(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 Ubuntu Bugs, which is subscribed to 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 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
