Synchronization problems with, seemingly, big/long files

[radorn]

I use Avidmux a lot to cutup and convert digital TV recordings in TS format.

Recently, I've been noticing that it seems files that either play for too long or are too big in size (5:46:57 and 10.6GB in the case that I'm handling now) seem to result in big audio synchronization problems in Avidemux. I'm talking about audio coming in a few full seconds behind video. VLC seems to have the same problem, but SMplayer plays it fine.
If I remux the TS into MKV with MKVToolNix, now both SMplayer and VLC play fine, but Avidemux still has desynchronization.

I don't know for certain if this was always the case with all previous builds, or all previous big files. I just noticed it a couple of times recently, both with big files like this one. I don't keep them around after a seemingly successful edit, so I can't really test this as thoroughly as I would like. Also, I can't share such big files over the internet as I'm on a metered connection and that would take a big chunk of my data quota (and it would take forever too)

With the previous file that gave me this kind of trouble, I could fix it (at least it seemed fixed) by remuxing the TS into MKV with MKVToolNix and then importing into Avidemux, but this time it doesn't help.

[eumagga0x2a]

Do you experience loss of A/V sync with video being ahead of audio when playing the source MPEG-TS file in Avidemux (in the latest available nightly, please)? Or does this occur with the output only?
If the latter, do you re-encode or copy?

In any case, please keep the source video until the problem has been fully assessed.

Additionally, please provide the output of MediaInfo for the MKV created by MKVToolNix (preferably as an attachment as CleanTalk seems to block posts containing MediaInfo output).

[radorn]

Desync occurs both when playing the original TS or remuxed MKV within Avidemux and also when playing cutout exported from it to MKV.
In fact, while the original TS plays fine with SMPlayer, the Avidemux export has the same delay as within the editor.
I have only tried in copy mode, as I didn't see a point in investing time encoding anything that I expect to have out of sync audio.

[eumagga0x2a]

Thank you for MediaInfo analysis, didn't expect it to be the good old MPEG-2.

Indeed, if the problem exists already when playing the source in Avidemux, there is no need to ask about export mode. Is this A/V delay variable (growing) or is it a constant offset?

[eumagga0x2a]

Please delete (or rename) the idx2 index file created by Avidemux for the source MPEG-TS file, open Avidemux, load the MPEG-TS file, close Avidemux and attach admlog.txt from %localappdata%\avidemux directory to your reply. Please compress it (zip) when necessary.

[radorn]

Yes, there are many SD MPEG-2 channels in this country still. The plan was to phase out all SD broadcasting and replace those with HD h264 by the end of last year. A single channel did the transition early last year, but, then, the government announced that they would further delay the deadline for the switchtover, and even that channel that transitioned early, switched right back to SD. I guess they felt silly... Spain is a ridiculous country.

Anyway, to answer your question, the delay seems constant across the entire file. I'm only eyeballing it, but it seems about 3 or 2 seconds, same at the beginning and end.

[eumagga0x2a]

Code Select Expand

[addReferenceVideo] 03:00:59-315 Original frame increment 00:00:00,040 = 40000 us
[addReferenceVideo] 03:00:59-322 DTS going back by 2520000 at frame 456573
[addReferenceVideo] 03:00:59-322 DTS going back by 2280000 at frame 456693
[addReferenceVideo] 03:00:59-323 DTS going back by 2160000 at frame 456970
[addReferenceVideo] 03:00:59-323 DTS going back by 2640000 at frame 464455
[addReferenceVideo] 03:00:59-323 DTS going back by 2640000 at frame 465223
[addReferenceVideo] 03:00:59-323 DTS going back by 2400000 at frame 466370
[addReferenceVideo] 03:00:59-324 DTS going back by 3000000 at frame 485401
[addReferenceVideo] 03:00:59-324 DTS going back by 3000000 at frame 485405
[addReferenceVideo] 03:00:59-324 DTS going back by 2520000 at frame 498531
[addReferenceVideo] 03:00:59-324 DTS going back by 2160000 at frame 506798
[addReferenceVideo] 03:00:59-325 DTS going back by 2280000 at frame 508591
[addReferenceVideo] 03:00:59-325 DTS going back by 2760000 at frame 511011
[addReferenceVideo] 03:00:59-325 DTS going back by 2400000 at frame 512871
[addReferenceVideo] 03:00:59-325 DTS going back by 2280000 at frame 515438
[addReferenceVideo] 03:00:59-325 DTS going back by 2640000 at frame 516726
[addReferenceVideo] 03:00:59-326 DTS going back by 2400000 at frame 517073
[addReferenceVideo] 03:00:59-326 min increment 00:00:00,040 = 40000 us for frame 3
[addReferenceVideo] 03:00:59-326 max increment 00:00:03,120 = 3120000 us for frame 485402
[addReferenceVideo] 03:00:59-326 About 40000 microseconds per frame, 520419 frames
[addReferenceVideo] 03:00:59-326 We have some DTS > PTS, reducing DTS by 170244 microseconds (00:00:00,170)
[addReferenceVideo] 03:00:59-331 We have some DTS > PTS, delaying video by 2949756 microseconds (00:00:02,949)
[addReferenceVideo] 03:00:59-338 The first frame DTS = 0 ms
[addReferenceVideo] 03:00:59-338 The first frame has a PTS > 0, adjusting to 3240 ms
We have to delay video because some decode timestamps in the stream quite close to the end (at approx. 05:04:22) are broken. Could you please provide the last ~20% of the source file as a sample?

Either there is a bug in Avidemux which should shift audio timing by the same amount as video and probably doesn't do that, or audio timestamps in the stream are as bad as video ones. A sample would help to figure that out.

Regarding the handling of this particular video, just shift audio by the indicated amount. However, I would expect audio to be ~3 sec ahead, not behind.

[radorn]

20% of ~10GB is around ~2GB which is not a small chunk of my quota, so I'm afraid I can't do that. (this is the main reason I now record stuff from TV instead of finding a download)

I played that spot you point out in SMPlayer and it indeed breaks up. It seems to be the result of a reception error due to bad signal (DVB-T), which seems to happen often in this channel lately. Luckily it's during a commercial break (EDIT: scratch that, it also happens during one of the programs later, although not as badly).
When playing this spot suddenly audio gets ahead of video, and both start breaking up badly at different points. When things stop breaking SMPlayer accelerates the video until it has catched up with the audio. If I scroll back small steps until the end of the breakups, the part used by SMplayer to smoothly cath-up is also OK itself.
No idea how that can be handled in an editor timeline, so that isolated problem areas don't throw off the entire stream.

MKToolNix job output:

Found at least one B frame without second reference in a non closed GOP.
'D:\TV\bg-2023-02-02 17-06-41.ts' track 2: This audio track contains 152 bytes of invalid data which were skipped before timestamp 05:04:26.040000000. The audio/video synchronization may have been lost.
'D:\TV\bg-2023-02-02 17-06-41.ts' track 2: This audio track contains 232 bytes of invalid data which were skipped before timestamp 05:04:26.064000000. The audio/video synchronization may have been lost.

[eumagga0x2a]

All symptoms you decribe align neatly.

No idea how that can be handled in an editor timeline, so that isolated problem areas don't throw off the entire stream.

I would assume that we need to delay audio by the same amount of time we delay video PTS. If Avidemux doesn't take care of that automatically, you have to do it manually.

You could narrow down the area which should be covered by a sample to less than 100 MiB, it just takes some effort.

[radorn]

I've cut a 32MB chunk containing the main trouble section and a bit of seemingly healthy stream at both ends, and it compresses into about 19MB in 7Zip, so I guess that'll be OK.

https://ufile.io/oq89192f

man, those ads give me cancer...


MORE:  I just found another file, a smaller one, that also has audio sync problems. clearly it has nothing to do with size or duration, as I initially thought. It's just that, given how often this channel seems to suffer from bad reception, a longer recording is more likely to contain the kind of corrupted patches that cause this problem.
Not sure this helps any, but I seem to have a recollection of finding similar transmission problems in earlier recordings, but I don't remember noticing any audio desync then... not saying there wasn't, but maybe it wasn't as obvious as this time, even though there were long patches of extremely corrupted stream.
Could it be that a relatively recent change to Avidemux introduced this bug?

[eumagga0x2a]

Thank you for the sample. Unfortunately, it doesn't allow to reproduce the problem you experience as I get no noticeable loss of sync in Avidemux (but there is a lot of data corruption in the stream, which forces Avidemux to skip to the next keyframe after getting stuck). At least the start of the video doesn't allow to judge, and after the first jump out of the stretch of corrupted frames to the next keyframe, the sync is just fine.

man, those ads give me cancer...

Worse, the site even doesn't properly work in Firefox. So far, WeTransfer has established itself as the best service to provide samples.

Could it be that a relatively recent change to Avidemux introduced this bug?

Yes, [editor] Handle broken videos with DTS being uniformly delayed past PTS and some DTS missing, which allowed to save such videos in copy mode, might have introduced this issue. Prior to this patch, re-encoding was the only option, if at all.

[eumagga0x2a]

Actually, I got misled by the debug messages about DTS going back. They indicate corruption, but they are not directly related to the loss of sync. What matters are the lines

Code Select Expand

[addReferenceVideo] 03:00:59-326 We have some DTS > PTS, reducing DTS by 170244 microseconds (00:00:00,170)
[addReferenceVideo] 03:00:59-331 We have some DTS > PTS, delaying video by 2949756 microseconds (00:00:02,949)
Avidemux currently doesn't log the timing of the frame with the highest DTS-PTS offset. I'll add it tonight, so that once the next nightly becomes available, you could identify the location which a new sample should include. My apologies for avoidable wasting of a part of your data quota.

[radorn]

Thank you for the sample. Unfortunately, it doesn't allow to reproduce the problem you experience as I get no noticeable loss of sync in Avidemux (but there is a lot of data corruption in the stream, which forces Avidemux to skip to the next keyframe after getting stuck). At least the start of the video doesn't allow to judge, and after the first jump out of the stretch of corrupted frames to the next keyframe, the sync is just fine.

Maybe it's because it's in Spanish and it makes it harder for you to notice? I don't know, it's wildly out of sync on my end. I'm using the "win64" nightly from 230111

I meant the ads in the video give me cancer. heh

I have no idea about all these PTS DTS things. Structures of the MPEG-TS format, I suppose, but I don't know what they are or what they do. No point in explaining though.

19MB is OK. I have a bigger quota than last year when I first brought it up. Hundreds of MB would start to be a problem. A GB would be a considerable problem, and up from there is murder, heh.

[eumagga0x2a]

I've enhanced the debug messages, but scratch the above, the sample does allow to reproduce the problem. With improved reporting, I get

Code Select Expand

[addReferenceVideo] 23:39:03-208  We have some DTS > PTS, reducing DTS based on frame 346 by 410244 microseconds (00:00:00,410)
[addReferenceVideo] 23:39:03-208  We have some DTS > PTS, delaying video based on frame 346 by 2269756 microseconds (00:00:02,269)

Delaying audio by the 2270 milliseconds makes sure the start of the sample (after the initial silence) is in sync.

However, if you inspect timestamps of the video around the mentioned frame 346, you get after

Code Select Expand

ed = Editor()
for frame in range(320,360):
    ed.printFrameInfo(frame)
in the script console in Avidemux the following output in the log:

Code Select Expand

Frame 00320 Flags 4000 (B/F) DTS 00:00:15,480 PTS 00:00:15,480 / 00:00:12,680 Size: 9340
Frame 00321 Flags 0000 (P/F) DTS 00:00:15,520 PTS 00:00:15,640 / 00:00:12,840 Size: 10424
Frame 00322 Flags 4000 (B/F) DTS 00:00:15,560 PTS 00:00:15,560 / 00:00:12,760 Size: 10545
Frame 00323 Flags 4000 (B/F) DTS 00:00:15,600 PTS 00:00:15,600 / 00:00:12,800 Size: 10533
Frame 00324 Flags 0000 (P/F) DTS 00:00:15,640 PTS 00:00:15,760 / 00:00:12,960 Size: 10602
Frame 00325 Flags 4000 (B/F) DTS 00:00:15,680 PTS 00:00:15,680 / 00:00:12,880 Size: 10574
Frame 00326 Flags 4000 (B/F) DTS 00:00:15,720 PTS 00:00:15,720 / 00:00:12,920 Size: 10473
Frame 00327 Flags 0000 (P/F) DTS 00:00:15,760 PTS 00:00:15,880 / 00:00:13,080 Size: 10373
Frame 00328 Flags 4000 (B/F) DTS 00:00:15,800 PTS 00:00:15,800 / 00:00:13,000 Size: 10475
Frame 00329 Flags 4000 (B/F) DTS 00:00:15,840 PTS 00:00:15,840 / 00:00:13,040 Size: 10403
Frame 00330 Flags 0000 (P/F) DTS 00:00:15,880 PTS 00:00:16,000 / 00:00:13,200 Size: 10525
Frame 00331 Flags 4000 (B/F) DTS 00:00:15,920 PTS 00:00:15,920 / 00:00:13,120 Size: 10444
Frame 00332 Flags 4000 (B/F) DTS 00:00:15,960 PTS 00:00:15,960 / 00:00:13,160 Size: 10591
Frame 00333 Flags 0000 (P/F) DTS 00:00:16,000 PTS 00:00:16,120 / 00:00:13,320 Size: 11113
Frame 00334 Flags 4000 (B/F) DTS 00:00:16,040 PTS 00:00:16,040 / 00:00:13,240 Size: 13191
Frame 00335 Flags 4000 (B/F) DTS 00:00:16,080 PTS 00:00:16,080 / 00:00:13,280 Size: 12039
Frame 00336 Flags 0010 (I/F) DTS 00:00:16,120 PTS 00:00:16,240 / 00:00:13,440 Size: 21416
Frame 00337 Flags 4000 (B/F) DTS 00:00:16,160 PTS 00:00:16,160 / 00:00:13,360 Size: 1339
Frame 00338 Flags 4000 (B/F) DTS 00:00:16,200 PTS 00:00:16,200 / 00:00:13,400 Size: 34610
Frame 00339 Flags 4000 (B/F) DTS 00:00:19,400 PTS 00:00:19,400 / 00:00:16,600 Size: 28265
Frame 00340 Flags 4000 (B/F) DTS 00:00:19,440 PTS 00:00:19,440 / 00:00:16,640 Size: 32261
Frame 00341 Flags 0010 (I/F) DTS 00:00:19,480 PTS 00:00:19,600 / 00:00:16,800 Size: 47075
Frame 00342 Flags 4000 (B/F) DTS 00:00:19,520 PTS 00:00:19,520 / 00:00:16,720 Size: 17163
Frame 00343 Flags 4000 (B/F) DTS 00:00:19,560 PTS 00:00:19,560 / 00:00:16,760 Size: 32397
Frame 00344 Flags 0000 (P/F) DTS 00:00:19,600 PTS 00:00:19,720 / 00:00:16,920 Size: 31609
Frame 00345 Flags 4000 (B/F) DTS 00:00:19,640 PTS 00:00:19,640 / 00:00:16,840 Size: 21610
Frame 00346 Flags 4000 (B/F) DTS 00:00:17,000 PTS 00:00:17,000 / 00:00:14,200 Size: 6942
Frame 00347 Flags 4000 (B/F) DTS 00:00:17,040 PTS 00:00:17,040 / 00:00:14,240 Size: 14315
Frame 00348 Flags 0000 (P/F) DTS 00:00:17,080 PTS 00:00:17,200 / 00:00:14,400 Size: 14783
Frame 00349 Flags 4000 (B/F) DTS 00:00:17,120 PTS 00:00:17,120 / 00:00:14,320 Size: 14337
Frame 00350 Flags 4000 (B/F) DTS 00:00:17,160 PTS 00:00:17,160 / 00:00:14,360 Size: 6281
Frame 00351 Flags 0000 (P/F) DTS 00:00:17,200 PTS 00:00:17,320 / 00:00:14,520 Size: 10381
Frame 00352 Flags 4000 (B/F) DTS 00:00:17,240 PTS 00:00:17,240 / 00:00:14,440 Size: 29293
Frame 00353 Flags 4000 (B/F) DTS 00:00:17,280 PTS 00:00:17,280 / 00:00:14,480 Size: 22873
Frame 00354 Flags 0000 (P/F) DTS 00:00:17,320 PTS 00:00:17,440 / 00:00:14,640 Size: 23033
Frame 00355 Flags 4000 (B/F) DTS 00:00:17,360 PTS 00:00:17,360 / 00:00:14,560 Size: 23009
Frame 00356 Flags 4000 (B/F) DTS 00:00:17,400 PTS 00:00:17,400 / 00:00:14,600 Size: 22985
Frame 00357 Flags 0000 (P/F) DTS 00:00:17,440 PTS 00:00:17,560 / 00:00:14,760 Size: 44890
Frame 00358 Flags 4000 (B/F) DTS 00:00:17,480 PTS 00:00:17,480 / 00:00:14,680 Size: 598
Frame 00359 Flags 4000 (B/F) DTS 00:00:17,520 PTS 00:00:17,520 / 00:00:14,720 Size: 17730

From frame 339 to frame 345, all timestamps are suddenly delayed by about 2800 ms, then return to what appears to be normal. Avidemux cannot handle this kind of defects. It can fix a uniform shift, but not such a back and forth pattern.

[eumagga0x2a]

Maybe it's because it's in Spanish and it makes it harder for you to notice?

There is no A/V offset after Avidemux jumps to next keyframe once decoding stalls, but during the first advert, it is the noise of water coming out of the nozzle which allows to roughly judge the A/V offset.