[FFmpeg-devel] [RFC] Non monotonically increasing timestamps

[Michael Niedermayer]

On Fri, Mar 25, 2011 at 07:45:56PM +0100, Stefano Sabatini wrote:
> On date Monday 2011-03-21 18:26:36 +0100, Stefano Sabatini encoded:
> > Hi all,
> > 
> > I'm dealing with files with non-monotonically increasing timestamps,
> > e.g.:
> > https://roundup.ffmpeg.org/issue1551
> > 
> > precisely with these files (tipically DVB TS captures), there is are
> > duplicated DTS values in consecutive video packets.
> > 
> > Follows an example:
> > 
> > $ ffprobe -show_packets  non_monotone_timestamps20091117.ts
> > ...
> > [PACKET]
> > codec_type=video
> > stream_index=0
> > ***pts=6583750012
> > pts_time=73152.777911 
> > dts=6583739212
> > dts_time=73152.657911 
> > duration=3600
> > duration_time=0.040000 
> > size=75597.000000 
> > pos=11172903
> > flags=_
> > [/PACKET]
> > [PACKET]
> > codec_type=video
> > stream_index=0
> > pts=6583742812
> > pts_time=73152.697911 
> > dts=6583742812
> > dts_time=73152.697911 
> > duration=3600
> > duration_time=0.040000 
> > size=3106.000000 
> > pos=11257127
> > flags=_
> > [/PACKET]
> > [PACKET]
> > codec_type=video
> > stream_index=0
> > pts=6583746412
> > pts_time=73152.737911 
> > dts=6583746412
> > dts_time=73152.737911 
> > duration=3600
> > duration_time=0.040000 
> > size=3102.000000 
> > pos=11260699
> > flags=_
> > [/PACKET]
> > [PACKET]
> > codec_type=audio
> > stream_index=1
> > pts=6583716091
> > pts_time=73152.401011 
> > dts=6583716091
> > dts_time=73152.401011 
> > duration=0
> > duration_time=0.000000 
> > size=5872.000000 
> > pos=11237199
> > flags=K
> > [/PACKET]
> > [PACKET]
> > codec_type=video
> > stream_index=0
> > ***pts=6583750012
> > pts_time=73152.777911 
> > ***dts=6583750012
> > dts_time=73152.777911 
> > duration=1800
> > duration_time=0.020000 
> > size=4.000000 
> > pos=-1
> > flags=_
> > [/PACKET]
> > [PACKET]
> > codec_type=video
> > stream_index=0
> > pts=6583760812
> > pts_time=73152.897911 
> > ***dts=6583750012
> > dts_time=73152.777911 
> > duration=3600
> > duration_time=0.040000 
> > size=58301.000000 
> > pos=11264083
> > flags=K
> > [/PACKET]
> > ...
> > 
> > The problem shows up tipically when copying with -vcodec copy, when
> > transcoding I suppose DTS is recomputed and so it never results in
> > duplicated DTSs.
> > 
> > So I'm asking if someone can suggest which is a good / the best way to
> > fix the DTS duplication problem.
> > 
> > A simple solution may consists of simply dropping the packets with the
> > duplicated DTS, which may result in video corruption (e.g. in the
> > abovementioned case, where the packet is a key packet), or fix the
> > dts somehow.
> > 
> > A full-fledged solution may involve the implementation of a
> > packet-level filtering API (which would be useful also for ffprobe,
> > e.g. for selecting only particular packets,
> > e.g. type=A|V|S/stream=X/PTS>X etc.).
> 
> Well, I investigated more with the issues. A possible fix may require
> adding a check in ffmpeg (see attached), which issues a warning and
> fixes the DTS/PTS accordingly (BUT: maybe this should be moved into
> the library, and enable the check according to some flag).
> 
> But then I discover that there is a problem while reading, in certain
> cases ffmpeg generates incorrect DTSes.
> 
> Precisely when we have this situation:
> pkt1: PTS1=DTS1
> pkt2: DTS=AV_NOPTS_VALUE
> 
> in this case FFmpeg (libavformat/utils.c:compute_pkt_fields) sets:
> DTS2 = pkt.dts = st->last_IP_pts
> 
> which corresponds to PTS1=DTS1, so we have DTS2 == DTS1 and ffmpeg
> fails when remuxing the file.

can you post some debug output that shows wheere/when this exactly
happens?


> 
> Note that the attached code doesn't prevent the error for remuxed
> MPEG-PS streams (with -*codec copy), indeed the MPEG-PS demuxer
> sometimes doesn't read the DTS written to the output, DTS is set to
> AV_NOPTS_VALUE and we're back to the abovementioned situation.
>

> A possible solution:
> add an AVStream.last_IP_dts, and replace the above instruction with:
> DTS2 = pkt.dts = st->last_IP_dts+1;
> 
> and/or add sanitizing code:
> dts = FFMAX(st->last_IP_dts+1, dts);

this will break more files than it fixes
timestamp discontinuities come to mind as one case it breaks



> 
> Comments?
> -- 
> FFmpeg = Free Fiendish Martial Portable Ecumenical Gorilla

>  ffmpeg.c |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 2ff2249848f6bc0198cb85f4a8347a9fa4f491d9  0005-ffmpeg-sanitize-DTS-values-before-to-pass-them-to-av.patch
> From 95a029c5562f02605843dee84869246be3f3de93 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini <stefano.sabatini-lala at poste.it>
> Date: Tue, 22 Mar 2011 19:36:47 +0100
> Subject: [PATCH] ffmpeg: sanitize DTS values before to pass them to av_interleaved_write_frame()
> 
> Set duplicated DTS values to MAX_DTS_VALUE+1, and fix the
> corresponding PTS accordingly. Avoid to pass a packet with illegal
> values to av_interleaved_write_frame().
> 
> This avoids the "invalid, non monotonically increasing dts" error in
> compute_pkt_fields2().
> 
> Note: this should be more properly fixed conditionally in libavformat.
> ---
>  ffmpeg.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)

The correction should be done after the demuxer in ffmpeg.c not before
the muxer.
Because the correction must be done before the encoder because the
encoder needs correct timestamps for many things, vbv is one but
not the only one


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110329/ecc4e595/attachment.asc>