AviDemux 2.8.1 timestamps get changed in copy-mode

[antoniu200]

Hi,

I have a multitude of files originating from TV that need to be cut. All of them have some sort of delay between the video and the audio.
AviDemux seems to not like this type of file, since every time I cut or just simply export one without trimming in AviDemux, it changes the timestamps and the original delay.

For this particular issue, I would like to know exactly how AviDemux changes these timestamps, if the issue cannot be fixed, so I can at least perform the same adjustments on subtitles.

Also, for some reason, every single file cut using AviDemux causes FFmpeg to throw a "Non-monotonous DTS in output stream", but this only happens if one actually trims the file, not just exports it. This FFmpeg error causes the video FPS to go haywire.

Here are some sample files for you to see the issue: https://drive.google.com/drive/folders/1lTnYufORT4lhwVjJEAnq3YmwUANY5e_h. There is also a PGS subtitle in there that you can use to check whether or not the timestamps are being changed. The original "ffmpeg trimmed" file also contains a DVB sub, identical in timing and images to the PGS subtitle.

[eumagga0x2a]

It might be helpful to compare with the source video, but the samples you have provided show good A/V sync on my system.

Regarding "Non-monotonous DTS in output stream" warnings, this looks for me at first glance like a bug in Matroska muxer in FFmpeg, affecting interlaced, field-encoded streams. The MP4 muxer in FFmpeg doesn't exhibit this issue, please use it as far as Matroska container is not mandatory for your purposes.

Regarding timestamps, Avidemux will shift (delay) all timestamps to ensure that all valid timestamps are non-negative (it stores timestamps as an unsigned 64-bit integer). If you inspect admlog.txt from loading a video, you might encounter a line like

Code Select Expand

[addReferenceVideo] .... The first frame has a PTS > 0, adjusting to 1360 ms
If your (external) subtitles have been created based on the first keyframe having PTS = 0 (which implies that the DTS of this frame due to presence of B-frames has to be negative), all timing in the subtitle file needs to be delayed by 1360 milliseconds.

[antoniu200]

It might be helpful to compare with the source video, but the samples you have provided show good A/V sync on my system.

Uhh, I meant a delay pre-specified in the video file, the kind MediaInfo would tell you about and the player would automatically compensate for.

Regarding "Non-monotonous DTS in output stream" warnings, this looks for me at first glance like a bug in Matroska muxer in FFmpeg, affecting interlaced, field-encoded streams. The MP4 muxer in FFmpeg doesn't exhibit this issue, please use it as far as Matroska container is not mandatory for your purposes.

Oh, wow, I've spent probably a month trying to diagnose this issue before. I just tried exporting from AviDemux in .ts, to import into FFmpeg and the issue was gone. Even if I use FFmpeg to export to MKV, the warnings are completely gone.
Wow, I'll let the devs over at FFmpeg know.

Regarding timestamps, Avidemux will shift (delay) all timestamps to ensure that all valid timestamps are non-negative (it stores timestamps as an unsigned 64-bit integer). If you inspect admlog.txt from loading a video, you might encounter a line like

Code Select Expand

[addReferenceVideo] .... The first frame has a PTS > 0, adjusting to 1360 ms
If your (external) subtitles have been created based on the first keyframe having PTS = 0 (which implies that the DTS of this frame due to presence of B-frames has to be negative), all timing in the subtitle file needs to be delayed by 1360 milliseconds.

Well, they're ripped from the "ffmpeg trimmed" video, so they have the same timestamps as the DVB Subtitle. You say "delayed", but what fixed the timing was displaying them earlier by 1360 ms. Anyway, I'll keep this in mind from now on. Useful stuff.
Thanks!