Launchpad has imported 15 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=794282.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-09-25T23:02:12+00:00 Mar-castelluccio wrote: Enable GStreamer in official builds for Linux. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/4 ------------------------------------------------------------------------ On 2012-09-26T00:24:20+00:00 Ted Mielczarek wrote: I suspect we don't want to do this until we have a plan for getting support for all the platforms we ship desktop Firefox on. Just shipping h.264 support on Linux doesn't help us. (And it might hurt us, by having different codecs supported on different desktop Firefox builds.) Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/6 ------------------------------------------------------------------------ On 2012-09-26T00:33:01+00:00 Pdowling wrote: Does having different codecs in mobile and desktop already hurt? Case: User wants to view a video they have accessed on Firefox mobile and synced with Firefox Sync onto their desktop. One scenario they can play it, another they cannot, frustration ensues? In addition, Flash continues to be problematic for security, reliability and so on. Enabling genuine HTML5 video support (h.264) across all desktop and mobile builds would enable developers to take a genuine pro- HTML5 open web, plugin-free step they cannot easily take right now because Firefox is a substantial blocker for h.264 on a seemingly shrinking basis. Re XP lacking native h.264 support, what are the issues surrounding bundling or linking to the x264 codec to solve this issue? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/7 ------------------------------------------------------------------------ On 2012-09-26T02:11:39+00:00 Chris Double wrote: I think we should enable GStreamer in Linux builds even if we don't support H.264 in the other platforms yet. Things to be resolved before we can do this though: 1) Get the mochitest media tests passing. There's a H.264 video file in the tests already. 2) Ensure Firefox still runs on Linux distributions that don't have GStreamer or have older versions. 3) Check that we have new enough GStreamer libraries on build machines. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/8 ------------------------------------------------------------------------ On 2012-09-26T02:15:45+00:00 Pdowling wrote: (In reply to Chris Double (:doublec) from comment #3) > I think we should enable GStreamer in Linux builds even if we don't support > H.264 in the other platforms yet. Agreed. > Things to be resolved before we can do this though: > > 1) Get the mochitest media tests passing. There's a H.264 video file in the > tests already. > 2) Ensure Firefox still runs on Linux distributions that don't have > GStreamer or have older versions. > 3) Check that we have new enough GStreamer libraries on build machines. I'd be more than willing to help test at least every Debian-based distribution I can get my hands on as I have basic familiarity with the Advanced Packaging Tool (apt) but not really with rpm or other systems. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/9 ------------------------------------------------------------------------ On 2012-09-26T06:15:53+00:00 Henri Sivonen wrote: (In reply to Chris Double (:doublec) from comment #3) > I think we should enable GStreamer in Linux builds even if we don't support > H.264 in the other platforms yet. > > Things to be resolved before we can do this though: > > 1) Get the mochitest media tests passing. There's a H.264 video file in the > tests already. > 2) Ensure Firefox still runs on Linux distributions that don't have > GStreamer or have older versions. > 3) Check that we have new enough GStreamer libraries on build machines. 4) Check that when MP4, H.264 and AAC support is present, canPlayType() behaves as in other H.264 and AAC-supporting browsers. See bug 760140. 5) Test that when both H.264 and AAC decoders are absent, canPlayType() behaves like in Firefox today even if an MP4 demuxer is present. 6) Test that MPEG4 Visual, MPEG2 or other non-H.264, non-AAC encumbered codecs do not get exposed to the Web as a side effect. #4 and #5 are important for avoiding poisoning canPlayType(). #6 is important to take care of before enablement, because it’s hard to take features away even if the features were unintentional. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/10 ------------------------------------------------------------------------ On 2012-09-26T06:38:07+00:00 Mh+mozilla wrote: I doubt this is possible to do for official builds. Distro builds could do it, but official will likely have a hard time maintaining binary compatibility with different versions of the system libraries. Look at the ABI changes between 0.10 and 1.0. http://upstream- tracker.org/versions/gstreamer.html Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/11 ------------------------------------------------------------------------ On 2012-09-26T06:39:38+00:00 Mh+mozilla wrote: and no, embedding gstreamer like we embed other third party libraries won't help. The only way it would work would be to also embed the mp4 decoder, and that's opening a legal can of worms. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/12 ------------------------------------------------------------------------ On 2012-09-26T07:15:31+00:00 Pdowling wrote: (In reply to Mike Hommey [:glandium] from comment #7) > and no, embedding gstreamer like we embed other third party libraries won't > help. The only way it would work would be to also embed the mp4 decoder, and > that's opening a legal can of worms. Perhaps we're missing the point here. I realize this specific bug focuses on GStreamer but AFAIK the broader goal is (or perhaps should be?) enabling HTML5 <video> support for the most common format(s) on all platforms that Firefox supports. Is it possible that this goal would be more easily achieved if Firefox were to use the native media frameworks for each platform, i.e. DirectShow, GStreamer and Quicktime, as Firefox mobile does with Stagefright? Would utilizing these frameworks possibly be less work than targeting a single framework that perhaps changes so often because it is trying to be everything to everybody? On another note, has anybody engaged the GStreamer people and asked them if they are willing to work with Mozilla by maintaining a branch of their code that preserves binary compatibility for longer than they historically have to date? If not glacial pack ice frozen APIs, perhaps ice cube APIs capable of thawing every summer or so? :) There could be a ceremonial GStreamer/Mozilla ice cooler that API documents get thrown into, a bit like a time capsule :) Sorry, just a bit of mirth there! In addition, doesn't any code base change a lot more frequently whilst getting to version 1 than it is likely to after that point? Perhaps then Mr Hommey's example in comment 6 is not necessarily representative of future development trends? Apologies if these points are less technical and more general than is ideal. However this bug thus far has seemed to evolve in more of a discussion manner than other bugs might normally so I hope it's ok to continue that style for the moment at least. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/13 ------------------------------------------------------------------------ On 2012-09-26T07:42:37+00:00 Henri Sivonen wrote: (In reply to Mike Hommey [:glandium] from comment #6) > I doubt this is possible to do for official builds. Distro builds could do > it, but official will likely have a hard time maintaining binary > compatibility with different versions of the system libraries. Look at the > ABI changes between 0.10 and 1.0. > http://upstream-tracker.org/versions/gstreamer.html I took the topic to dev-planning since Bugzilla isn’t a discussion forum: https://groups.google.com/d/topic/mozilla.dev.planning/aYOuhdkKNXo/discussion Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/14 ------------------------------------------------------------------------ On 2012-09-26T08:38:27+00:00 Matej wrote: Just to note that we are IMHO getting back to bug 422540, bug 435298, and bug 435339, which IMHO was a mistake to WONTFIX. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/15 ------------------------------------------------------------------------ On 2012-09-26T08:54:20+00:00 Chris Double wrote: (In reply to Matej Cepl from comment #10) > Just to note that we are IMHO getting back to bug 422540, bug 435298, and > bug 435339, which IMHO was a mistake to WONTFIX. It was WONTFIX according to the policies and direction at the time. How (and if) support of H.264 across platforms is eventually done is yet to be decided and it may be that those approaches are used. I'd rather leave general H.264 support out of this bug though and concentrate on what needs to be done to get GStreamer enabled - if it's even a good idea based on Mike Hommey's comments. Is it better just to leave it up to distro's to enable? Should we change the GStreamer backend to use the MPAPI plugin approach that Android's media support uses to enable dynamic loading of it? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/16 ------------------------------------------------------------------------ On 2012-09-26T17:44:55+00:00 Riles wrote: gladium makes a good point. I think it's clear that if we enabled the gstreamer backend in official builds, we'd want to include our own build. But that doesn't help if it's not abi compatible with the elements we want to use on the system. I just tried loading the fluendo binary elements for gstreamer-0.10 with today's git (gstreamer 1.0.0) and it wasn't able to find the entry points: WARN GST_PLUGIN_LOADING gstplugin.c:383:gst_plugin_register_func: plugin "/home/giles/gstreamer/fluendo-bin/libgstflump3dec.so" has incompatible version, not loading So while I thought it was clear official biulds would include their own builds of gstreamer if we enabled this back end, that doesn't help if we can't load elements from the system gstreamer install. We could still pick a target version and only support that, which is easier to do now that gstreamer 1.0 is released. That might be ok if we could fall back to our built-in decoders when the requested elements aren't available. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/17 ------------------------------------------------------------------------ On 2012-09-26T17:55:50+00:00 Mar-castelluccio wrote: http://www.collabora.com/about/gstreamer-interview/ Looks like simple usages of GStreamer shouldn't be broken (but http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-1.0.txt is pretty long...). Maybe we can load GStreamer dynamically and, if we use only a subset of the API, we could avoid running into issues (just like we're now doing with libnotify). AFAIK, there will be other API breakages in the future. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/18 ------------------------------------------------------------------------ On 2012-09-26T18:00:04+00:00 Riles wrote: Keep in mind that calling system gstreamer libraries means feeding data from the network into code we have no way to issue security fixes for. Being able to protect our users independent of distro updates is why the official builds include there own copy of even ubiquitous libraries like zlib. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1051559/comments/19 ** Changed in: firefox Status: Unknown => Confirmed ** Changed in: firefox Importance: Unknown => Medium -- 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
