591080 - when we cannot play any available source type, we should ignore the video element

Status: RESOLVED INACTIVE

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

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

The <video> element uses a <source src="URI" type="media/format"> element to indicate the URI and MIME type of video stream to be used. Not all browsers support all available stream types, though - for example, Firefox does not support video/mp4, and Firefox 4 supports video/webm or video/ogg but Firefox 3.6 only supports video/ogg. When there's no <source> element that matches a supported type, though, we render the <video> element as "broken".

You can see how this works using this testcase: http://beltzner.ca/test/testvideo.html

Try it in IE8, Firefox 3.6, Firefox 4.0 and Safari, and interestingly, you'll see that the only browser that can render the video content without fail is IE8, the browser that doesn't support the <video> tag :) That's because the code I'm using contains a fallback for browsers that don't support that tag, allowing the web author to include an <img> or <object> tag.

I propose that in cases where we cannot use any of the available <source> elements in a <video> element, we should just not render the <video> element and use any available fallback. I know that web authors can use JS to determine a priori if the client can display a given MIME type, but this feels like it would be a lot easier for web authors, and end up promoting use of the <video> tag as it would gracefully degrade without additional JS requirements.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is a spec issue. It's been raised many times on the WHATWG list. Unfortunately specifying and implementing a solution has proven hard. You might want to raise it again there anyway.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(But you probably should read previous threads on the topic first.)

Comment 3

[cajbir (:cajbir)]

This has been asked for occasionally and discussed on the WHATWG list:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023850.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020998.html

The latter has comments from the spec editor on the issue.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Reopening, not to be cumbersome and annoying, but because I don't think that in this specific case we gain anything by being spec-compliant.

The latter link in comment 3 shows that the spec editor is basically unwilling to support this sort of change at the specification level, but I think that following that specification will ultimately lead to a bad user experience for Firefox users. I will figure out how to jump into the lion's den tomorrow; it's been a year, and there are now multiple video codecs in play, so perhaps the spec editor will entertain argument again.

Is it possible for us to do the right thing for users here, even if it isn't spec-compliant?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There's always some benefit for the Web when browsers interoperate.

If you think the benefits of easy fallback here outweigh the loss of interoperability --- well, you could be right.

This probably wouldn't be *terribly* hard to implement. We could hack frame construction to construct a block frame for <video> when the element is in the right error state. We'd reconstruct frames when entering/exiting the error state. That would probably be enough.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Just making the omgnotablocker part clear ;)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Where "the error state" is defined as, say, "media element has a 'src' attribute or <source> child, AND media element is in state NETWORK_NO_SOURCE, AND if the media element was created by the parser then the parser has closed it (IsDoneAddingChildren)".

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #5)
> If you think the benefits of easy fallback here outweigh the loss of
> interoperability --- well, you could be right.

I actually think it's better than that: when we obviously *don't* interoperate (as evidenced by not supporting the video format specified) we should support easy fallback. The user wins! :)

Comment 9

[Gordon P. Hemsley [:GPHemsley]]

I think this should be revisited, and I think it should also apply to <audio>.

Since fallback content within <audio>/<video> is only used by browsers that do not support those elements, Firefox rightly ignores that fallback content, AIUI.

However, if Firefox then discovers that it doesn't support the media type of the element, then it should treat it like an <embed> and pass the file off to the plugin associated with that file type.

For example, Firefox doesn't support MP3 files. However, the QuickTime plugin does. If the MP3 file is linked to in an <embed> element or is visited directly, the QuickTime plugin will parse it and play it properly. However, if the MP3 file is linked in an <audio> element, this does not happen. Rather than have the same behavior as the <embed> element, Firefox simply does nothing. This is a bad user experience and benefits no one except those who are (orthogonally) advocating for a different audio format.

If the spec does not allow this behavior, the spec should be changed. And, in the meantime, Firefox should willingly violate the spec in order to improve the user experience.

Comment 10

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.