Comments on: using HTML5 video with fallbacks to other formats

By: Kelly

Kelly — Thu, 17 Jun 2010 16:16:18 +0000

So far, all implementations of the video tag in HTML5 have taken (in net speak) ages to load before playing.

I visit a site on Safari on a Mac and then in Firefox and do the same on Windows.

In every case (so far) the html5 video takes anywhere from 10 to 25(!) seconds before playing. Too much time in this world.

At least Flash and even QuickTime start playing within 5 seconds. You can just pause and wait and seem to be under more control than when you wait for 10 seconds before anything happens.

All I care about is getting the content delivered quickly and easily to the audience and thats what 100% of all users want. No, we developers are not users, not even when we’re off the job.. it’s a different mindset.

Unless you’re at a movie-trailer site, then videos should start playing within 5 seconds or the content has failed.

By: Roger Watson

Roger Watson — Sat, 24 Apr 2010 17:04:54 +0000

I’ve gone to Kroc Camen’s site just now using the iPhone and the demo video doesn’t play on the iPhone.
Additionally, I’ve used his method with regards to getting video to play on the iPad and the video doesn’t play on the iPad either (actually the play and pause controls don’t show up (they are there but for some reason invisible) but if you press on the screen where you know the play button should be the video will play.
Furthermore, if you run Safari on a pc one must press the pause button to play the video and press the play button to pause it (the video).
C’mon!
What a croc, Kroc!

By: Daniel D

Daniel D — Mon, 02 Nov 2009 10:12:16 +0000

Although I am more late on this, I can’t help but second the opinion mentioned in Fred’s first question:
I too see no need to have every frickin file encoded twice. This is pure waste of drive space!
This may seem irrelevant for the hobbyist content provider, but if you’re — say — an academic institution that’s going to provide lecture recordings in a VOD service, this adds up pretty quick.
And what for?
Encode H.264, pack it up in an MPEG 4 container and (through with Flash-fallback) you could serve it to virtually anyone — well, except Firefox users, that is.

Let me get this straight:
is intended to obfuscate Flash for web video, right?
Then, why on earth would one implement it in a way that does not handle codec mismatches gracefully???
If — for what ever ideological reasons — Mozilla chooses not to support MPEG 4 in the first place and goes for Ogg/Theora (what virtually no-one uses, but hey it’s open) instead, then why not at least handle MPEG 4 content gracefully?
Like — for example — ask the (plug-in) system if anything handles that type and if not, pass on to the fallback?

I strongly doubt, that it would have been much of an effort, to implement it that way…

I’m serious guys:
Battles for codec-superiority* are nothing you should fight on your users backs!

(* then again, from the technical point of view Theora _isn’t_ superior to H.264 — if I’m not mistaken; the only advantage it offers is being open)

Plus:
Add me to the list of “Don’t encourage the use of JavaScript for this!”-people.

Thanks

By: Fred K

Fred K — Mon, 28 Sep 2009 01:36:37 +0000

I know it’s a bit late in the game, but I have two questions:
1) Why should it be necessary for developers -big or small- to create/get two different versions of the same video file, to cover as wide an audience as possible? (And that is hoping that Microsoft doesn’t decide to push their own media format and excluding others.) At least two. Three, if Flash is added into the mix. It feels quite contrary to the spirit of HTML 5, and in my view it’ll probably hamper its uptake rate. In my view, if I publish an mp4 file (for example) using the element, that file should be viewable by users that have or decide to install the appropriate browser plugin. Same goes obviously if I publish an ogg file. What we’re seeing now is two sides pushing their separate codecs, disallowing the other side’s playable formats, and MS waiting in the wings. Not good. Mozilla/Opera and Apple/Google need to settle this thing quickly. Then MS can just jump on the train – no?

2) Apparently the file extension .ogv makes an ogg video unplayable in Firefox. That’s weird, because when using ffmpeg2theora to convert files to ogg video (I’m on a Mac, ffmpeg2theora is the recommended converter), it automatically makes them *.ogv* files. And since this information is virtually non-existent (that .ogv files are unplayable in the main browser that requires ogg files for HTML 5 video) it takes a great deal of digging to understand what the f*** is going on. If you’re going to allow only one file format, make sure that the information is abundantly clear about this, and readily available. If for nothing else, to save me from having a(nother) bleeding ulcer… (I’ll put this to the ffmpeg2 people, but you (Mozilla) and Opera need to start making this info visible.)

Thanks

By: Friday Linkdump at aleatory

Friday Linkdump at aleatory — Fri, 10 Jul 2009 08:06:56 +0000

[...] open letter railing against the evils of javascript in manipulating html5 structs. Thankfully they all lived happily ever after [corrected original article], although surely a sign of the difficulties involved & [...]

By: ginger’s thoughts » Javascript libraries for <video> support

ginger’s thoughts » Javascript libraries for <video> support — Wed, 08 Jul 2009 10:22:01 +0000

[...] posts that demonstrate how to play flv files in a [...]

By: video - more than just a tag at hacks.mozilla.org

video - more than just a tag at hacks.mozilla.org — Wed, 08 Jul 2009 03:04:56 +0000

[...] Here’s some more information about the fallback mechanism. [...]

By: Steven Rowat

Steven Rowat — Tue, 23 Jun 2009 21:20:29 +0000

@Lars
Thank you, this is very helpful, and I’ll look at your code.

I’m using PHP otherwise to generate the HTML code, so it would be great for me if that could cover what CSS can’t do; but I assume that’s not possible here since only the Javascript or HTML read by the browser can apply in a client-side issue like this. Is this correct?

By: Lars Trieloff

Lars Trieloff — Tue, 23 Jun 2009 19:10:16 +0000

@Steven – no, the controllers cannot by styled using CSS. This is where my library would come to play (you can have a look at the source code, it is not very to do)

The spec says:

The controls attribute is a boolean attribute. If present, it indicates that the author has not provided a scripted controller and would like the user agent to provide its own set of controls.

If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user. This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, and show the media content in manners more suitable to the user (e.g. full-screen video or in an independent resizable window). Other controls may also be made available.

This also lists all the “basic stuff”: play/pause/seek/volume

By: Steven Rowat

Steven Rowat — Tue, 23 Jun 2009 18:02:07 +0000

@Lars
“…no Javascript for basic things like video playback.”
Good, thank you; it remains only to ask about what is included in ‘basic things’:

My need, which I believe will be shared by others for a variety of reasons and uses-cases, is this: can the standard audio (and video) tag controllers that appear on-screen, without Javascript, be modified by CSS for color, transparency, size, and control features?

I’m doing a site, for example, that has an individual web page for each of >100 poems. Each poem is unique, has a unique image background, and the page containing it is meant to be experienced as a whole: including, if an audio controller is added, different needs for the controller color, transparency, and sizes and types of controls available. Current Windows Media, QuickTime, and Linux-based controllers lack some or all of the basic color, size, transparency and controls configurability, and what remains is also different on different OS’s and browsers. WM and QT controllers appear so intrusive and out-of-place in many of the poems that I gave up attempting to use them, waiting instead for HTML5 audio/video tags, where I intend another attempt — one where I hope to be able to set a consistent controller across browsers and OSs.

So, my question is: will this sort of configuration of the controller now be possible — and without Javascript?

By: Lars Trieloff

Lars Trieloff — Tue, 23 Jun 2009 15:24:16 +0000

@Steven: no Javascript for basic things like video playback – agreed. But if you want to build a non-linear-video editor on the web, create your own controls, etc. you need Javascript. This is where my solution is targeted at. I am also looking forward to incorporate Video for Everyone in future examples, so that the easy things work easily.

@Kroc: RSS Readers is a different topic, because
- they have shorter upgrade cycles than browsers, so they can soon implement html5 video natively
- web-based feed readers use Javascript anyway, they could even use html5flash to implement html5 video now
- there is MediaRSS, which is similar to a video element with multiple source elements

From my point of view, the real concern is getting having the video element in the markup, so that user agents know what’s going on and to have a fallback for the non-FF/non-Chrome/non-Safari population. People with Javascript disabled are less common in my usecase, and disabling Javascript often correlates with disabling Flash and Plugins, which would make most fallbacks unworkable.

By: html5 video fallbacks with markup at hacks.mozilla.org

html5 video fallbacks with markup at hacks.mozilla.org — Tue, 23 Jun 2009 06:25:54 +0000

[...] a previous post on this blog we talked about using JavaScript to create video elements on the fly. While that was a good use [...]

By: Kroc Camen

Kroc Camen — Mon, 22 Jun 2009 17:15:40 +0000

@Mike @Lars Trieloff

What of RSS readers that don’t execute JavaScript?

A common API is definitely what’s needed Lars, I think everybody would benefit if we could combine Video for Everybody with HTML5Flash so that JavaScript isn’t required to see the video (including Flash users), but a JavaScript API allows people to do more advanced stuff and interact with the page.

By: Steven Rowat

Steven Rowat — Mon, 22 Jun 2009 17:12:19 +0000

I agree with the prevailing sentiment in the comments so far: no, please, no Javascript! This is an important cross-roads of the web, I believe: an open, standard, easy-to-use HTML video is essential NOW to avoid another decade of corporate obfuscation. ANd AFAIK the audio tag (which is my primary interest) is in the same boat as the video, web-wide, and so I ask Mozilla to do the same with it: true work out a true HTML 5 implementation with best possible fallback; without Javascript.

By: 颠覆网络35天 ─ 使用HTML5 video时向前兼容 < MJiA

颠覆网络35天 ─ 使用HTML5 video时向前兼容 < MJiA — Mon, 22 Jun 2009 07:07:30 +0000

[...] 原文地址：using HTML5 video with fallbacks to other formats 系列地址：颠覆网络35天 [...]

By: sxpert

sxpert — Mon, 22 Jun 2009 06:58:09 +0000

@PD
you owe us all $5 ;)

By: Lars Trieloff

Lars Trieloff — Sun, 21 Jun 2009 21:06:33 +0000

I have been working on an approach that uses the video markup directly in HTML, but will employ a Javascript wrapper library to provide a Flash fallback that still implements most of the HTML5 mediaelement API. This makes it possible to start, stop and resume video playback using one, standardized cross-browser API, even when the Flash fallback is being used. Thanks to gradual improvement the HTML still contains the video element, so that mashups and aggregation continue to work.

There is a blog post describing my approach here: http://gettingsoftware.posterous.com/html5flash-using-html5-video-and-audio-right and the source code is available from Github.

By: Nick

Nick — Sun, 21 Jun 2009 18:35:45 +0000

I would prefer the following approach: Use only the video element and fallback content in your markup. Then run one JS script on page load, that converts video elements to the corresponding object elements for browsers that don’t support HTML5 video.

The only users who wouldn’t see embedded video although they technically could are the ones that have Flash enabled, but Javascript disabled. And that’s a negligibly small part of most audiences.

By: Mike

Mike — Sun, 21 Jun 2009 17:35:02 +0000

We intend to use Kroc Camen’s implementation on our Oracle Reference Library site (http://psoug.org) because it’s the way it SHOULD be done. Javascript is NOT required, nor should it be.

A big “Thank You” to Kroc for posting the correct way to embed video using HTML5. For those interested in doing it the right way (instead of the FUBAR way, Kroc’s page is here: http://camendesign.com/code/video_for_everybody

-Mike

By: Eevee

Eevee — Sun, 21 Jun 2009 09:27:05 +0000

Augh. Please, no. I’m so tired of sites that use convoluted Javascript to accomplish things that plain HTML does simply. It doesn’t work with NoScript (and usually has no helpful fallback), it’s harder to examine, and it’s harder to change client-side. This is not what the Web is supposed to be about, Mozilla.