[FFmpeg-trac] #9590(undetermined:new): FFmpeg-written MP4 fails to be read-back without distortion of PTS/DTS
FFmpeg
trac at avcodec.org
Mon Jan 10 15:40:34 EET 2022
#9590: FFmpeg-written MP4 fails to be read-back without distortion of PTS/DTS
-------------------------------------+-------------------------------------
Reporter: Ulrik | Type: defect
Mikaelsson |
Status: new | Priority: normal
Component: | Version:
undetermined | unspecified
Keywords: mov pts DTS | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Summary of the bug: After writing an MP4 using libavformat, and reading it
back using ffprobe, timestamps are distorted
How to reproduce:
{{{
% ffprobe -show_packets non-zero-start.mp4
ffmpeg version 4.4.1
built on ubuntu (probably not relevant)
}}}
After writing an MP4 using PyAV (using ffmpeg under the hood), and reading
it back using ffprobe,
the timestamps have been altered from those provided.
The timestamps passed to `av_write_frame` are:
{{{
PTS=-1358 and DTS=-4243
PTS=3599 and DTS=-2367
PTS=1527 and DTS=-1358
PTS=518 and DTS=518
PTS=2563 and DTS=1527
PTS=5612 and DTS=2563
PTS=4584 and DTS=3599
}}}
The timestamps read back using `ffprobe -show_packets` are:
{{{
PTS=-1876 and DTS=-4761
PTS=3081 and DTS=-2885
PTS=1009 and DTS=-1876
PTS=0 and DTS=0
PTS=2045 and DTS=1009
PTS=5094 and DTS=2045
PTS=4066 and DTS=3081
}}}
The `timebase` passed to both the AVStream, and to the mvhd header,
(through option `movie_timescale`), is `1/30000`.
I've tried dumping the mp4 using mp4box (and MP4Box.js;
[https://gpac.github.io/mp4box.js/test/filereader.html]). After manually
subtracting the edit-list offset, the samples match the timestamps
provided to the muxer, leading to the conclusion that something in the
demuxing of this mp4 goes wrong.
After some bisecting in the demuxer, I've narrowed it down to this if-
clause
[https://github.com/FFmpeg/FFmpeg/blob/f37e66b3937a914e16d89a9050f042ad89567245/libavformat/mov.c#L3792].
The intention is to "make the minimum PTS (first non-discarded frame?)
zero", but it's unclear to me _why_ it should be made zero? It's perfectly
reasonable for a track to start a non-zero PTS? This is even intentionally
supported, for tracks where the edit-list starts with a few empty edits. I
do not see why a track with some frames before 0 should change that?
AFAICT, this might even possibly break A/V-sync, since the corresponding
adjustment does not seem to be done to other tracks?
1. Should I not expect the inputs I pass to the libavformat-muxer here to
be reflected back out, unchanged?
2. What is the intention behind "making the first pts zero"? Why can't
this clause simply be removed?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9590>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list