FFMpeg strikes (again)
December 5, 2008 4:04 pm GeneralTrying to build VXL so that I can test out OpenGazer – neither are packaged in Ubuntu – I get this error:
[ 89%] Building CXX object contrib/brl/bbas/vidl2/CMakeFiles/vidl2.dir/vidl2_ffmpeg_istream.o In file included from /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream.cxx:24: /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:25:28: error: ffmpeg/swscale.h: No such file or directory In file included from /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream.cxx:24: /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:68: error: ISO C++ forbids declaration of ‘SwsContext’ with no type /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:68: error: expected ‘;’ before ‘*’ token /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx: In constructor ‘vidl2_ffmpeg_istream::pimpl::pimpl()’: /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:38: error: class ‘vidl2_ffmpeg_istream::pimpl’ does not have any field named ‘sws_context_’ /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx: In member function ‘virtual vidl2_frame_sptr vidl2_ffmpeg_istream::current_frame()’: /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:348: error: ‘struct vidl2_ffmpeg_istream::pimpl’ has no member named ‘sws_context_’ /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:349: error: ‘struct vidl2_ffmpeg_istream::pimpl’ has no member named ‘sws_context_’ /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:352: error: ‘SWS_BILINEAR’ was not declared in this scope /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:353: error: ‘sws_getCachedContext’ was not declared in this scope /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:355: error: ‘struct vidl2_ffmpeg_istream::pimpl’ has no member named ‘sws_context_’ /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:363: error: ‘struct vidl2_ffmpeg_istream::pimpl’ has no member named ‘sws_context_’ /home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:366: error: ‘sws_scale’ was not declared in this scope make[2]: *** [contrib/brl/bbas/vidl2/CMakeFiles/vidl2.dir/vidl2_ffmpeg_istream.o] Error 1 make[1]: *** [contrib/brl/bbas/vidl2/CMakeFiles/vidl2.dir/all] Error 2 make: *** [all] Error 2
To anyone who has ever had to use ffmpeg as a build dependency, errors like this are commonplace – FFMpeg’s developers have adopted a position that copying individual SVN revisions into your product is the best way to use the library, and that releases and API stability are for wusses.
The end result for me is that I can’t build this library, and I have no idea how to go about fixing it. I do have ffmpeg, libavcodec-dev and the other ffmpeg libraries and headers installed (with the charmingly user-friendly and distribution-independent version number “3:0.svn20080206-12ubuntu3”) but they’re not the right version, I don’t know what is the right version, and even if I did, I wouldn’t know how to install the right version in a way that wouldn’t break a bunch of applications.
Is this stuff really that hard to get right?
December 5th, 2008 at 4:28 pm
Dude, I feel you on this one. I have had more frustrations with ffmpeg packages than I would have liked, mostly the notorious syntax changes that make me re-think scripting anything with ffpmeg in the loop.
Boo!
December 5th, 2008 at 4:39 pm
One word “fork”.
I know that “forking” is a bad practice, but I have to agree that this situation is bad and in my humble opinion the best solution is to fork.
In fact the proposed solution by the developers themselves is forking. Putting a snapshot in your tree is nothing more then creating a yaslffmpegf (yet another static linked ffmpeg fork) library. What I propose is to create a site put the code there and continue development with a stable API and with real releases that everyone can depend on.
December 5th, 2008 at 5:10 pm
Hi bolsh
The same problem occurs when I build GEGL from SVN on Fedora. In your case, the fix would be to find out which directory the header resides on your distribution and fix the #include for this file:
/home/dneary/src/vxl-1.11.0/contrib/brl/bbas/vidl2/vidl2_ffmpeg_istream_v2.txx:25:28: error: ffmpeg/swscale.h: No such file or directory
December 5th, 2008 at 5:13 pm
We had the same problem with Moonlight.
What we ended up doing for our project was give users the actual revision number that we had tested against and every time a build broke, point them to those instructions.
Far from optimal.
December 5th, 2008 at 5:39 pm
I’m curious… why don’t applications like this (and aforementioned Moonlight) use gstreamer, and are therefore isolated from this ffmpeg insanity?
December 5th, 2008 at 6:11 pm
Well, the error is actually pretty simple:
error: ffmpeg/swscale.h: No such file or directory
thanks to the multiple different versions of ffmpeg floating around, and different distribution policies, the ffmpeg headers can show up in lots of different places. Find out where your distro actually keeps swscale.h, and patch the build to look for it there. You may have to fix some other similar issues, but doing that should basically work.
However, overall, yes it is that hard. The ffmpeg guys really *do* break API compatibility all the time, they’re not joking. So you can either keep a static copy of it in every fricking app that uses it, or build against the system one and hope it keeps working, which it probably won’t. Neither’s a good choice. We have a selection of both, in Mandriva.
December 5th, 2008 at 6:17 pm
@Victor
It’s the consensus of the ffmpeg developers that “nobody but Michael passes the ‘fork test'”. Who are you going to recruit to work on this new ffmpeg. None of the current developers seem to want to deal with the hassle of releases.
If you want a stable interface to ffmpeg probably the best way to go is gstreamer-ffmpeg.
December 5th, 2008 at 6:38 pm
Just install libswscale-dev.
Cheers
December 5th, 2008 at 6:41 pm
Also, make sure you have
libswscale-dev installed
on ubuntu that will put the header in /usr/include/ffmpeg/swscale.h
December 6th, 2008 at 12:26 pm
It amazes me that anyone still develops software against FFMPEG rather than GStreamer or other multimedia libraries with a sane release process. 🙂
December 7th, 2008 at 12:24 pm
Now now there Dave, just remember that all good apps statically link to ffmpeg.
December 7th, 2008 at 5:57 pm
The other problem with ffmpeg is that the various distributions that distribute it refuse to use the embedded version of ffmpeg into the various packages, but want to use a single version for everyone.. And this will guarantee pain.
December 8th, 2008 at 8:23 pm
This is a general problem with interface versioning and not exclusive to ffmpeg. I use FFmpeg a lot, and it’s changes are not exceedingly frequent or annoying IMO. People are claiming gstreamer’s API is stable, but I remember in Phonon planning, KDE devs complaining that gstreamer would not guarantee a stable interface. And what is to prevent someone trying to build gst-ffmpeg to get their app to work from running into the same problem? So, that is not the solution. A software release is simply a check point in time with little guarantees about scarcity of bugs or build problems. Therefore, a Subversion revision number in a project where policy on trunk head is very strict with the more significant patches getting mailing list review is just as valid. I recommend someone trying to build a project against FFmpeg that does not include a snapshot or revision number to grab a revision from a week or two prior to the date of the app’s release. I like Moonlight’s solution; I will start doing that. I think most complaints here are about things changing and breaking. Well, I have learned that is quite the norm as a FOSS developer. Yeah, it sucks to deal with, but I try to maintain hope that it is just a sign of things evolving and progressing.
December 9th, 2008 at 5:01 am
[…] discovered surprisingly few sites dedicated to hating FFmpeg. These stood out: FFMpeg strikes (again) and ffmpeg sucks. One comment even pointed out that there are no ffmpegsucks.tld domains registered […]
December 9th, 2008 at 12:42 pm
so the ubuntu ffmpeg package lacks swscale.h in the correct place (or vxl looks in the wrong place or doesnt check for swscale.h during configure), and you blame upstream ffmpeg?