Added central compatibility header file, which enables blender to compile
against very old ffmpeg versions as well as very new versions using the
*NEW* API. (Old API functions are simulated using macros and inline functions)
Added a whole lot of additional checks, tested against 6 different versions
down the timeline, hopefully, now finally all is well.
* removed a lot of old cruft code for ancient ffmpeg versions
* made it compile again against latest ffmpeg / libav GIT
(also shouldn't break distro ffmpegs, since those API changes
have been introduced over a year ago. If it nevertheless breaks,
please send me an email)
FFMPEG was reallocating buffers it didn't own and wasn't allowed to. This workaround should work now flawlessly.
Also fixing a bug regarding unpacking sounds, the UI stated unpacking to //audio/filename while it was unpacking to //sounds/filename
* Adding play method to the device classes to play back a reader (not used yet, preparation for a later feature).
* Using a linear resampler in case SRC is disabled.
* [#25638] 'Insufficient thread locking' for sounds
- Actually a workaround for an msvc bug, msvc STL containers are buggy
* [#25922] Sound does not play in BlenderPlayer(r34579)
- Windows OpenAL doesn't seem to have clear context error state on initialising
This fixes a rather subtle seeking issue with ffmpeg and Sony
XDCAM-footage.
Problem is: MPEG2 streams within an MP4 container can contain a start
time - at several places. There is a starttime within the video
and audio streams and one within the container.
FFMpeg commandline tool only uses the container starttime and we used
the stream starttime.
The world would be a better place, if those two timestamps always match
up, since in XDCAM-footage those two starttimes differ in 4
frames - and the container has the right one.
We now always use the container start time as ffmpeg commandline tool
does (in the hope, that there is a good explaination for this and this
is the right thing(tm) to do).
I tested this also with HDV footage, which seems to work with the new
code, too.
Additional fix: disabled seek_by_bytes again, since it will only work
correctly, if ffmpeg guessed the HDV bitrate right (which it doesn't).
If you have seeking issues with HDV and have an older version of ffmpeg
installed, please upgrade, newer versions have some fixes in them.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
Reported by Guy Smith.
MSVC-compiled code would fall over iterator decrease on empty list. Shortest snippet to redo: http://www.pasteall.org/15408/cpp
See also http://www.pasteall.org/15409/cpp for list.end() behaviour on MSVC. Thanks to Jörg Müller for assistance.
