Created attachment 332718 [details] build.log See attached build.log and emerge --info. I'm not sure if this is related to ffmpeg-0.10.X vs ffmpeg-1.0.X (API breakage) or ffmpeg vs libav. I'll try to rebuild against ffmpeg-0.10.X and report back then.
Created attachment 332720 [details] emerge --info
Might be a mater of different includes. URLProtocol is actually *new* API and is already present in ffmpeg-0.10.x.
compiles fine against ffmpeg-0.10.6 but because of comment #2, I didn't set "BLOCKS 417677 and 443230". Can someone with libav installed test compilation against the old and new API?
(In reply to comment #3) > compiles fine against ffmpeg-0.10.6 but because of comment #2, I didn't set > "BLOCKS 417677 and 443230". Can someone with libav installed test > compilation against the old and new API? Clarify: are *you* using libav or ffmpeg ? On the other hand, 'error: ‘AVCodecContext’ has no member named ‘palctrl’' actually is due to API that got removed in ffmpeg 1.0 - check the comment in 0.10 avcodec.h.
(In reply to comment #4) > (In reply to comment #3) > > compiles fine against ffmpeg-0.10.6 but because of comment #2, I didn't set > > "BLOCKS 417677 and 443230". Can someone with libav installed test > > compilation against the old and new API? > > Clarify: are *you* using libav or ffmpeg ? > > On the other hand, 'error: ‘AVCodecContext’ has no member named ‘palctrl’' > actually is due to API that got removed in ffmpeg 1.0 - check the comment in > 0.10 avcodec.h. I am using ffmpeg. Usually 1.X but if I downgrade to 0.10.X, the compilation works. However I don't even know which version of libav the gstreamer-plugin is made for.
(In reply to comment #5) > I am using ffmpeg. Usually 1.X but if I downgrade to 0.10.X, the compilation > works. However I don't even know which version of libav the gstreamer-plugin > is made for. It is unfortunately made for their own private copy of libav they keep in their repository. Logs show they've since updated to a more recent copy of libav, and removed palctrl. 1.0.4 still doesn't built with ffmpeg-1.0.1 though.
http://anonscm.debian.org/gitweb/?p=pkg-gstreamer/gst-libav1.0.git;a=tree;f=debian/patches;h=4fede98fb158845bbb4dd0e78a5922ac47e5926d;hb=refs/heads/debian-experimental This fixes it, at least for libav.
I tried the mentioned patches from debian and it fails with another error: gstavcodecmap.c:30:38: fatal error: libavutil/channel_layout.h: No such file or directory mentioned line is introduced here: http://anonscm.debian.org/gitweb/?p=pkg-gstreamer/gst-libav1.0.git;a=blob;f=debian/patches/03_git-2012-12-18.patch;h=cc6468f66a3e44124f6f2db11a667637ea9a439e;hb=refs/heads/debian-experimental#l2020 The file "channel_layout.h" is not included in ffmpeg-1.0.1: kripton@miramis ~ $ equery f ffmpeg | grep -i layout kripton@miramis ~ $
As said you are supposed to use libav.
(In reply to comment #9) > As said you are supposed to use libav. I know. However, until now the two remained API-compatible ... Oh, I just found out that the file "/usr/include/libavutil/audioconvert.h" from ffmpeg seems to have the correct content. However, when on changing the include-line, I get this: gstavcodecmap.c:163:59: warning: ‘enum AVPixelFormat’ declared inside parameter list [enabled by default] gstavcodecmap.c:163:59: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] gstavcodecmap.c: In function ‘gst_ffmpeg_video_set_pix_fmts’: gstavcodecmap.c:169:3: error: invalid use of undefined type ‘enum AVPixelFormat’ gstavcodecmap.c:169:20: error: dereferencing pointer to incomplete type gstavcodecmap.c:190:10: error: dereferencing pointer to incomplete type gstavcodecmap.c:191:48: error: dereferencing pointer to incomplete type gstavcodecmap.c:196:9: error: increment of pointer to unknown structure gstavcodecmap.c:196:5: error: arithmetic on pointer to an incomplete type gstavcodecmap.c: In function ‘gst_ffmpeg_codecid_to_caps’: gstavcodecmap.c:797:9: warning: ‘sub_id’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:1502) [-Wdeprecated-declarations] gstavcodecmap.c: In function ‘gst_ffmpeg_codectype_to_video_caps’: gstavcodecmap.c:2179:7: warning: passing argument 2 of ‘gst_ffmpeg_video_set_pix_fmts’ from incompatible pointer type [enabled by default] gstavcodecmap.c:163:1: note: expected ‘const enum AVPixelFormat *’ but argument is of type ‘const enum PixelFormat *’ gstavcodecmap.c: In function ‘gst_ffmpeg_caps_with_codecid’: gstavcodecmap.c:2857:9: warning: ‘sub_id’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:1502) [-Wdeprecated-declarations] make[3]: *** [libgstlibav_la-gstavcodecmap.lo] Fehler 1 make[3]: Leaving directory `/var/tmp/portage/media-plugins/gst-plugins-libav-1.0.3/work/gst-libav-1.0.3/ext/libav' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/var/tmp/portage/media-plugins/gst-plugins-libav-1.0.3/work/gst-libav-1.0.3/ext' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/var/tmp/portage/media-plugins/gst-plugins-libav-1.0.3/work/gst-libav-1.0.3' make: *** [all] Fehler 2
AVPixelFormat seems to be just PixelFormat in ffmpeg.
I've removed --with-system-libav from configure parameters and compilation was successfull. ... and works fine # lsof | grep totem | grep libav totem 1033 koprut mem REG 253,0 7809072 586691 /usr/lib64/gstreamer-1.0/libgstlibav.so
(In reply to comment #12) > I've removed --with-system-libav from configure parameters and compilation > was successfull. > > ... and works fine > :roll: well, duh... And just what do you 'think' the build system does in such case ?
(In reply to comment #13) > (In reply to comment #12) > > I've removed --with-system-libav from configure parameters and compilation > > was successfull. > > > > ... and works fine > > > :roll: well, duh... > And just what do you 'think' the build system does in such case ? It uses bundled libav, and statically links it into libgstlibav.so. What do _you_ thought? Ebuild should check if system was built against ffmpeg instead of libav and disable --with-system-libav key in such case.
:roll: The whole point of '--with-system-libav' is to *not* use the bundled lib. The problem discussed in this bug is whether to make libav the dep instead of the virtual or see if patching the plugin to use ffmpeg instead is feasible. So, you've discovered nothing but the obvious.
Any progress on getting this bug resolved? There has now been security alerts posted about ffmpeg prior to 1.02. And libav-9 compatibility is currently a mess in the portage tree. TIA
I've added a gst-plugins-libav-1.1.0_pre20130128 snapshot, hacked to be compatible with gstreamer-1.0.5. It works with libav-9 and hopefully should work with ffmpeg-1.1 too. It's masked, and should be unmasked together with the new libav and ffmpeg. But fixing gst-plugins-ffmpeg-0.10.x will be much more difficult: gstreamer upstream no longer cares about the 0.10 series, and for libav-9 support, we would need to backport many heavy patches two major gst releases into the past (from 1.1 to 0.10). +*gst-plugins-libav-1.1.0_pre20130128 (03 Feb 2013) + + 03 Feb 2013; Alexandre Rostovtsev <tetromino@gentoo.org> + gst-plugins-libav-1.0.3.ebuild, gst-plugins-libav-1.0.5.ebuild, + +gst-plugins-libav-1.1.0_pre20130128.ebuild, + +files/gst-plugins-libav-1.1.0_pre20130128-gbr-color.patch: + Add gst-plugins-libav-1.1 prerelease for libav-9 and ffmpeg-1.1 compatibility + (bug #423717). Pin gst-plugins-libav-1.0.x to libav-0.8 and ffmpeg-0.10. + 03 Feb 2013; Alexandre Rostovtsev <tetromino@gentoo.org> package.mask: + Add media-plugins/gst-plugins-libav-1.1 prereleases to libav package.mask + (bug #423717).
Thanks for the "hacked" ebuild. Compiles fine against media-video/ffmpeg-1.1.1, no testing done though
