[FFmpeg-user] Problems with mpegts and long running stream

[Mathias Schneider]

Hello,

I have the following setup:
a mpegts stream is built by a gstreamer pipeline and re-muxed by ffmpeg. I want to use the rich feature set of the ffmpeg mpegts-muxer (i.e. fill null-packets into my mpegts stream), therefore I’ve chosen this setup.
ffmpeg version: 3.3 (latest static build for Linux from ffmpeg.org)
gstreamer version: 1.10
OS: Ubuntu 16.04

Example:

Start ffmpeg - it will wait for incoming stream from gstreamer:
ffmpeg -re -buffer_size 2560000 -i rtp://127.0.0.1:2335?listen -c copy -muxrate 6000k -f mpegts  -mpegts_flags system_b udp://239.200.0.82:1234?pkt_size=1316

Start gstreamer:
 gst-launch-1.0 -e -m -v videotestsrc is-live=true name=vsource pattern=18 ! videoscale ! videoconvert ! videorate ! video/x-raw,width=1280,height=720,framerate=25/1 ! queue ! videoconvert ! videoscale ! videorate ! x264enc bitrate=5000 threads=0 byte-stream=true key-int-max=50 ! video/x-h264,profile=high ! queue ! h264parse ! mpegtsmux alignment=7 name=strmux ! rtpmp2tpay ! udpsink async=false sync=false host=127.0.0.1 port=2335

Everything works fine for around 1 day - 26,5 hours to be exact. Then, ffmpeg fires a lot of warnings, saying "Non-monotonous DTS in output stream“. The first of these messages gives a hint to the problem:

[mpegts @ 0x4f21ba0] Non-monotonous DTS in output stream 0:0; previous: 8584531106, current: -5399886; changing to 8584531107. This may result in incorrect timestamps in the output file.

There is a overflow in the mpegts PCR-field (33 bits), I guess. Is there a way to make ffmpeg dealing correctly with this overflow?
I’ve already tried the options "-copyts" and "-copytb 1“ -  but without success. 

During my search for a solution, I found this patch here: 
https://github.com/arut/ffmpeg-patches/blob/master/mpegts-33bit

I’ve patched my ffmpeg with it and it seems to solve my issue! 

Question: Did I something wrong or is there really a problem inside ffmpeg mpegts for long duration streams? And is this patch a correct solution?

Thanks,
Mathias