Opened 3 months ago

Last modified 3 months ago

#6366 new defect

tracks lengths are not frame accurate for non-compressed codecs

Reported by: rprowel Owned by:
Priority: normal Component: undetermined
Version: 3.1.7 Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:

I do a lot of transcoding from AVCHD to QT wrapper containing MJPEG and pcm16le two channel audio. This gives me a good I-frame format for nonlinear editing on a timeline based editor. The resultant stream "usually" ends up with audio tracks that do not match the video in length to a frame specific boundry. Concatenation of these clips with incorrect audio length causes the audio to skew. I've verified ffmpeg output with over 100ms skew and of course the effect is cumulative when concatenating clips/scenes.

For uncompressed audio of 48khz there is adequate bandwidth to sample at greater than 30fps, even in stereo.

ie. cinellera-cv

Workarounds are shunned. This is incorrect behaviour in the context I've outlined. The cinelerra folks have acknowledged and are fixing this in their internal use of codecs from an API, but the problem remains when using ffmpeg from the command line.

How to reproduce:


cmd="ffmpeg -i $inname -y \
 -acodec pcm_s16be \
 -deinterlace \
 -vcodec mjpeg \
 -q:v 1 \
 -vf ${filters}scale=1280:720 \
 -aspect 1.78 -r 29.97 $outname"
time $cmd

verify track lengths using something like exiftool or in a nonlinear editor.

ffmpeg version ... 3.1.7 (fc24)

built on ... 2017-02-12

Change History (1)

comment:1 Changed 3 months ago by cehoyos

  • Keywords audio drift removed

Please test current FFmpeg git head and provide both the command line you tested together with the complete, uncut console output and an input sample that allows to reproduce the issue to make this a valid ticket.

Unrelated: Very old documentation states that -qscale 1 is not recommended and suggests to use -qscale 2 instead.

Note: See TracTickets for help on using tickets.