After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 588783 - [gst-inspect] Add RPM provides output
[gst-inspect] Add RPM provides output
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-07-16 14:54 UTC by Bastien Nocera
Modified: 2009-09-13 17:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gstreamer-inspect-rpm-format.patch (10.83 KB, patch)
2009-07-16 14:55 UTC, Bastien Nocera
rejected Details | Review

Description Bastien Nocera 2009-07-16 14:54:59 UTC
This allows us (since Fedora 10) to output a list of RPM provides that will be embedded into the RPM themselves. For example, for the schroedinger GStreamer plugin package:

$ rpm -q --provides gstreamer-plugins-schroedinger-1.0.7-1.fc11.x86_64
gstreamer0.10(decoder-video/x-dirac)()(64bit)  
gstreamer0.10(encoder-video/x-dirac)()(64bit)  
gstreamer0.10(encoder-video/x-mp4-part)()(64bit)  
gstreamer0.10(encoder-video/x-qt-part)()(64bit)  
libgstschro.so()(64bit)  
gstreamer-plugins-schroedinger = 1.0.7-1.fc11
gstreamer-plugins-schroedinger(x86-64) = 1.0.7-1.fc11

PackageKit will use the missing-plugins information from Totem and other apps to munge it into an RPM provides as above, and request that "provides" be installed.

Complete functionality also includes a helper script for RPM to include this metadata in the provides:
http://cvs.fedoraproject.org/viewvc/rpms/gstreamer/devel/gstreamer.prov?view=markup
Comment 1 Bastien Nocera 2009-07-16 14:55:43 UTC
Created attachment 138535 [details] [review]
gstreamer-inspect-rpm-format.patch
Comment 2 Sebastian Dröge (slomo) 2009-07-28 19:04:16 UTC
We have something similar for Debian/Ubuntu: http://svn.debian.org/viewsvn/pkg-gstreamer/unstable/gstreamer0.10/debian/gst-codec-info.c?revision=2275&view=markup

This also outputs the stuff in a custom format, used by the Debian infrastructure and provides some more information, like what elements are in there, what uri source/sinks are there and virtual package information to provide information if a audio sink, video sink, or something similar is there.

Also the caps for decoders are all in one line and put through gst_caps_do_simplify() to reduce the size.

It would probably make sense to define a format that satisfies RPM and the Debian infrastructure if this should be included in gst-inspect.



Example output for gst-plugins-base:

gstreamer:Version=0.10
gstreamer:Elements=adder, appsink, appsrc, audioconvert, audiorate, audioresample, audiotestsrc, cdparanoiasrc, decodebin, decodebin2, ffmpegcolorspace, gdpdepay, gdppay, giosink, giosrc, giostreamsink, giostreamsrc, libvisual_bumpscope, libvisual_corona, libvisual_infinite, libvisual_jakdaw, libvisual_jess, libvisual_lv_analyzer, libvisual_lv_scope, libvisual_oinksie, multifdsink, oggaviparse, oggdemux, oggmux, oggparse, ogmaudioparse, ogmtextparse, ogmvideoparse, playbin, playbin2, queue2, ssaparse, subparse, tcpclientsink, tcpclientsrc, tcpserversink, tcpserversrc, theoradec, theoraenc, theoraparse, uridecodebin, v4lsrc, videorate, videoscale, videotestsrc, volume, vorbisdec, vorbisenc, vorbisparse, vorbistag
gstreamer:Provides=gstreamer0.10-audiosource, gstreamer0.10-videosource, gstreamer0.10-visualization
gstreamer:URISources=appsrc, archive, burn, cdda, computer, dav, dav+sd, davs, davs+sd, dns-sd, ftp, gphoto2, localtest, network, obex, sftp, smb, ssh, trash
gstreamer:URISinks=appsink, archive, burn, computer, dav, dav+sd, davs, davs+sd, dns-sd, ftp, gphoto2, localtest, network, obex, sftp, smb, ssh, trash
gstreamer:Encoders=application/ogg; application/x-gdp; audio/x-vorbis; video/x-theora
gstreamer:Decoders=application/ogg; application/x-annodex; application/x-ass; application/x-ogg-avi; application/x-ogm-audio; application/x-ogm-text; application/x-ogm-video; application/x-ssa; application/x-subtitle; application/x-subtitle-mpl2; application/x-subtitle-sami; application/x-subtitle-tmplayer; audio/x-vorbis; video/x-theora
Comment 3 Sebastian Dröge (slomo) 2009-07-28 19:13:26 UTC
I should probably add that those gstreamer:Blabla fields are added to the binary package metadata that will be included in the package index and can be searched even if the package is not installed. But that's probably obvious ;)
Comment 4 Bastien Nocera 2009-07-28 19:18:59 UTC
gst-plugins-base is the most useless package to show as an example, to be honest. If it's not installed, then you're screwed already.

What's the output for, say, gst-ffmpeg, or gst-plugins-bad?

You also don't seem to handle:
- multi-lib (how does one know if a particular provides is for 64-bit or 32-bit),
- or codec version (say, playing a WMV9 file and installing the right decoder).
Is that the case?
Comment 5 Sebastian Dröge (slomo) 2009-07-28 19:31:14 UTC
Well, gst-plugins-base is a good example because it contains elements of all types ;)

Debian's multilib support is currently a bit suboptimal but it would work if the infrastructure supported it correctly. A Debian binary package must only contain files for one architecture so if a 32 bit application needs some decoder it will only search in the 32 bit packages.

The codec version that is supported by the elements is inside the caps. For gst-ffmpeg the decoders line would look like:

gstreamer:Decoders=application/gxf; application/mxf; application/x-ape; application/x-gst_ff-RoQ; application/x-gst_ff-avs; application/x-gst_ff-daud; application/x-gst_ff-ea; application/x-gst_ff-ffm; application/x-gst_ff-film_cpk; application/x-gst_ff-idcin; application/x-gst_ff-ipmovie; application/x-gst_ff-mm; application/x-gst_ff-mmf; application/x-gst_ff-nsv; application/x-gst_ff-nut; application/x-gst_ff-nuv; application/x-gst_ff-psxstr; application/x-gst_ff-smk; application/x-gst_ff-sol; application/x-gst_ff-vmd; application/x-gst_ff-voc; application/x-gst_ff-wc3movie; application/x-gst_ff-wsaud; application/x-gst_ff-wsvqa; application/x-shockwave-flash; application/x-yuv4mpeg, y4mversion=(int)2; audio/mpeg, mpegversion=(int)1, layer=(int)[ 1, 3 ]; audio/qcelp; audio/x-ac3; audio/x-adpcm, layout=(string){ 4xm, adx, ct, ea, ea-maxis-xa, ea-r1, ea-xas, g726, amv, dk3, dk4, ea-eacs, ea-sead, iss, quicktime, smjpeg, dvi, westwood, microsoft, sbpro2, sbpro3, sbpro4, swf, thp, xa, yamaha, ea-r3 }; audio/x-aiff; audio/x-alac; audio/x-dpcm, layout=(string){ interplay, roq, sol, xan }; audio/x-dts; audio/x-eac3; audio/x-ffmpeg-parsed-ape; audio/x-ffmpeg-parsed-musepack, streamversion=(int){ 7, 8 }; audio/x-flac; audio/x-gst_ff-mp3adu; audio/x-gst_ff-mp3on4; audio/x-gst_ff-sonic; audio/x-gst_ff-vmdaudio; audio/x-gst_ff-ws_snd1; audio/x-imc; audio/x-mace, maceversion=(int){ 3, 6 }; audio/x-mlp; audio/x-musepack, streamversion=(int)7; audio/x-nellymoser; audio/x-pn-realaudio, raversion=(int){ 8, 1, 2 }; audio/x-qdm2; audio/x-shorten; audio/x-truespeech; audio/x-tta; audio/x-ttafile; audio/x-vnd.sony.atrac3; audio/x-wma, wmaversion=(int){ 1, 2 }; image/bmp; image/jpeg; image/pbm; image/png; image/ppm; video/mpeg, mpegversion=(int){ 4, [ 1, 2 ] }, systemstream=(boolean)false; video/sp5x; video/x-3ivx; video/x-4xm; video/x-amv; video/x-apple-video; video/x-asus, asusversion=(int){ 1, 2 }; video/x-ati-vcr, vcrversion=(int)1; video/x-camtasia; video/x-cinepak; video/x-cirrus-logic-accupak; video/x-compressed-yuv; video/x-divx, divxversion=(int){ [ 4, 5 ], 3 }; video/x-dnxhd; video/x-dv, systemstream=(boolean)false; video/x-ffv, ffvversion=(int)1; video/x-flash-screen; video/x-flash-video, flvversion=(int)1; video/x-fraps; video/x-gst_ff-8bps; video/x-gst_ff-aasc; video/x-gst_ff-avs; video/x-gst_ff-camstudio; video/x-gst_ff-cavs; video/x-gst_ff-ffvhuff; video/x-gst_ff-flic; video/x-gst_ff-idcinvideo; video/x-gst_ff-interplayvideo; video/x-gst_ff-loco; video/x-gst_ff-mdec; video/x-gst_ff-mmvideo; video/x-gst_ff-pam; video/x-gst_ff-pgm; video/x-gst_ff-pgmyuv; video/x-gst_ff-qpeg; video/x-gst_ff-roqvideo; video/x-gst_ff-snow; video/x-gst_ff-vmdvideo; video/x-gst_ff-vqavideo; video/x-gst_ff-wnv1; video/x-gst_ff-xl; video/x-gst_ff-zmbv; video/x-h261; video/x-h263, variant=(string)itu; video/x-h264; video/x-huffyuv; video/x-indeo, indeoversion=(int){ 2, 3 }; video/x-intel-h263, variant=(string)intel; video/x-kmvc; video/x-mimic; video/x-mjpeg-b; video/x-msmpeg, msmpegversion=(int){ 41, 42, 43 }; video/x-msvideocodec, msvideoversion=(int)1; video/x-mszh; video/x-nuv; video/x-pn-realvideo, systemstream=(boolean)false, rmversion=(int){ 1, 2, 3, 4 }; video/x-qdrw; video/x-rle, layout=(string){ microsoft, quicktime }; video/x-smc; video/x-svq, svqversion=(int){ 1, 3 }; video/x-theora; video/x-truemotion, trueversion=(int){ 1, 2 }; video/x-ultimotion; video/x-vmnc; video/x-vp3; video/x-vp5; video/x-vp6; video/x-vp6-alpha; video/x-vp6-flash; video/x-wmv, wmvversion=(int){ 1, 2, 3 }; video/x-xan, wcversion=(int)3; video/x-xvid; video/x-zlib


If someone wants for example "video/x-msmpeg, msmpegversion=(int) 43" the caps would be compatible and it would be known that the package provides the required decoder.
Comment 6 Bastien Nocera 2009-07-28 20:06:46 UTC
Right, except that stuff like:
video/mpeg, mpegversion=(int){ 4, [ 1, 2 ] }, systemstream=(boolean)false;
makes it impossible to not have any intelligence in the front-end/package handling system.

In Fedora we transform it like so:
gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)  
gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=false)()(64bit)  
gstreamer0.10(decoder-video/mpeg)(mpegversion=4)(systemstream=false)()(64bit)  

So you don't need any intelligence in the front-end:
$(application) install "gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)"
will install the package that provides this requirement

> Debian's multilib support is currently a bit suboptimal but it would work if
> the infrastructure supported it correctly. A Debian binary package must only
> contain files for one architecture so if a 32 bit application needs some
> decoder it will only search in the 32 bit packages.

How do you know for which architecture your provides is for? Eg., if you have both 32-bit and 64-bit repos enabled, how do you know that you should install the 32-bit or the 64-bit package?
Comment 7 Sebastian Dröge (slomo) 2009-07-28 20:13:15 UTC
(In reply to comment #6)
> Right, except that stuff like:
> video/mpeg, mpegversion=(int){ 4, [ 1, 2 ] }, systemstream=(boolean)false;
> makes it impossible to not have any intelligence in the front-end/package
> handling system.
> 
> In Fedora we transform it like so:
> gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)  
> gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=false)()(64bit)  
> gstreamer0.10(decoder-video/mpeg)(mpegversion=4)(systemstream=false)()(64bit)  
> 
> So you don't need any intelligence in the front-end:
> $(application) install
> "gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)"
> will install the package that provides this requirement

Right, intelligence is needed in the front-end. If you don't add any intelligence there you will have very large codec informations. How would you display caps like "audio/mpeg,mpegversion=(int)[1,4],rate=(int)[16000,32000]"? By using 4*16000 different provide lines?

> > Debian's multilib support is currently a bit suboptimal but it would work if
> > the infrastructure supported it correctly. A Debian binary package must only
> > contain files for one architecture so if a 32 bit application needs some
> > decoder it will only search in the 32 bit packages.
> 
> How do you know for which architecture your provides is for? Eg., if you have
> both 32-bit and 64-bit repos enabled, how do you know that you should install
> the 32-bit or the 64-bit package?

The provides is stored together with the package for which it is. It's either for a 32 bit package or for a 64 bit package.
Comment 8 Bastien Nocera 2009-07-28 20:15:30 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Right, except that stuff like:
> > video/mpeg, mpegversion=(int){ 4, [ 1, 2 ] }, systemstream=(boolean)false;
> > makes it impossible to not have any intelligence in the front-end/package
> > handling system.
> > 
> > In Fedora we transform it like so:
> > gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)  
> > gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=false)()(64bit)  
> > gstreamer0.10(decoder-video/mpeg)(mpegversion=4)(systemstream=false)()(64bit)  
> > 
> > So you don't need any intelligence in the front-end:
> > $(application) install
> > "gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)"
> > will install the package that provides this requirement
> 
> Right, intelligence is needed in the front-end. If you don't add any
> intelligence there you will have very large codec informations. How would you
> display caps like "audio/mpeg,mpegversion=(int)[1,4],rate=(int)[16000,32000]"?
> By using 4*16000 different provide lines?

We ignore the rate (and a number of other properties), check the patch.

> > > Debian's multilib support is currently a bit suboptimal but it would work if
> > > the infrastructure supported it correctly. A Debian binary package must only
> > > contain files for one architecture so if a 32 bit application needs some
> > > decoder it will only search in the 32 bit packages.
> > 
> > How do you know for which architecture your provides is for? Eg., if you have
> > both 32-bit and 64-bit repos enabled, how do you know that you should install
> > the 32-bit or the 64-bit package?
> 
> The provides is stored together with the package for which it is. It's either
> for a 32 bit package or for a 64 bit package.

Right. We add that information ourselves in the RPM provides script anyway...

What's the use case for advertising elements in the provides?
Comment 9 Sebastian Dröge (slomo) 2009-07-28 20:19:04 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Right, except that stuff like:
> > > video/mpeg, mpegversion=(int){ 4, [ 1, 2 ] }, systemstream=(boolean)false;
> > > makes it impossible to not have any intelligence in the front-end/package
> > > handling system.
> > > 
> > > In Fedora we transform it like so:
> > > gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)  
> > > gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=false)()(64bit)  
> > > gstreamer0.10(decoder-video/mpeg)(mpegversion=4)(systemstream=false)()(64bit)  
> > > 
> > > So you don't need any intelligence in the front-end:
> > > $(application) install
> > > "gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit)"
> > > will install the package that provides this requirement
> > 
> > Right, intelligence is needed in the front-end. If you don't add any
> > intelligence there you will have very large codec informations. How would you
> > display caps like "audio/mpeg,mpegversion=(int)[1,4],rate=(int)[16000,32000]"?
> > By using 4*16000 different provide lines?
> 
> We ignore the rate (and a number of other properties), check the patch.

Ok, rate was a bad example (we ignore it too). But what about other fields of type range that are not ignored? :)

> > > > Debian's multilib support is currently a bit suboptimal but it would work if
> > > > the infrastructure supported it correctly. A Debian binary package must only
> > > > contain files for one architecture so if a 32 bit application needs some
> > > > decoder it will only search in the 32 bit packages.
> > > 
> > > How do you know for which architecture your provides is for? Eg., if you have
> > > both 32-bit and 64-bit repos enabled, how do you know that you should install
> > > the 32-bit or the 64-bit package?
> > 
> > The provides is stored together with the package for which it is. It's either
> > for a 32 bit package or for a 64 bit package.
> 
> Right. We add that information ourselves in the RPM provides script anyway...
> 
> What's the use case for advertising elements in the provides?

Missing plugin messages can also be posted on the bus for a specific element or for a specific uri sink or source. There are 5 possible "missing" types:
element, encoder, decoder, uri source and uri sink.


The gstreamer0.10-audiosink virtual package thing has the use case that some packages are depending on some audiosink and not an a specific one. That's not related to automatic codec installation.
Comment 10 Bastien Nocera 2009-07-28 20:23:42 UTC
(In reply to comment #9)
<snip>
> Ok, rate was a bad example (we ignore it too). But what about other fields of
> type range that are not ignored? :)

Which other ones? I couldn't find any such properties that would cause problems...

> > What's the use case for advertising elements in the provides?
> 
> Missing plugin messages can also be posted on the bus for a specific element or
> for a specific uri sink or source. There are 5 possible "missing" types:
> element, encoder, decoder, uri source and uri sink.
> 
> 
> The gstreamer0.10-audiosink virtual package thing has the use case that some
> packages are depending on some audiosink and not an a specific one. That's not
> related to automatic codec installation.

That's useful I guess. I can add that to the code.

If we were to output something like:
gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)
would you be able to process it to add as provides for your packages?
Comment 11 Sebastian Dröge (slomo) 2009-07-29 05:03:48 UTC
Well, I won't be able to use it if it outputs normalized and decoder-separated caps as I need a as small as possible format for Debian. People already complained that the current, simplified and combined caps use to much space.

This RPM stuff would only be used by packagekit by the packagekit rpm backend, right? Or would it be the GStreamer codec information format that is used by all packagekit backends?
Comment 12 Tim-Philipp Müller 2009-07-29 08:58:07 UTC
This normalised caps thing is broken by design.

(If you want this in gst-inspect for RPM, that's fine with me, I won't fight it, but I'm strongly opposed to establishing normalised caps as the recommended/standard way of doing this stuff for packages in general.)
Comment 13 Sebastian Dröge (slomo) 2009-07-29 09:45:54 UTC
FYI the packagekit apt backend uses GStreamer logic to find the package that provides the requested codec and also works on the package information I've written about above.

Btw, why do you want this in gst-inspect and can't have this as a separate program? I mean, it's only useful for those few systems that actually use RPM.
Comment 14 Bastien Nocera 2009-07-29 10:16:44 UTC
(In reply to comment #12)
> This normalised caps thing is broken by design.

It is. It's also a functional way of doing things.

> (If you want this in gst-inspect for RPM, that's fine with me, I won't fight
> it, but I'm strongly opposed to establishing normalised caps as the
> recommended/standard way of doing this stuff for packages in general.)

RPM provides can only do full string matching. How would one implement the functionality in an other way that would be acceptable to you?

(In reply to comment #13)
> FYI the packagekit apt backend uses GStreamer logic to find the package that
> provides the requested codec and also works on the package information I've
> written about above.
> 
> Btw, why do you want this in gst-inspect and can't have this as a separate
> program?

Because it means that there's less distribution specific code, which is always a good thing.

> I mean, it's only useful for those few systems that actually use RPM.

RPM is a required part of the LSB. So I'd argue that it would be used for any LSB compliant distribution.
Comment 15 Sebastian Dröge (slomo) 2009-07-29 10:25:37 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > This normalised caps thing is broken by design.
> 
> It is. It's also a functional way of doing things.

I could easily design a new codec + some element that handles it, which would then break your system if you're using normalized caps. What if some day there's a codec like

"bling/bla, majorversion=[1,100], minorversion=[0, 1000]"

and a decoder only supports major version [3,30] and minor versions [0,400] for each? You can't remove the fields then and you would have 27*400 caps lines.

> > (If you want this in gst-inspect for RPM, that's fine with me, I won't fight
> > it, but I'm strongly opposed to establishing normalised caps as the
> > recommended/standard way of doing this stuff for packages in general.)
> 
> RPM provides can only do full string matching. How would one implement the
> functionality in an other way that would be acceptable to you?

By not using RPM for the matching but by using something that uses GStreamer functionality to match the caps.

> (In reply to comment #13)
> > FYI the packagekit apt backend uses GStreamer logic to find the package that
> > provides the requested codec and also works on the package information I've
> > written about above.
> > 
> > Btw, why do you want this in gst-inspect and can't have this as a separate
> > program?
> 
> Because it means that there's less distribution specific code, which is always
> a good thing.

Well, it could be shipped as part of the packagekit RPM backend.

> > I mean, it's only useful for those few systems that actually use RPM.
> 
> RPM is a required part of the LSB. So I'd argue that it would be used for any
> LSB compliant distribution.

Sure that's many distributions but gst-inspect is also used on non Linux systems and Linux distributions that are not LSB compliant. I don't see why adding something RPM specific is a good idea here. Adding some generic format that can be useful for everybody is but I believe we won't find such format as our requirements are kind of disjoint.
Comment 16 Tim-Philipp Müller 2009-07-29 12:41:46 UTC
> RPM provides can only do full string matching.

You mean you can't even query/filter for all packages where the provides string contains e.g. 'gstreamer-0.10'? So you can only say 'give me all packages where the provides string is exactly $this'? If that is the case, you would need to extend or fix RPM IMHO. It would be enough to be able to query for a provides string prefix for example, which could be done by a 'dumb' filter, and the resulting strings could then be processed by something smarter.

Can that current system of yours handle additional fields - e.g. what do you do when you get video/mpeg,systemstream=false,mpegversion=2,foo=bar where field foo is unexpected and your system doesn't know about whether it's relevant or strippable? Can you still find the line with video/mpeg,systemstream=false,mpegversion=2? (decodebin/playbin would match those as compatible)
Comment 17 Sebastian Dröge (slomo) 2009-08-06 19:28:45 UTC
Bastien, how shall we proceed now?
Comment 18 Sebastian Dröge (slomo) 2009-09-13 17:52:17 UTC
Oh well, then let's close this for now. It can always be better handled at the distro side IMHO