DTS Error in recorded MKV

[Lumbermatt85]

Hi,

I'm experiencing some problems with some files I'm recording from French TV (DVB-T2 aired).
My setup is a Raspberry Pi 4 with several USB DVB-T2 tuners and TVHeadend 4.3-2382. Some files (but not all, without being able to find which exactly) cause me problems when I want to process them.

The files have following structure:

  Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn (default)
  Stream #0:1(fre): Audio: eac3, 48000 Hz, stereo, fltp, 128 kb/s (default)
  Stream #0:2(qaa): Audio: eac3, 48000 Hz, stereo, fltp, 128 kb/s (default)
  Stream #0:3(qaa): Audio: eac3, 48000 Hz, stereo, fltp, 96 kb/s (default)
  Stream #0:4(fre): Subtitle: dvb_subtitle (default)
  Stream #0:5(fre): Subtitle: dvb_subtitle (default)

I usually get an MKV file with the programme recorded. I process the file with ffmpeg to remove the padding before and after and possibly cut out the commercial break if some, then I encode them. The recorded MKV file is played back smoothly by VLC. When I play it with ffplay I get a small but increasing number of errors on the DTS (console output f=X/0 with X increasing) but the playback is not choppy (or at least it's not noticeable).

As soon as I reprocess the file, even as simply as possible, like

ffmpeg -i recorded.mkv -c:v copy -c:a copy -c:s copy -map 0 output.mkv

The output file is no longer read correctly. Under VLC you get extremely annoying choppy playback, and in the playback statistics about a quarter of the frames are dropped. When playing with ffplay, playback is also choppy and the number of DTS and PTS errors increases rapidly during playback.

When remuxing MKV with ffmpeg, a large number of ‘Non-monotonic DTS in output stream is displayed’ warnings are displayed :

[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 244, current: 184; changing to 244. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 244, current: 204; changing to 244. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 404, current: 344; changing to 404. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 404, current: 364; changing to 404. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 564, current: 504; changing to 564. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 564, current: 524; changing to 564. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 724, current: 664; changing to 724. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 724, current: 684; changing to 724. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 884, current: 824; changing to 884. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 884, current: 844; changing to 884. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 1044, current: 984; changing to 1044. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 1044, current: 1004; changing to 1044. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 1204, current: 1144; changing to 1204. This may result in incorrect timestamps in the output file.
[matroska @ 0x59f808bc5fc0] Non-monotonic DTS in output stream 0:0; previous: 1204, current: 1164; changing to 1204. This may result in incorrect timestamps in the output file.

I'm far from being an expert in video encoding, but I understand the output as ffmpeg finding timestamps that aren't in the right order, for example in the first few lines, it looks like 244 comes before 184 and 204 and on correcting what it thinks is a monotonicity error, it correct the timestamp twice on 244 which probably causes the frame to be lost during playback.

Does this sound familiar?

I've been trying for a few days now using the

-fflags +igndts

or

-use_wallclock_as_timestamps

flags, but without much success.

I've read on a few forums that this phenomenon could be caused by the MBAFF encoding used in DVB-T2 broadcasting in some countries, but I have no idea how to verify this statement and set ffmpeg to take this into account.

Thank you very much for any help.

[Lumbermatt85]

I couldn't edit my first message. I just noticed something odd using Mediainfo while investigating the interlacing :

In the original recorded file :

Scan type                                : Interlaced
Scan type, store method                  : Separated fields
Scan order                               : Top Field First

In the ffmpeg processed output :

Scan type                                : Interlaced
Scan type, store method                  : Separated fields (2 fields per block)
Scan order                               : Top Field First

[ProWo]

Remux your mkv with clever FFmpeg-GUI.

Start the app, load your mkv, click main page, click multiplex, select mkv as container and click multiplex.
Done.

All timestamps are recreated with with process.

BTW
The difference shown in your post #2 isn't an issue.

[Lumbermatt85]

Thank you very much for the advice: it's a very useful tool I didn't know.
I tried it, unfortunately the effect is exactly the same when I remux manually with ffmpeg, the output file has exactly the same problem (about 1/4 of the frames lost).

I've also tried the ‘fix timing’ function, which gives exactly the same result as when I use use_wallclock_as_timestamps and genpts: the file no longer seems to have a timestamp and is not playable (90% of frames lost).

[ProWo]

There are other 2 options:
1) Scan for errors (to found where the errors are). Main page, Various. You could post the error.txt file here.
2) If the problem is with the videostream, you could extract it as raw stream (main page, extract stream); if finished, return to the source page and drag the created .h264 stream into the window.
The program ask you for the FPS, insert 25 and click OK.
The raw stream is imported into a mp4 container and automatically loaded.
This new mp4 video should play fine without issues.

[Henry_V]

Just because VLC is able to play the file smoothly doesn’t necessarily mean the file is error-free. VLC is known for being very forgiving when it comes to irregularities in timestamps — it often masks underlying issues that would cause problems in stricter players or tools. On the other hand, tools like ffmpeg and ffplay are much more sensitive to timestamp inconsistencies, which is probably why you're seeing playback stuttering and DTS/PTS errors there.
You might want to try remuxing the file using mkvmerge (part of the MKVToolNix suite). In some cases, it does a better job than ffmpeg at fixing or smoothing out problematic timestamp sequences without requiring a full re-encode. It’s definitely worth a shot if you're looking to preserve the original streams while improving playback compatibility.

[Lumbermatt85]

Hi ProWo, hi Henry_V

First of all, thank you for your advice and your time.

I did an error scan, without any errors that came back to me, then as suggested I exported the raw stream in .h264 then reimported it in an mp4 container.

Here is the output of ffplay for the h264 raw file :

Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 1200k tbn

The source don't seem to be in 25 fps: the file is twice as long as normal and twice as slow, and there's an artefact on the movements (like flickering) which gives the impression that two interlaced frames are being played one after the other without processing.

Duration: 04:59:58.62, start: 0.000000, bitrate: 1913 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 1912 kb/s, 25 fps, 25 tbr, 12800 tbn (default)

If I set 50 fps the file has the right duration and plays perfectly smoothly without errors.

Duration: 02:29:59.28, start: 0.000000, bitrate: 3826 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 3825 kb/s, 50 fps, 50 tbr, 12800 tbn (default)

I'll look if I can multiplex the whole file back to get audio and subtitles back (dvb-t subtitles are bitmap based an don't fit in an MP4 container)

[ProWo]

50 fps is right, as you see in the raw file data (50 tbr); your source file has wrong data (25 tbr).
So it seems fixed now.
For the dvb-t subtitles you could convert them to srt with Subtitle Edit and mux them after to mp4.
For the muxing you can also use clever FFmpeg-GUI.

[Lumbermatt85]

Ok, video works perfectly now. After multiplexing I had an audio/video desynchronisation of -400 ms which I recovered by multiplexing with clever FFMpeg-GUI.

Thanks a lot !