[FFmpeg-devel] [PATCH] avformat/mpegts: correct timestamp overflow on multiple pcr loopback

[Sébastien Rossi]

The issue I tried to patch is that on ts stream that last more than 26,5h
(time between pcr loopback) we had pts and dts discontinuities. In
wrap_timestamp function in demux.c, I've seen there's some code to correct
timestamp overflow, but when the stream last more than 26,5h, timestamps
are upper than pts_wrap_reference two times. So the second time we outrun
the pts_wrap_reference we lose the timestamp correction and have some
errors like pts < dts.
What I tried to do is to restamp pts and dts using mpegts pcr information.
The preserve_continuity function checks relative position between timestamp
(dts or pts) and pcr, and handle cases when pcr have already loopback and
timestamp not or vice versa. Then it applicates correction to the timestamp
depending on pcr loopback count.

I can provide a stream with a duration of 30h, if you want to.

Could you tell me how to reproduce the segfault you've seen ?

Sébastien Rossi

Le ven. 24 juin 2022 à 01:31, Michael Niedermayer <michael at niedermayer.cc>
a écrit :

> On Thu, Jun 23, 2022 at 05:45:52PM +0200, Sébastien Rossi wrote:
> > - Detect and count PCR loopback
> > - Correct DTS and PTS with PCR loopback count to avoid timestamp overflow
> > and preserve timestamp continuity
>
> >  libavformat/mpegts.c         |   45 +
> >  tests/ref/fate/ts-opus-demux | 1028
> +++++++++++++++++++++----------------------
> >  2 files changed, 556 insertions(+), 517 deletions(-)
> > 43462e655164b7eda6d3a5e8a85bc42556891742
> 0001-avformat-mpegts-correct-timestamp-overflow-on-multip.patch
> > From 19305e9c1beffb34b73c71f721a6dea2b9fc483f Mon Sep 17 00:00:00 2001
> > From: sebastien_rossi <sebastien.rossi at bbright.com>
> > Date: Thu, 23 Jun 2022 17:20:06 +0200
> > Subject: [PATCH] avformat/mpegts: correct timestamp overflow on multiple
> pcr
> >  loopback
>
> not entirely sure what you are trying to do, did you look at the timestamp
> handling in the generic code?
> also this sort of timestamp modification can have issues with seeking
>
> also this segfaults
>
> ==13685== Invalid read of size 8
> ==13685==    at 0x690357: new_pes_packet (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x6937AB: mpegts_push_data (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x690CE7: handle_packet (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x6911A4: handle_packets (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x6912E1: mpegts_read_packet (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x5F42D4: ff_read_packet (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x5F50C4: read_frame_internal (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x5F6EA0: avformat_find_stream_info (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x2F1644: open_input_file (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x2F7C5B: ffmpeg_parse_options (in ffmpeg/ffmpeg_g)
> ==13685==    by 0x2E60F4: main (in ffmpeg/ffmpeg_g)
> ==13685==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>