[FFmpeg-trac] #9921(avformat:new): DASH has duplicate AAC timestamp
FFmpeg
trac at avcodec.org
Tue Sep 13 11:59:51 EEST 2022
#9921: DASH has duplicate AAC timestamp
-------------------------------------+------------------------------------
Reporter: philipn | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: avformat
Version: unspecified | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+------------------------------------
Comment (by philipn):
I think my analysis and potential fix was wrong. The timing in the DASH is
correct but the packet timestamps read are wrong.
The first segment file contains 235 frames. The init segment edts
determines that the segment starts at the second frame (time 1024), i.e.
the segment presentation duration is 234 frames. The earliest presentation
time property of the second segment should therefore be 234 * 1024 =
239616 and that is what it is set to.
The packet timing issue when reading however can be seen when re-encoding
using "ffmpeg -i test.mpd test.mp4". This results in a "[aac @
0x55bee3dd4280] Queue input is backward in time" warning.
Another example is opus, "ffmpeg -i test.mpd -codec:a libopus test.ogg"
which results in
"[libopus @ 0x560e352de280] Queue input is backward in time
[ogg @ 0x560e352cc0c0] Non-monotonous DTS in output stream 0:0; previous:
240648, current: 240584; changing to 240648. This may result in incorrect
timestamps in the output file."
The incorrect timing matters if the thing that is processing the media
doesn't correct or ignore the issue in the right way.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9921#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list