Non-monotonic DTS errors, saving a live encode via mediaMTX
Hi, I am please looking for some advice. live encoding from a decklink card to MediaMTX (on windows) then using ffmpeg to save the live stream to file. I need to be able to independently stop and start the saving of the file, that's why I am using this setup. We are also going to send the live stream to a CDN, via another instance of ffmpeg. Here is my current command to encode; ffmpeg.exe -rtbufsize 2G -re -format_code Hp30 -f decklink -i 35:00000000:00230600 -framerate 30 -video_size 1920x1080 -pix_fmt uyvy422 -vcodec libx264 -preset veryfast -x264-params "keyint=120:min-keyint=120:scenecut=0" -tune stillimage -b:v 3000k -minrate 3000k -maxrate 3000k -bufsize 3000k -acodec aac -ac 2 -ar 48000 -b:a 128k -g 120 -f rtsp rtsp://localhost:8554/mystream then to save the file I am using this; ffmpeg -rtsp_transport tcp -fflags +igndts -copyts -i rtsp://localhost:8554/mystream -start_at_zero -c copy output.ts I don't have the time to re-encode the .ts - just we will do a -copy and change to .mp4 which will be the final output. I keep getting Non-monotonic DTS errors, which I could just ignore, but I think they are suggesting something is wrong. My test .ts files will play in VLC, but I don't think they are 'good enough'. both seeking and audio sync does not look right.
Hello, In the Message; Subject : [FFmpeg-user] Non-monotonic DTS errors, saving a live encode via mediaMTX Message-ID : <ME0P300MB04539F83440F23672218DA55B70E2@ME0P300MB0453.AUSP300.PROD.OUTLOOK.COM> Date & Time: Fri, 27 Dec 2024 01:42:55 +0000 [AS] == Andrew Strachan <stroltz-at-hotmail.com@ffmpeg.org> has written: [...] AS> I keep getting Non-monotonic DTS errors, which I could just AS> ignore, but I think they are suggesting something is wrong. My AS> test .ts files will play in VLC, but I don't think they are 'good AS> enough'. both seeking and audio sync does not look right. Non-monotonic DTS (Decoding Time Stamp) errors are a common problem that occurs when processing video and audio files with FFmpeg. This error occurs when the timestamps of the output stream are not monotonically increasing. When this error occurs, the timestamps of the output file may be incorrect, and this may cause problems when playing back the file. In any case, it is recommended that you use the latest version of FFmpeg, as older versions may frequently encounter this error. Possible solutions; 1. re-encoding or 2. adjusting the FFmpeg options 2-1. -fflags +igndts: ignore timestamps 2-2. -copytb 1: specify how to copy timebase However, it may be difficult to completely avoid this problem. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "The production of A.I. seems to carry a powerful side effect: as the machines generate intelligence, they also generate mystery. Human misunderstanding endures, possibly a permanent condition. " -- "Was Linguistic A.I. Created by Accident?" THE NEW YORKER --
Masaru Nomiya <nomiya@lake.dti.ne.jp> wrote: Non-monotonic DTS (Decoding Time Stamp) errors are a common problem
that occurs when processing video and audio files with FFmpeg. This error occurs when the timestamps of the output stream are not monotonically increasing.
Please refrain from using AI generated answers :-) KR, Vincent
Especially useless AI answers. Rectifying DTS errors is something that particularly interests me. On Friday, December 27, 2024 at 06:16:31 AM PST, Vincent Deconinck <vdeconinck@gmail.com> wrote: Masaru Nomiya <nomiya@lake.dti.ne.jp> wrote: Non-monotonic DTS (Decoding Time Stamp) errors are a common problem
that occurs when processing video and audio files with FFmpeg. This error occurs when the timestamps of the output stream are not monotonically increasing.
Please refrain from using AI generated answers :-) KR, Vincent _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 12/26/24 8:42 PM, Andrew Strachan wrote:
Hi,
I am please looking for some advice. live encoding from a decklink card to MediaMTX (on windows) then using ffmpeg to save the live stream to file. I need to be able to independently stop and start the saving of the file, that's why I am using this setup. We are also going to send the live stream to a CDN, via another instance of ffmpeg.
Here is my current command to encode;
ffmpeg.exe -rtbufsize 2G -re -format_code Hp30 -f decklink -i 35:00000000:00230600 -framerate 30 -video_size 1920x1080 -pix_fmt uyvy422 -vcodec libx264 -preset veryfast -x264-params "keyint=120:min-keyint=120:scenecut=0" -tune stillimage -b:v 3000k -minrate 3000k -maxrate 3000k -bufsize 3000k -acodec aac -ac 2 -ar 48000 -b:a 128k -g 120 -f rtsp rtsp://localhost:8554/mystream
then to save the file I am using this; ffmpeg -rtsp_transport tcp -fflags +igndts -copyts -i rtsp://localhost:8554/mystream -start_at_zero -c copy output.ts
I don't have the time to re-encode the .ts - just we will do a -copy and change to .mp4 which will be the final output.
I keep getting Non-monotonic DTS errors, which I could just ignore, but I think they are suggesting something is wrong. My test .ts files will play in VLC, but I don't think they are 'good enough'. both seeking and audio sync does not look right.
First of all, -video_size 1920x1080 and -pix_fmt uyvy422 appear to be input options, which should go before the -i, so you would end up with -f decklink -video_size 1920x1080 -pixel_format uyvy422 -i .... Likewise, -copyts and -start_at_zero are both input options. However, to answer your question, it looks like you have -fflags +igndts, which causes the demuxer to ignore the DTS of the input files. DTS is "demux time stamp." Sometimes, frames are decoded/demuxed in a different order than they are presented - this is the case with B-frames (bi-directional), which are frames that include both forward and backward predictions. By setting -fflags +igndts, you're telling FFmpeg to ignore the DTS, and it likely is generating fake DTS values based on the PTS, which are incorrect. The PTS are out of order, as you would expect when b-frames are present, causing the DTS to also be out of order. DTS being out of order is not legal (unlike PTS), so the MPEG-TS muxer is observing this, fixing it, and throwing a warning. In order to fix this, you may want to simply remove -fflags +igndts. As for seeking the output file with VLC, mpegts is not an easily seekable format and you should no generally expect that to work well. - Leo Izen (Traneptora)
participants (5)
-
Andrew Strachan -
Bruce Gavin -
Leo Izen -
Masaru Nomiya -
Vincent Deconinck