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 681362 - missing plugins install: ignore the mpegaudioversion field
missing plugins install: ignore the mpegaudioversion field
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-07 09:36 UTC by Bastien Nocera
Modified: 2015-02-13 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-missing-plugins-Remove-the-mpegaudioversion-field.patch (1.09 KB, patch)
2012-08-07 09:36 UTC, Bastien Nocera
none Details | Review

Description Bastien Nocera 2012-08-07 09:36:07 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.
Comment 1 Sebastian Dröge (slomo) 2012-08-07 09:38:14 UTC
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?
Comment 2 Bastien Nocera 2012-08-07 10:07:00 UTC
(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.
Comment 3 Sebastian Dröge (slomo) 2012-08-07 10:31:50 UTC
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.
Comment 4 Bastien Nocera 2012-08-07 12:37:39 UTC
(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".
Comment 5 Tim-Philipp Müller 2012-08-09 09:13:16 UTC
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.
Comment 6 Tim-Philipp Müller 2015-02-13 14:26:58 UTC
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