(In reply to Bryan Quigley from comment #24) > (In reply to Chris Pearce (:cpearce) from comment #19) > > We talked about this in Auckland, and we'd prefer to use our existing > > built-in backends for Ogg and WebM, since they've been fuzz tested and we > > know they're reliable. > > Maybe I'm misunderstanding this, but are there outstanding exploits that > Mozilla found that haven't made it upstream yet to Ogg, WebM? If it is > gStreamer specific, but not the codecs, then all someone would need to do is > use H264 to exploit it.
We apply several patches on top of our libvpx, and a couple on top of the Xiph Ogg libraries. I don't know if these have been fixed upstream yet. Possibly some or all of these patches have been upstreamed and our libraries are behind current-stable versions. This decision also motivated by the fact that we know our built in decoders work reliably, and we know that the GStreamer backend has some problems; it fails our unit tests, so we know there are bugs either in GStreamer or in our use of it. > > I'm going to change our decoder creation code in bug 799344 to not use > > GStreamer for Ogg and WebM. > > One of the reasons I am interested in this bug is due to what seems to be > much better video acceleration code in gStreamer vs Firefox. At least could > it be be made an about:config option, pass all to gstreamer? Sure, I will do this, it's a good idea. -- 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
