Hi, summary is self-explaining. gst-plugins-meta is meant to help in supporting apps with optional dependencies on multiple gstreamer plugins. If firefox requires gst-plugins-ffmpeg or gst-plugins-libav, it needs to depend on it directly.
Per conversation on IRC #gentoo-dev, we will adjust the dep to point to gst-plugins-libav:1.0 for the next mozilla releases.
(In reply to Gilles Dartiguelongue from comment #0) > Hi, > > summary is self-explaining. > > gst-plugins-meta is meant to help in supporting apps with optional > dependencies on multiple gstreamer plugins. If firefox requires > gst-plugins-ffmpeg or gst-plugins-libav, it needs to depend on it directly. This is where the gnome team needs to make up their mind. We were requested to change it once and now you all want us to change it again. Make up your mind on what the policy is gonna be please.
(In reply to Jory A. Pratt from comment #2) gst-plugins-meta is for the "my package's users may need to play any random format that gstreamer supports, I don't want to add a dozen flags to IUSE and keep track of all the plugin names, so I will just depend on gst-plugins-meta for simplicity" situation. gst-plugins-libav is for the "my package's users specifically expect to be able to play wmv or mpeg" situation.
(In reply to Alexandre Rostovtsev from comment #3) > (In reply to Jory A. Pratt from comment #2) > > gst-plugins-meta is for the "my package's users may need to play any random > format that gstreamer supports, I don't want to add a dozen flags to IUSE > and keep track of all the plugin names, so I will just depend on > gst-plugins-meta for simplicity" situation. > > gst-plugins-libav is for the "my package's users specifically expect to be > able to play wmv or mpeg" situation. And of course if your package explicitly is constructing a pipeline with a certain plugin (as opposed to just letting playbin autodetect the file type and find some plugin to play it), it needs to depend on that plugin.
(In reply to Alexandre Rostovtsev from comment #4) > (In reply to Alexandre Rostovtsev from comment #3) > > (In reply to Jory A. Pratt from comment #2) > > > > gst-plugins-meta is for the "my package's users may need to play any random > > format that gstreamer supports, I don't want to add a dozen flags to IUSE > > and keep track of all the plugin names, so I will just depend on > > gst-plugins-meta for simplicity" situation. > > > > gst-plugins-libav is for the "my package's users specifically expect to be > > able to play wmv or mpeg" situation. > > And of course if your package explicitly is constructing a pipeline with a > certain plugin (as opposed to just letting playbin autodetect the file type > and find some plugin to play it), it needs to depend on that plugin. Leio and I had a fairly long discussion about this in #-dev yesterday; due to the fact that mozilla products use 'playbin' he recommended two courses of action: 1 - keep it as-is. 2 - depend on the following: ( gst-plugins-good # for containers || ( gst-plugins-libav # for software decoding ( gst-plugins-vaapi # only hardware decoder right now gst-plugins-faad # hardware decoder cant do m4a, need this gst-plugins-mad # hardware decoder cant do mp3, need this ) ) ) ...which we would need to update as-needed for any future hardware decoders, like gst-plugins-omx
Imho, being able to || or hardware decoders plugins is an refinement that needs not be reflected in ebuilds. Not everyone has hardware decoding capabilities and plugins to make use of it are likely to be varied making it hard to have a consistent list across packages.
(In reply to Gilles Dartiguelongue from comment #6) > Imho, being able to || or hardware decoders plugins is an refinement that > needs not be reflected in ebuilds. Not everyone has hardware decoding > capabilities and plugins to make use of it are likely to be varied making it > hard to have a consistent list across packages. Yeah, I guess it's mostly useful to be able to unmerge software decoders, or not install them in the first place when concerned about software patents (as the patent fees for hardware decoding are paid for already). Anyhow, from that discussion I remember that H.264/AAC, VP8, etc is not handled via gstreamer, but more like via ffmpeg/libav directly or something. But I can't spot any other media dependencies than gstreamer. Is ffmpeg/libvpx code bundled in firefox and not unbundled by us, or I misread something? People in the forums seem to be reporting HTML5 working with firefox without USE=gstreamer. Note that gstreamer master now prefers the gst-plugins-libav provided AAC decoder over gst-plugins-faad. For some reason that wasn't done to 1.4 branch, and I'll have to check with upstream on that as I remember they pretty much considered gst-libav one better already in 1.3 days or earlier
For 1.4 they suggest depending on gst-plugins-faad; or || ( gst-plugins-faad gst-plugins-libav ) for AAC software decoding. gst-plugins-libav priority switching to higher was a non-trivial change post-1.4 and it's still to prove itself fully in development versions or something. I wonder if firefox could somehow support gstreamer missing-plugins architecture or already does. Then it could prompt some codec as missing, but it might get complicated when it needs to immediately report to the website if it supports that format or not (but could at least tell in some infobox that it was missing, like it does for flash or whatnot). Though in Gentoo we don't have missing-plugins support, but eventually...
(In reply to Mart Raudsepp from comment #8) > For 1.4 they suggest depending on gst-plugins-faad; or || ( gst-plugins-faad > gst-plugins-libav ) for AAC software decoding. gst-plugins-libav priority > switching to higher was a non-trivial change post-1.4 and it's still to > prove itself fully in development versions or something. > I wonder if firefox could somehow support gstreamer missing-plugins > architecture or already does. Then it could prompt some codec as missing, > but it might get complicated when it needs to immediately report to the > website if it supports that format or not (but could at least tell in some > infobox that it was missing, like it does for flash or whatnot). Though in > Gentoo we don't have missing-plugins support, but eventually... ... ok, so then if I understand this correctly, we want to change the gst-plugins-mega[ffmpeg] into ( gst-plugins-good gst-plugins-libav gst-plugins-faad ) ... ?? Or should we just leave the dep as-is since as discussed firefox doesn't have any link-time deps and uses that gstreamer-loader call (sorry can't remember its name) to actually use it?
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team