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 778283 - gst-libav 1.8.3 loses encoders/decoders vs 1.8.2 when built with system ffmpeg 2.8.10
gst-libav 1.8.3 loses encoders/decoders vs 1.8.2 when built with system ffmpe...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
1.8.3
Other Linux
: Normal normal
: 1.8.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-07 12:49 UTC by Iain Lane
Modified: 2018-01-15 11:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decoder changes (865 bytes, patch)
2017-02-07 12:50 UTC, Iain Lane
none Details | Review
encoder changes (865 bytes, text/plain)
2017-02-07 12:50 UTC, Iain Lane
  Details
decoder changes (1.73 KB, text/plain)
2017-02-07 12:52 UTC, Iain Lane
  Details
Like this? I moved to enumerating them for < 3.0. (3.21 KB, patch)
2017-02-08 13:41 UTC, Iain Lane
none Details | Review
avaudenc/dec: Don't do range comparisons against AV_CODEC_ID_PCM_S16BE_PLANAR for < 3.0 (3.25 KB, patch)
2017-02-08 14:06 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Iain Lane 2017-02-07 12:49:12 UTC
Someone reported this on Launchpad at http://pad.lv/1661842

The decoders for wma/tta/ape/others are missing, as well as some encoders too. Will attach the diff.

It was introduced with 70c281b545a383d45ec2fca296ce2387e1eac59e. The problem is that in 2.8.10, we have "AV_CODEC_ID_PCM_S16BE_PLANAR = MKBETAG('P','S','P',16)" - with 3.2 it changed to a different (sequential) value, so things are okay there. It's not safe to do range comparisons on it for 2.8. It's this part:

+    /* no quasi codecs, please */
+    if […]
+        (in_plugin->id >= AV_CODEC_ID_PCM_S8_PLANAR &&
+            in_plugin->id <= AV_CODEC_ID_PCM_S16BE_PLANAR)) {

That causes these to be thrown out.

Any suggestion for how to fix? Maybe just don't do this on old libavcodec?
Comment 1 Iain Lane 2017-02-07 12:50:37 UTC
Created attachment 345110 [details] [review]
decoder changes
Comment 2 Iain Lane 2017-02-07 12:50:57 UTC
Created attachment 345111 [details]
encoder changes
Comment 3 Iain Lane 2017-02-07 12:52:21 UTC
Created attachment 345112 [details]
decoder changes
Comment 4 Sebastian Dröge (slomo) 2017-02-08 09:37:38 UTC
Do you want to provide a patch (only against 1.8 branch)? Just list the values in question explicitly instead of checking the range.
Comment 5 Iain Lane 2017-02-08 13:41:18 UTC
Created attachment 345218 [details] [review]
Like this? I moved to enumerating them for < 3.0.

Don't do range comparisons against AV_CODEC_ID_PCM_S16BE_PLANAR for < 3.0

Prior to ffmpeg 3.0, this constant had a specified value. Excluding all
plugins in a range bounded by this value was throwing out plugins that
we want to keep.

Instead switch to enumerating the values to exclude, for < 3.0.
Comment 6 Sebastian Dröge (slomo) 2017-02-08 14:06:18 UTC
Created attachment 345220 [details] [review]
avaudenc/dec: Don't do range comparisons against AV_CODEC_ID_PCM_S16BE_PLANAR for < 3.0

Prior to ffmpeg 3.0, this constant had a specified value. Excluding all
plugins in a range bounded by this value was throwing out plugins that
we want to keep.

Instead switch to enumerating the values to exclude, for < 3.0.
Comment 7 Sebastian Dröge (slomo) 2017-02-08 14:07:27 UTC
Yes, except that you broke the compilation with the included ffmpeg version.
I fixed that.

Attachment 345220 [details] pushed as e1b4116 - avaudenc/dec: Don't do range comparisons against AV_CODEC_ID_PCM_S16BE_PLANAR for < 3.0
Comment 8 Sebastian Dröge (slomo) 2017-02-08 14:07:57 UTC
1.10 requires 3.0, so this is only going to be in 1.8
Comment 9 Iain Lane 2017-02-08 15:21:10 UTC
Thanks, and sorry for that
Comment 10 Sebastian Dröge (slomo) 2017-02-08 15:38:37 UTC
No problem, sorry for letting that break 1.8.3 and causing you to have a broken version in the xenial updates
Comment 11 Sebastian Dröge (slomo) 2017-02-08 15:42:38 UTC
Btw, if you build with a different ffmpeg release series (i.e. 2.8/2.9 while the release ships with 3.0, or 3.0 while the release ships with 3.1) than included in the release, I'd recommend that you do some more testing. We don't really support building with different ffmpeg versions.
Comment 12 Tim-Philipp Müller 2018-01-13 12:11:40 UTC
ping?
Comment 13 Iain Lane 2018-01-15 09:17:04 UTC
(In reply to Tim-Philipp Müller from comment #12)
> ping?

I think this is RESOLVED FIXED? Reopen if I'm missing something.
Comment 14 Tim-Philipp Müller 2018-01-15 11:10:59 UTC
Ah yes, sorry. Didn't see that the patch was committed.