GNOME Bugzilla – Bug 720986
vp9dec: Don't build with libvpx earlier than 1.3.0 because of non-final bitstream
Last modified: 2013-12-26 08:02:21 UTC
With the latest gst-plugins-good from git, on Fedora 19, I get this error: make[3]: Entering directory `/home/blong/gst/git/gst-plugins-good/ext/vpx' CC libgstvpx_la-gstvp9dec.lo gstvp9dec.c: In function 'gst_vp9_dec_handle_frame': gstvp9dec.c:537:12: error: 'VPX_IMG_FMT_I422' undeclared (first use in this function) case VPX_IMG_FMT_I422: ^ gstvp9dec.c:537:12: note: each undeclared identifier is reported only once for each function it appears in gstvp9dec.c:540:12: error: 'VPX_IMG_FMT_I444' undeclared (first use in this function) case VPX_IMG_FMT_I444: ^ If I remove `libvpx-devel`, the build error goes away. The error also goes away before commit c62229ae2dc017e461fab2aac8f68051677b3b5f (vpx: Mark VP9 support as non-experimental). What's odd is that VPX_IMG_FMT_I444 should be defined in libvpx 1.2.0 (I checked their git repo and compared tags). I'll try to track this down more.
Oh wait, I think this was added in 1.3: [blong@blong-desktop libvpx]$ git log v1.2.0 -G VPX_IMG_FMT_I444 [blong@blong-desktop libvpx]$ git log v1.3.0 -G VPX_IMG_FMT_I444 commit da58436f43095743d77f7ee84500fd22851317d8 Author: John Koleszar <jkoleszar@google.com> Date: Mon May 6 15:52:06 2013 -0700 Subsampling aware allocs and bitstream Make framebuffer allocations according to the chroma subsamping factors in use. A bit is placed in the raw part of the frame header for each of the two subsampling factors. This will be moved in a future commit to make them part of the TBD feature set bits, probably only set on keyframes, etc. Change-Id: I59ed38d3a3c0d4af3c7c277617de28d04a001853 commit 8dd8287e16d3afc037a4ad5a18863107868ff5ef Author: John Koleszar <jkoleszar@google.com> Date: Mon May 6 11:01:35 2013 -0700 Y4M input support for 4:2:2, 4:4:4, 4:4:4:4 Adds a new experiment CONFIG_NON420 that allows other chroma subsamplings to be passed to the codec. This commit allows the data to be passed from a y4m input file through vpxenc to the codec, where they're currently rejected. Later commits will finish support for this inside the codec. Change-Id: Ib3aac604d8cad9e24cef395fa1067f16ba7e8e43
It's easy to make a patch to configure.ac that requires 1.3.0, but I wonder if it's worth it to leave the check at 1.1.0, and have another check for 1.3.0 before enabling vp9. I don't actually need this (I just want it to compile), but it seems like Fedora 19 is new enough that being able to build vp8dec would be useful.
How do you even get the VP9 code compiled without having libvpx >= 1.3? The VP9 code was only added with 1.3
(In reply to comment #3) > How do you even get the VP9 code compiled without having libvpx >= 1.3? The VP9 > code was only added with 1.3 I think that's the error. We only check for libvpx >= 1.1.0, and then try to build vp9dec.
It checks for the vpx_codec_vp9_cx_algo and vpx_codec_vp9_dx_algo symbols in libvpx.so and only enables the VP9 code if those are available.
Can you provide your config.log?
Created attachment 264809 [details] [review] Require libvpx >= 1.3.0 to build vp9dec This patch disables vp9dec and vp9enc if we don't have libvpx >= 1.3.0, but stills allows vp8dec and vp8enc to be built with libvpx >= 1.1.0.
(In reply to comment #5) > It checks for the vpx_codec_vp9_cx_algo and vpx_codec_vp9_dx_algo symbols in > libvpx.so and only enables the VP9 code if those are available. Hm that's a good point. I wonder why it doesn't like this.
Created attachment 264810 [details] config.log
It looks like I'm using libvpx from the Chromium repo, so it's possible they built it with weird options, like enabling vp9 even though it was still experimental at the time.
Well, apparently those symbols exist in your library for whatever reason :) I still applied your patch because it is correct for a different reasons, see the changed commit message. commit c0852624f7591d19cd44013e729e49f24473b12d Author: Brendan Long <b.long@cablelabs.com> Date: Mon Dec 23 12:23:27 2013 -0600 vp9dec: Require vpx >= 1.3.0 for building vp9dec and vp9enc Previous versions did not have a stable bitstream for VP9. https://bugzilla.gnome.org/show_bug.cgi?id=720986
Sounds good to me. In case you're curious, downgrading to Fedora's normal libvpx-devel also fixes it, so it's definitely something about how the Chromium developers were building it.