[FFmpeg-devel] [PATCH] [RFC] libavformat/mpegts: Prevent wrapping of PTS & DTS

Michael Niedermayer michael at niedermayer.cc
Sun Jun 12 22:29:16 CEST 2016

On Sun, Jun 12, 2016 at 02:59:14PM -0400, DeHackEd wrote:
> On 06/12/2016 02:31 PM, Carl Eugen Hoyos wrote:
> > DeHackEd <git <at> dehacked.net> writes:
> > 
> >> The effects vary a bit. One guy in IRC basically had ffmpeg 
> >> crash for him every 26.5 hours when he was saving to HLS
> > 
> > And when I asked him how I can reproduce this issue he 
> > unfortunately couldn't answer;-(
> I pasted output from ffmpeg way back at the start of this thread.
> If you're not using libav (or you are and your application doesn't correct for the timestamp wrap itself) then you can
> get the API experience with -copyts in the ffmpeg command.

> $ ffmpeg -i longvideo.ts -c copy -f mpegts -copyts output.ts
> [mpegts @ 0x245f460] Invalid timestamps stream=0, pts=43408, dts=8589888000, size=535
> [mpegts @ 0x245f460] Invalid timestamps stream=0, pts=7408, dts=8589906000, size=157
> [null @ 0x2465180] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8589924000 >= 7408
> [null @ 0x2465180] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8589924000 >= 25408
> [null @ 0x2465180] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8589924000 >= 43408
> ...

copyts is not possible with timestamp discontnuities, the muxers need
clean timestamps for all kinds of buffer and compliance stuff

> In libav calling av_write_frame() with non-monontonic timestamps will return an error. In ffmpeg the video will be cut
> off or otherwise damaged at 26.5 hours.
> The guy in IRC had this convoluted command-line where he piped from ffmpeg to NvTranscoder (sample app in the nvenc SDK)
> and back through ffmpeg. The commend-line pasted was:
> /home/ffmpeg-3.0.1/ffmpeg -i - -codec copy -f mpegts - 2>/var/log/channels/${CHN}/input.txt < "$fifo" &
> encode+=($!)|NvTranscoder -size 1280 720 -i /dev/stdin -o /dev/stdout -bitrate 1800000 -vbvMaxBitrate 2500000  -vbvSize
> 1000000 -deviceID $2 $NVENC_OPTS |/home/ffmpeg-3.0.1/ffmpeg -fflags +genpts -i - -c:v copy -c:a aac -b:a 128k -ac 2
> -timestamp now -f hls -hls_time 6 -hls_flags delete_segments -hls_list_size 5 ${HLS_PATH}/${CHN}/${CHN}2M.m3u8
> 2>/var/log/channels/${CHN}/720p.txt
> ... and as for the outputs, all his pastebin records have expired.

there is a issue in hls, you can reproduce it with

./ffmpeg -f lavfi -i testsrc=s=80x60:r=2  -t 30:00:00  -f hls -hls_list_size 1000000 delthshls2/file-hls.m3u8
./ffmpeg -i delthshls2/file-hls.m3u8 -f null -

The problem here is that the hls demuxer does not support timestamp
wraps. It could remove the wraps relatively easily as it has a
"playlist" but it doesnt do that and just passes them on while at
the same time declaring to the outside that it doesnt have

if you add
.flags          = AVFMT_TS_DISCONT,
to the hls demuxer then sequential demuxing will be fine and ffmpeg
will remove the discontnuities, but seeking will cause problems
i think for hls it might be best to use the available "playlist"
and associate the needed wrap to the segments so they can be
corrected when demuxing packets and seek has a full and stable
do you want to try to work on implementing this ?

using hls with some generic discontnuity correction in the core if
one is written may be harder as that would depend on seeking per
byte position which hls doesnt really support

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160612/776753c9/attachment.sig>

More information about the ffmpeg-devel mailing list