BCmoney MobileTV

Answer #1

The following shows an example of playing a video using an animated GIF as the poster:

(NOTE: the video used in the demo is not meant to go with the actual image, I just picked a random funny Animated GIF!)

The code for this is quite simple:

<video id="movie" width="320" height="240" poster="video.gif">
<source src="video.mp4" />
<source src="video.ogv" />
<source src="video.webm" />
</video>

Just as you might expect, you simply place it in the poster attribute of the <video> tag itself. This could have lots of uses for image previews, rollovers (by dynamically changing the value of the poster attribute using JavaScript), and possibly even playing back the entire video without sound for some devices that still don’t support HTML5 video. In some cases you could even combine an Animated GIF with the HTML5 <audio> tag or another audio playback method for those odd cases such as legacy Mobile Devices or old decrepit browsers like IE which simply can’t support the <video> tag at all… though for those, using a Flash fallback like JW, FlowPlayer or VideoJS can be another alternative.

The animated image itself could be generated by taking snapshots of the video at various time intervals, and combining them into a single animated GIF image using a graphics library like ImageMagick or FFMPEG. All of this would happen automatically upon upload of a new video file. This “real-time encoding of the poster image” concept gave me an idea for a service which could solve what is IMHO one of the most significant problems for HTML5 video adoption, bringing me to my next point…

Answer #2

To answer question #2: “is HTML5 ready for primetime?”, I would simply point to the increasingly common use of the new video tag (see DailyMotion, Vimeo, and YouTube), proving it is indeed almost ready for primetime.

The only thing holding HTML video in particular back, is a common denominator video container/codec format. The use of MP4 with a Flash fallback is already enough for supporting a pretty wide array of browsers, and its mostly mobile devices other than the iPhone that we have to worry about for specific implementations. If you want to avoid encoding in multiple formats (i.e. MP4, WebM, Ogg Theora, 3GP and 3GPP), then your best bet is to use a direct-link fallback, which will work for those devices which can’t render the <video> tag yet, but can possibly play MP4. The only thing that bothers me about MP4 (ok there’s a few other things too, such as the questions still surrounding licensing despite the MPEG-LA group’s attempts to reassure the public they will never enforce fees) is that within the container itself, there are several different profiles and codec combinations, and so, you still won’t be guaranteed that you do support many mobile devices other than Apple products.

So what’s the best alternative then? Possibly WebM, but with Google‘s ever growing hold on the entire internet industry, it makes that option less and less attractive (although I certainly appreciate the premise of the project). More likely, I think what we need and will see soon enough is a real-time conversion tool or service, to which we can POST videos as they are needed, which will serve the video in the desired format, on-demand.

For example, we send a POST containing our MP4 video named “coolvideo.mp4” to http://video.org/convert along with a to parameter, a width parameter, and a height parameter (with some sample values being to=ogg&width=600&height=400 for playback in FireFox on a laptop, or to=3gp&width=320&height=240 for playback on a mobile device) then, we get back a temporary link to stream the created video. After the stream disconnects (or the player closes the page or navigates to another video), the temporary URL and video could be deleted. Such a real-time transcoding service would surely solve most of the problems for secure video playback on the web, and it could either be run as a 3rd party Web Service with remote authentication, or, delivered as an open source package which can be run alongside an existing library like FFMPEG on your own servers.

The important thing to note, and indeed the reality check for this idea, is that conversion takes time as does passing the video between servers, so it may be impractical for now; but the idea holds some water, internet speeds are increasing day by day, and things that were thought impossible only a few years ago are now possible on today’s World Wide Web. Since HTML5 video is about 2-5 years away from becoming a de facto standard for video on the web, a lot changes in a few years time, so I wouldn’t dismiss the possibility of real-time video encoding just yet. The promises are quite great, in that publishers would only have to choose one format for all of their videos and still be able to push that video to just about any browser or device in near real-time (today; with fast connections, optimizations and parallel processing, a relatively short video could be transmitted to an encoding service, encoded and delivered to the user in about as much time as it used to take to load and buffer an online video about 5 or 6 years ago).

[snippet id=63451]