- Sequencer dynamics: Now it's possible to change the output channels and the resampling quality also increased (previously maximum quality was 44,1 kHz)
- Changed two buffers to use ffmpeg allocation, not sure if that helps somehow.
- Implemented a nice rechanneling solution with unofficial speaker arrangement standards similar to what OpenAL soft has
- Renamend AUD_Channel in the C API to AUD_Handle
- Removed the unlogical 7.2 speaker configuration, that's a hardware only config
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
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.
