Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 515198 - www-client/firefox depends on gst-plugins-meta[ffmpeg]
Summary: www-client/firefox depends on gst-plugins-meta[ffmpeg]
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-26 13:32 UTC by Gilles Dartiguelongue (RETIRED)
Modified: 2017-08-26 17:55 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gilles Dartiguelongue (RETIRED) gentoo-dev 2014-06-26 13:32:15 UTC
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.
Comment 1 Ian Stakenvicius (RETIRED) gentoo-dev 2014-06-26 15:06:25 UTC
Per conversation on IRC #gentoo-dev, we will adjust the dep to point to gst-plugins-libav:1.0 for the next mozilla releases.
Comment 2 Jory A. Pratt gentoo-dev 2014-06-27 02:56:05 UTC
(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.
Comment 3 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-06-27 03:34:41 UTC
(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.
Comment 4 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-06-27 03:39:00 UTC
(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.
Comment 5 Ian Stakenvicius (RETIRED) gentoo-dev 2014-06-27 14:04:06 UTC
(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
Comment 6 Gilles Dartiguelongue (RETIRED) gentoo-dev 2014-06-29 13:42:37 UTC
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.
Comment 7 Mart Raudsepp gentoo-dev 2014-09-02 08:30:53 UTC
(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
Comment 8 Mart Raudsepp gentoo-dev 2014-09-02 08:40:32 UTC
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...
Comment 9 Ian Stakenvicius (RETIRED) gentoo-dev 2014-09-02 15:34:09 UTC
(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?
Comment 10 Jory A. Pratt gentoo-dev 2017-08-26 17:55:52 UTC
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