[FFmpeg-trac] #8345(undetermined:closed): Audio Async by 1 frame from some video files

[FFmpeg]

#8345: Audio Async by 1 frame from some video files
-------------------------------------+-------------------------------------
             Reporter:  Vespucci     |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:  invalid
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by mkver):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 This is indeed priming/encoder delay:
 1. Your input mov file is pretty simple: The audio's edit list says: "Play
 the very first audio sample from the beginning for 480000 ticks of a 48kHz
 clock (i.e. for 10s)." The video of said file also has no delay/reordering
 and is constant 25fps for 10s.
 2. The output file is more complicated:
 a) The video track uses two reorder frames: It has two reorder frames so
 that the pts of the first frame is 1024 (with a 12800 Hz timescale); but
 there is also an edit list that shifts this to 0.
 b) The audio track consists of 470 audio frames: 469 with a duration of
 1024 and one with a duration of 768. An edit list exists that says that
 the actual output starts only at sample 1024 (i.e. decode, but don't
 output the first frame (which has a duration of 1024 samples)). This is
 done in order to counter encoder delay. So everything is right at the
 beginning if you use a tool that correctly trims according to the edit
 list (whatever tool you use to decode the audio from the reencoded file
 ignores the edit list and is the real culprit for your asynchronity).
 c) I am btw not certain whether everything is right at the end: I would
 expect the last frame to also declare a duration of 1024, because it
 contains 1024 samples like all the other frames, and to rely on the edit
 list to trim the end padding away. (The edit list for this track says that
 it has a duration of exactly 10s.) If one claims the last frame to have a
 duration of 768/48000 s, does one not actually say that the 1024 samples
 from this frame (with a natural duration of 1024/48000 s) should be
 stretched to fit into 768/48000 s (i.e. played at a faster speed)?
 d) It follows from b) that your issue is invalid.
 e) You should also look at #7185 for what happens when the first audio
 sample does not have a timestamp of zero before reencoding.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8345#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker