Created attachment 138535 [details] [review]
gstreamer-inspect-rpm-format.patch

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

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 ;)

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?

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.

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?

(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.

(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?

(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.

(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?

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?

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.)

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.

(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.

(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.

> 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)

Bastien, how shall we proceed now?

Oh well, then let's close this for now. It can always be better handled at the distro side IMHO