Since avuitl 57.30.100 the pkt_duration is deprecated, and
the duration is to be used instead.
The units seems to match, and also from the avcodec decoder.c
the `frame->pkt_duration = frame->duration;` so does not seem
we need to do any conversion.
The change in FFmpeg is from 2022, which is a bit recent, so
the access to the duration is hidden behind a compatibility
API.
Pull Request: https://projects.blender.org/blender/blender/pulls/108451
Seems like the new audio channel api was not as backwards compatible as we thought.
Therefore we need to reintroduce the usage of the old api to make older ffmpeg version be able to compile Blender.
This change is only intended to stick around for two releases or so. After that we hope that most Linux distros ship
ffmpeg >=5.0 so we can switch to it.
Reviewed By: Sergey
Differential Revision: http://developer.blender.org/D16408
ffmpeg_generic_seek_workaround did work properly and our start pts
calculation was wrong.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11562
Because of the added sanity checks in rB14508ef100c9 (D11492), seeking
in proxies would not work correctly any more. This is because it wasn't
working as intended before, but in most cases this wouldn't be
noticeable. However now when the sanity checks are tripped it is very
noticeable that something is wrong
The indexer tried to use dts values for time stamps when we used pts in
our decode functions to get the time positions. This would make it
start in the wrong GOP frames when searching. Now that we enforce no
crossing of GOP frames when decoding after seek, this would lead to
issues.
Now we correctly use pts (or dts if pts is not available) and thus we
don't have any seeking issues because of time stamp format missmatch.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11561
Before the FFmpeg commit: github.com/FFmpeg/FFmpeg/commit/1c0885334dda9ee8652e60c586fa2e3674056586
FFmpeg would use deprecated variables to calculate the video fps.
We don't use these deprecated variables anymore, so ensure that the
duration is correct in ffmpeg versions without this fix.
Reviewed By: Sergey, Richard Antalik
Differential Revision: http://developer.blender.org/D11417
There need to be more cleanup for ffmpeg 4.5 (ffmpeg master branch).
However this now compiles on ffmpeg 4.4 without and deprication
warnings.
Reviewed By: Sergey, Richard Antalik
Differential Revision: http://developer.blender.org/D10338
This was introduced in FFmpeg lavf 55.1.100 in 2013. For systems that are
still on LibAV or older FFmpeg there is a fallback implementation that
performs the same guess as we did before in `av_get_r_frame_rate_compat()`.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Some years-old deprecated stuff has now been removed.
Correct solution is probably to use valid defines etc. in own code, but
this is more FFMEPG maintainer task (since it also may change how old
FFMPEG we do support...).
This is an issue with which value to trust: fps vs. tbr. They both cam be
somewhat broken. Currently the idea is:
- If file was saved with FFmpeg AND we are decoding with FFmpeg we trust tbr.
- If we are decoding with Libav we use fps (there does not seem to be tbr in
Libav, unless i'm missing something).
- All other cases we use fps.
Seems to work all good for files from T53857, T54148 and T51153. Ideally we
would need to collect some amount of regression files to make further tweaks
more scientific.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D3083
The issue was caused by stupid workaorund for libav. Now things works for
FFmpeg. There might need some tweaks needed for Libav, but that one is
not really priority for support.
While it's not something we'll be using for the official release,
it's nice to support new libraries at least on "it compiles" level,
so it's not that many frustrated developers around.
Nexyon, please have a look into Audaspace changes :)
Was a regression since avg_frame_rate changes.
Didn't find reliable way to get stream duration which will
work with both FFmpeg and Libav so added some freaking black
magic to distinguish one from another.
CODEC_ID_* have been replaced with AV_CODEC_ID_* in new libavcodec
versions.
Update the code to use those new identifiers.
Added a compatibility code to ffmpeg_compat.h
After planar codecs support minimal FFmpeg was
bumped to 0.10 which was not so much nice because
it was only released only later last year.
Didn't find a way to make compatibility code local
in ffmpeg_compat, so there're some ifdefs in
audaspace and writeffmpeg.
Not entirely happy, but having a bit of ifdefs in
code better than lots of real PITA for platform
maintainers.
AVCODEC_MAX_AUDIO_FRAME_SIZE was deprecated and
finally removed from current trunk.
Initial patch by Lawrence D'Oliveiro (ldo) with
own modification, Thanks!
The latest ffmpeg versions include a workaround to deal with a certain
pecularity in Canon DSLR footage: instead of decoding pictures with the
proper resolution of 1920x1080 they decode it with 1920x1088 and add a
black bar at the bottom.
Needless to say, that this screws up things in a lot of areas within blender
(proxy indices, mask animations etc.)
Since all blender versions besides Linux x86 32bit seem still to include
older ffmpeg versions which still contain this bug, this patch adds
a workaround for older versions until we have all versions on all platforms
up to date.
See also: http://git.libav.org/?p=libav.git;a=commit;h=30f515091c323da59c0f1b533703dedca2f4b95d
