Closed Bug 566796 Opened 15 years ago Closed 9 years ago

Add detection of H.264 videos and custom error UI.

Categories

(Core :: Audio/Video: Playback, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 494379

People

(Reporter: Dolske, Unassigned)

References

Details

(Whiteboard: [testday-20120302])

Mozilla believes that relying on H.264 is bad for the web, so we should present a bit of advocacy to our users to help the cause... Bug 513405 covers the general case of making media errors more descriptive (instead of just a big "X"). As a special case of this, we could detect when the only offered/available media type for a <video> is encoded with H.264, and present a custom error message for the situation. It could be as low-key as "This media format is not supported. <a>Learn more...</a>", or blunt like "This media format is not supported because it's patent-encumbered and kills puppies. Please, think of the puppies." I _think_ this would already be possible to do if everyone used <source> elements with the full markup (type/codecs attributes), but I suspect the more common case for H.264-only sites will be <video src="foo.mp4">. Or even src="foo" with a missing/ambiguous extension? I don't think the H.264 detection needs to be perfect -- if we already know that there's just 1 available source and we can't play it (via the existing source selection algorithm), it would be less than terrible to guess at it being H.264 based on the file extension (and/or data sniffing?), if no more-reliable metadata is available.
We don't currently guess based on the extension for media playback support except in the case of local files. I suggest using the server mime type which is how we detect whether we can play a file or not. We shouldn't assume that a non-playable file is H.264. It could be MP3 as another example.
IMHO, bug 635788 had a better summary, if this bug covers mp3.
The following are some notes from talking with cpearce: We'll have to add plumbing code on the media element to get access to the server mime type for H.264 files. We could extend MediaError to contain a list of the resources and their mime types it tried and failed to load, and use that from the JS. A common error is that people have Ogg or whatever, and they don't serve their media with a mime type, and so we don't load it. cpearce would *really* *really* want some sort of warning text on this case, as it's *really* common. Most of the cases where people say "this HTML5 video demo works best in chrome" is because they didn't realize they were making that mistake. Basically we could infer the H.264 case and the Ogg but no mimetype case if we had that the list of {resource,mimetypes} that failed to load on Media.error.
It is not clear if this bug is H.264 specific unlike bug 635788. Please clarify if it also applies to formats like Ogg/FLAC or Ogg/Speex. Related bugs: bug 494379, bug 544716.
Whiteboard: [testday-20120302]
Is this bug still valid while we are going to support H.264 at least on mobile?
(In reply to Masatoshi Kimura [:emk] from comment #6) > Is this bug still valid while we are going to support H.264 at least on > mobile? As I understand it, we're not planning on shipping our own H.264 decoder, but a bug like this would be useful for users who don't have the H.264 decoder installed on their machine. With that being said, we should probably duplicate this bug to bug 494379 since that bug is calling for more generic error messages related to unsupported codecs.
Component: Audio/Video → Audio/Video: Playback
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.