Closed Bug 869813 Opened 11 years ago Closed 11 years ago

Option to set WebM or H.264 as preferred

Categories

(Core :: Audio/Video, enhancement)

Product:
Core
Component:
Audio/Video
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kolAflash, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 2013032900

Steps to reproduce:

I like the new possibility to use Gstreamer/WMF for H.264 videos. It's a lot better then Flash. But - if provided by the website - I like WebM even more!

In Firefox 20 H.264 and Gstreamer/WMF (if enabled) are preferred above WebM. But I think Firefox should prefer WebM and/or have an about:config option to set which one is preferred.

Preferring WebM is for keeping the WWW a place of open standards. H.264 should only be used if there's no other format provided by the website.

Same for MP3 and OGG.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Doesn't this rather belong in Firefox Product?
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Version: 20 Branch → Trunk
Change it if you're sure. I haven't done so many bugs in this Bugzilla. So I just put this bug where I thought it's ok.

One more note: Many websites put h264 (mp4) first in priority, because a lot of Apple devices (I think those running iOS 3) else won't play the content.
We don't give any priority to any specific video formats AFAICT. Please provide a testcase if I'm wrong.
Most users will not care about which format is used as long as the page "just works".
The author of the page chooses the format that is preferred for their website, by using multiple <source> tags in their <video> tag. I general, I think the browser should not tamper with the page, because the author might have put the two <source>s in this particular order for a reason.

I appreciate your and share your concerns about open formats, but I believe this is the responsibility of an addon rather than being an in-product preference.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
I understand that this is not the responsibility of Firefox. But what about just giving an about:config option which is not set as default?

"Not set" could be an empty string telling "prefer nothing, behave normal". If the user changes this for example to "webm" Firefox prefers "webm".

This way Firefox wouldn't make a choice but the user gets the ability to do so.

I currently can't find any AddOn doing this and I think this job can be done very well by an about:config option.


On Linux I face the situation that gstreamer is working for h264 videos, but not working very well. Sometimes the video doesn't play smooth and sometimes just nothing happens because the h264-video doesn't works at all but becomes preferred by the website. WebM works much better but some websites provide just h264 so I have to enable "media.gstreamer.enabled".

Now all the time I have to open about:config to activate "media.gstreamer.enabled" when I'm on a website not providing WebM.
And at another time I have to go back to about:config to disable "media.gstreamer.enabled", because the websites provides WebM and h264, puts h264 first, but h264 fails and it's not automatically switching to WebM.
Setting WebM as default by the browser would make this so much easier!!!

As said, Firefox shouldn't make this choice. But I think it would be ok if the user can do so, by setting an about:config option.
It's not really possible to have a setting to prefer one over the other. Most websites use JavaScript to ask the browser what it can play and then plays with that format. They use the 'canPlayType' API for this. 

The website will ask if it can play H.264, we say yes, then it plays it. If we say "no" to prefer WebM and the site doesn't support WebM then the site won't re-ask if we support H.264. we already told it no. We can't say "Yes, but please use it as a last resort" as the Web API's aren't designed this way.
OK, that makes it hard...
In that case a "per site" setting would be useful, but that's much more work I think...

I used to do <video ...> like this on my websites:
<video ...>
  <source src="http://example.com/video.webm" type="video/webm"/>
  <source src="http://example.com/video.webm" type="video/mp4"/>
</video>
I don't use any JavaScript Player. But that's maybe not the usual case...
Recently I changed the php scripts on the serverside, so now Safari gets mp4 first (because of the Safari bug I mentioned).
Safari doesn't support WebM at all. So it's normal it will choose mp4.
(In reply to Masatoshi Kimura [:emk] from comment #8)
> Safari doesn't support WebM at all. So it's normal it will choose mp4.

The Safari issue is they require mp4 to be the first 'source' element. Which means Firefox chooses it first which is what the OP wants to avoid.
I don't know why we have to clean up Safari's mess. Safari should fix the bug. If authors have to workaround the bug, they will have to workaround themselves.
(In reply to Chris Double (:doublec) from comment #9)
> (In reply to Masatoshi Kimura [:emk] from comment #8)
> > Safari doesn't support WebM at all. So it's normal it will choose mp4.
> 
> The Safari issue is they require mp4 to be the first 'source' element. Which
> means Firefox chooses it first which is what the OP wants to avoid.

Safari/WebKit don't require mp4 to be the first <source> element. WebKit looks at <source> elements in order and skips those with unsupported types or which fail to load before reaching HAVE_METADATA ("is found by inspection to be in an unsupported format, or can otherwise not be rendered at all"). 

I just verified this with a simple test case, but please file a bug if you fine a case which does not behave correctly - http://bugs.webkit.org/enter_bug.cgi?product=WebKit
(In reply to Eric Carlson from comment #11)
>
> Safari/WebKit don't require mp4 to be the first <source> element. WebKit
> looks at <source> elements in order and skips those with unsupported types
> or which fail to load before reaching HAVE_METADATA ("is found by inspection
> to be in an unsupported format, or can otherwise not be rendered at all"). 

I'm going by reports on the web since I don't have an iPad, but these reports state that on the original iPad the first source element had to be MP4 to work. eg:

http://meridianinteractive.com/blog/embedding-video-ie-ff-safari-chrome-ipad/
http://camendesign.com/code/video_for_everybody
Any way, we can do nothing about the next generation of IE6.
(In reply to Chris Double (:doublec) from comment #12)
> 
> I'm going by reports on the web since I don't have an iPad, but these
> reports state that on the original iPad the first source element had to be
> MP4 to work. eg:
> 
> http://meridianinteractive.com/blog/embedding-video-ie-ff-safari-chrome-ipad/
> http://camendesign.com/code/video_for_everybody

That bug was fixed several years ago.
You need to log in before you can comment on or make changes to this bug.