Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#9671 closed defect (fixed)

wrong duration output with -t on audio with edit lists (preroll)

Reported by: Cosmin Stejerean Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: aac
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Given a typical AAC audio file in MP4 format it will contain an edit list for the necessary preroll duration. Attempting to decode a subset of such a file (with -t) will result in wrong duration output. Reproduced this in ffmpeg 5

Steps to reproduce

  1. Acquire a test AAC in MP4 file, or trivially create one as follows
ffmpeg -f lavfi -t 30 -i anullsrc=channel_layout=stereo:sample_rate=48000 -codec:a libfdk_aac -profile:a aac_he test.mp4
  1. Attempt to decode the first 10s of audio from this file
ffmpeg -i test.mp4 -t 10 out.wav
  1. Observe that the output is not in fact 10s long, it is missing precisely the duration of the start edit list in the original
ffprobe out.wav

Duration: 00:00:09.90, bitrate: 1536 kb/s
  1. Using -t as a demuxer option (before -i) results in correct output
ffmpeg -t 10 -i test.mp4  out2.wav
ffprobe out2.wav

Duration: 00:00:10.00, bitrate: 1536 kb/s

Based on this I believe that most likely the -t option is wrongly considering time without the edit list offset at the beginning, at least on the audio case. I have not verified what happens with -t on video inputs that also contain edit lists.

Change History (2)

comment:1 by James, 2 years ago

Component: undeterminedavcodec
Keywords: aac added
Resolution: fixed
Status: newclosed

comment:2 by Balling, 2 years ago

It really is an issue we faced (samples are indeed HE-AACv2) https://bugs.chromium.org/p/chromium/issues/detail?id=1234227

Thanks for fixing this!

Note: See TracTickets for help on using tickets.