Comment 67 for bug 1051559

(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.