diff options
| author | Mark Reid <mindmark@gmail.com> | 2021-01-16 17:48:45 -0800 |
|---|---|---|
| committer | Anton Khirnov <anton@khirnov.net> | 2021-02-22 11:12:10 +0100 |
| commit | a82a05276997d3fa5da5a4b7e09cd71bbe283c50 (patch) | |
| tree | 08e879aaa4fae07a9345e32a2d52a29438d1b02c /libavdevice/libavdevice.v | |
| parent | 1c36e7c1a524cd944679b3be8a52dde85d442ada (diff) | |
| download | ffmpeg-a82a05276997d3fa5da5a4b7e09cd71bbe283c50.tar.gz | |
avformat/mov: fix timecode with counter mode flag set
The current behaviour ends up squaring the avg_frame_rate if the conter mode flag is set.
This messes up the timecode calculation, and looks to me as a regression that
seems to have been introduced 428b4aac.
Upon further testing is seems that no special case is need for having the counter flag set.
av_timecode_init appears to handles the timecode correctly, at least in the sample files
I have.
Here is a sample mov file with the counter flag set
https://www.dropbox.com/s/5l4fucb9lhq523s/timecode_counter_mode.mov
before the patch ffmpeg will report the timecode as:
00:37:11:97 and warns that the timecode framerate is 576000000/1002001
after patch:
14:50:55:02
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Diffstat (limited to 'libavdevice/libavdevice.v')
0 files changed, 0 insertions, 0 deletions