[FFmpeg-user] Problems with mpegts and long running stream
m.schneider at s3de.net
Wed May 31 23:09:06 EEST 2017
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
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://188.8.131.52:1234?pkt_size=1316
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:
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?
More information about the ffmpeg-user