[Bug 1051559]

[Alessandro Decina]

(In reply to Chris Pearce (:cpearce) from comment #47)
> (In reply to Alessandro Decina from comment #46)
> > In addition to that, we could potentially consider importing the
> > ogg/webm/h264 gst plugins in m-c so there's even more control over those.
> 
> I'd rather keep our existing backends/libraries for decoding Ogg and WebM
> unless there's a compelling reason to switch to using GStreamer for those
> formats.

The only possible advantage I can see in using GStreamer for webm is
performance on mobile platforms. I have seen ARM vendors spend time
optimizing webm with their own codecs and some have announced webm hw
support. GStreamer has pretty good support for vendor provided codecs in
android/linux platforms.

I do see your point though and realize that what I said above can be
handled on a case by case basis with the media.prefer-gstreamer pref.


> Our Ogg and WebM libraries have been fuzzed pretty hard over the years, and
> our backends using those libraries have been well tested and are known to be
> robust and work well. We don't really want to redo all that
> "robustification" work for Ogg and WebM, we won't gain much by doing that
> now. Keeping our existing libraries also ensures Firefox's media playback
> behaviour is more likely to remain consistent across all platforms.

This makes sense. FWIW I saw that the test suite includes some half
broken/forged files. Last time I checked the gst backend did pretty well
with those, with the exception of one theora file that caused a crash
for which I have a patch laying somewhere.

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1051559

Title:
  Build Firefox with GStreamer support

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1051559/+subscriptions