Vadim, please, review this request.

it looks much better. However, may I ask you to do one more thing, especially because the current ffmpeg wrapper already looks ugly because of all those #if's? Namely, wouldn't it be more elegant to put the following definition in the beginning of impl file?

#if LIBAVCODEC_BUILD >= CALC_FFMPEG_VERSION(54,25,0)
typedef AVCodecID CodecID;
#endif

so that most of the changes are not needed.

@vpisarev, if we making a typedef then it will be better to use own name instead of redefining an old ffmpeg's name. Otherwise it might become a problem if some version of ffmpeg adds a compatibility typedef/define for the same identifier.

 #if LIBAVCODEC_BUILD >= CALC_FFMPEG_VERSION(54,25,0)
 typedef AVCodecID CvCodecID;
 #else
 typedef CodecID CvCodecID;
 #endif

ok, let's do it this way; it's still better than the #if's.

Yes but that would mean we would have to redefine all the CODEC_ID* constants to AV_CODEC_ID* as well ... or do we add a define for that as well?

This is a show stopper.

It means that any rebuild of existing code (as in dpkg-buildpackage -rfakeroot -b) fails when attempting
to rebuild current packages.

This means opencv is dead in the water for every new release of every distro.

Currently attempted rebuilds for alpha + beta releases of Debian, Ubuntu, RedHat opencv packages fail, because ffmpeg uplevel versions are already rolled into these distros.

This means opencv will be flagged as broken and dropped from shipping. (Shudder...)

Maybe a brute force fix is in order. Simply release opencv-2.4.5 with all structure field renames done.

Then distros choosing to deliver opencv pre-2.4.5 would have to work out the dependencies to force the currect downlevel version of ffmpeg to be installed.

Then new releases of distros will just work.

shachibista, I think, it makes sense. So far I can see just 2 or 3 such CODEC_ID* occurrences in our ffmpeg wrapper.

David, since those issues with ffmpeg appear regularly, let me express my opinion regarding this.

It's not our fault that

1. ffmpeg changes API in an incompatible way every few weeks (if we had more stable in terms of API alternative to ffmpeg, we would switch to it immediately)
   and at the same time
2. the distros vendors seem to be fine with such development style and rush to put in the latest and greatest versions of ffmpeg.

We are not going to do anything special regarding this problem.

As open-source project we have our own release schedule, limited resources (as usual), priorities etc. OpenCV is not Gnome, instant messaging client or any other mission-critical component of a linux distro. This is special purpose software and many people download latest versions and build it themselves. We ourselves mostly use Ubuntu LTS, Android, OSX, iOS, Windows and make sure OpenCV builds and runs there well.
We consider this bug as normal priority bug, not show stopper, not even a high-priority bug. If distro vendors think otherwise, they can exclude opencv, or apply the proposed patch or do whatever they want.
As soon as the patch is updated, we will put it in. I'd rather wait a bit and put the polished patch into OpenCV and thus simplify further support rather than put anything into the library immediately in order to satisfy everybody, but because of this turn OpenCV into unmanageable spaghetti of #ifdef's.

Agreed. Simplified future support is a must, so I'll look for the patch in the future.

About the patch. Let me know it's form, will it be a .patch file or the actual source of opencv patched.

Also I'm currently pulling against the git://code.opencv.org/opencv.git link.

Let me know if this is the correct repository to pull against.

Thanks.

If I pull using git://code.opencv.org/opencv.git - let me know if the patches mentioned above will show up in the normal repository... or... do I have to pull from somewhere else, like https://github.com/Itseez/opencv for example.

Thanks.

https://github.com/Itseez/opencv is a mirror of git://code.opencv.org/opencv.git. Normally there is no difference from where to pull.

#756 is merged.