FFMpeg strikes (again)

4:04 pm General

Trying 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?

15 Responses

  1. Duane Says:

    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!

  2. Victor Bogado Says:

    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.

  3. Mukund Says:

    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

  4. Miguel de Icaza Says:

    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.

  5. Craig Says:

    I’m curious… why don’t applications like this (and aforementioned Moonlight) use gstreamer, and are therefore isolated from this ffmpeg insanity?

  6. Adam Williamson Says:

    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.

  7. Alex Says:

    @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.

  8. blibx Says:

    Just install libswscale-dev.

    Cheers

  9. Alex Says:

    Also, make sure you have
    libswscale-dev installed
    on ubuntu that will put the header in /usr/include/ffmpeg/swscale.h

  10. Sam Morris Says:

    It amazes me that anyone still develops software against FFMPEG rather than GStreamer or other multimedia libraries with a sane release process. :)

  11. Chris S. Says:

    Now now there Dave, just remember that all good apps statically link to ffmpeg.

  12. Tester Says:

    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.

  13. Dan Dennedy Says:

    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.

  14. Does FFmpeg Actually Suck? | Breaking Eggs And Making Omelettes Says:

    [...] 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 [...]

  15. noname Says:

    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?