GNOME Bugzilla – Bug 681362
missing plugins install: ignore the mpegaudioversion field
Last modified: 2015-02-13 14:26:58 UTC
Created attachment 220520 [details] [review] 0001-missing-plugins-Remove-the-mpegaudioversion-field.patch See: https://bugzilla.redhat.com/show_bug.cgi?id=680809 The mpegaudioversion field is a duplicate of the mpegversion field, and shouldn't be required to find a matching decoder.
It isn't a duplicate of the mpegversion field. For "MP3" the mpegversion field is always 1, the mpegaudioversion field describes the actual version of MP1/2/3: 1 (ISO/IEC 11172-3), 2 (ISO/IEC 13818-3) or 2.5. http://www.mp3-tech.org/programmer/frame_header.html What's the problem here?
(In reply to comment #1) > What's the problem here? It's not an attribute exported by the decoder, so it doesn't get unfolded in the RPM provides, so it cannot get queried for using a full-string match, and thus will not get installed.
That's exactly one of the reasons why you shouldn't use string operations to detect caps compatibility. There might in theory be decoders that only support one or two of the mpegaudioversions, and in that case you might not want this decoder for this specific case.
(In reply to comment #3) > That's exactly one of the reasons why you shouldn't use string operations to > detect caps compatibility. We know. And repeating it over and over won't make it suddenly go away. > There might in theory be decoders that only support one or two of the > mpegaudioversions, and in that case you might not want this decoder for this > specific case. The important part here being "in theory".
We could provide a little gst-caps-util command line utility in core to do caps operations on input caps passed as string arguments, if that would help.
Let's WONTFIX this. It needs to be done properly in the installer application. We can provide ways to help the installer with that if needed, as per comment #5. Possible patches here: https://bugzilla.redhat.com/show_bug.cgi?id=1135558