Opened 9 months ago

Closed 4 months ago

#9492 closed defect (fixed)

ffmpeg reads wrong timecode

Reported by: marku Owned by:
Priority: important Component: avformat
Version: git-master Keywords: timecode mov regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
I use ffmpeg to generate proxy files but for some reason the timecode is wrong. When I open the original file in DaVinci Resolve it always shows double the timecode that ffmpeg (ffprobe) reads.
e.g. original video in Resolve shows Start TC 00:00:24:00 and ffprobe shows 00:00:12:00.
When I do anything with the original file in ffmpeg it changes the timecode to the wrong one.
The timecode is from Fujifilm XT-3 and the one that Resolve shows is the one from the camera.

How to reproduce:
Use any command that will create new file.

Command for creating proxy:

ffmpeg -hwaccel cuda -i DSCF6599.MOV -acodec pcm_s16le -vcodec prores -profile:v 0 -vf scale=-1:1080 ./Proxy/DSCF6599.MOV

Copy streams:

ffmpeg -i ~/Videos/Test/DSCF6599.MOV -map 0 -map_metadata 0 -movflags use_metadata_tags -c copy -copy_unknown ~/Videos/Test/Proxy/test.MOV

File to reproduce:
Video should start at 00:00:24:00, ffmpeg reads 00:00:12:00
https://drive.google.com/file/d/1FA3doe72wN6Z1vQz9ZoBtT2qBOgavn0X/view?usp=sharing

Change History (2)

comment:1 by NoKi, 6 months ago

Hi,
I noticed this issue too, when transcoding 50 fps videos with timecode from Panasonic cameras (x1500, GH5). It seems to happen on videos with framerates higher than 30 fps, which is (to my knowledge) the highest fps rate SMPTE timecode is standardized for.

So, it looks like that for compatibility reasons the cameras write a 25 or 30 fps timecode to the file, although the video actually is 50/60 fps. Most video NLEs (like Resolve) are aware of this and correctly calculate the timecode based on the standardized 25 or 30 fps rates.

FFMPEG seems to read the 25 fps timecode of a 50 fps video incorrectly with 50 fps. So, the incorrect timecode is always half of what it should be.

My workaround is to read the correct timecode with exiftool and use this for the file transcoded by FFMPEG. Though, I hope this will be fixed in FFMPEG.

comment:2 by Marton Balint, 4 months ago

Component: undeterminedavformat
Keywords: mov regression added
Priority: normalimportant
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.