Eternal loop in exporting corrupted ts video file

[TheOldTaylor]

Good evening everyone.
I recorded the TOPcrime (AC3, ita) Colombo.ts file using a TV tuner stick.
During the recording some reception anomalies occurred, which I have summarized in the attached table.
Avidemux 2.8.1 (installed 19th September 2022) is able to display all the contents of the file image by image, apart from of course the frames that have not been received.
However, if I try to export the video and it contains even a single frame of what I have called critical section, the export process falls into an eternal loop and must be stopped by the task manager.
I can not send you the original video file, because it is 2.44GB large and I can not export the critical section. Is there a way to send you it?
Thanks in advance for your disponibility.

[eumagga0x2a]

Please use any file splitter like HJSplit to find the problematic section and provide a neatly small sample. Alternatively, platforms like Dropbox and Google Drive allow sharing (link sharing, not requiring the recipient to possess an account) of files beyond 2 GiB in size (actually, I already got samples over 10 GiB).

Unrelated to the current issue, I strongly recommend updating to the latest 2.8.2 nightly (once ffmpeg5x lands in master, this recommendation might cease to be valid for a while, but at the moment, 2.8.2 nightlies are just the 2.8.1 release with a few crashes fixed).

[TheOldTaylor]

Thank you very much for your prompt reply.
I found HJSplit and divided the file into 256 kB blocks, but the anomaly affects 79 blocks, from 4712 to 4790 extremes included.
Given the limitations that the forum places on the number and size of attachments, I don't think I can send all this material via the forum and I would need an e-mail address to send everything to.
Could you send me an address on my mailing address, which you certainly know. I undertake not to disclose it.

[eumagga0x2a]

I found HJSplit and divided the file into 256 kB blocks

That is too small, please upload a sample between 50 and 100 MiB in size to WeTransfer (no email address required, despite the website suggesting otherwise!), Mega, Dropbox or Google Drive and provide the link either in your reply or (if CleanTalk intervenes) via a personal message.

Could you send me an address on my mailing address, which you certainly know

No, as a forum moderator, I have no access to such sensitive information, which is a relief.

[eumagga0x2a]

Regarding the sample, it should ideally begin and end with undamaged video, with the bad part inside.

[TheOldTaylor]

You can download the TOPcrime (AC3, ita) Colombo 154.ts file at the link https://we.tl/t-6swytDI6Wx.
For comparison, I update the timing table of the two files.
Thanks for the support.You cannot view this attachment.

[eumagga0x2a]

Thank you for the sample, confirming the hang in the MPEG-TS demuxer (no need to export the file, playing it is enough to trigger the issue). Will look into it later.

[TheOldTaylor]

Thanks to you for your patience. I hope I was helpful. Available should you need more.

[eumagga0x2a]

Just in case this happens to be useful, the hang with the provided sample is related to the first (E-AC3, language: Italian) audio track. Disabling this audio track works around the issue.

[eumagga0x2a]

Should be fixed now by [coreAudio,coreAudioParser] Flag E-AC3 frame followed by garbage data as damaged, discard it and try to resync to fix infinite loop, not related to MPEG-TS demuxer after all.

Thank you for your report.

[TheOldTaylor]

I understand, but I need the audio in Italian and, when I tried to export the audio in advance, the application stopped looping in the same way. No way to patch up the damage being analyzed? Or at least to avoid blocking the application and provide the user with a precise indication for the location of the damaged part of the file?
In the current conditions I worked almost six hours just to identify the extremes of the damaged section.

[TheOldTaylor]

I have found additional data that may be useful to you.
By playing the clip I sent you, I verify that the playback stops at 19.880 seconds.
To ensure that the playback does not stop again, it must be restarted no earlier than 26,600 seconds.
With these two limitations (automatically) identified, couldn't you just mute the audio for those 6,720 seconds?
The solution I temporarily gave to the problem was to export the entire recording from the beginning up to 01: 16: 07.120, export the rest of the recording from 01: 16: 20.750 to the end and then remount the two segments in a single file.
In this way, however, I lose over 13 seconds of film, audio and video, while with my proposal it would lose less than 7 seconds of audio alone.

[eumagga0x2a]

Maybe I was unclear: the bug (infinite loop when the buffer containing an E-AC3 frame started with the frame itself, but wasn't followed by the next one, which means that either some garbage followed the frame or the size of the frame was bogus) is fixed (or rather taped over). The next nightly build won't choke on this sample.

However, a proper fix needs to implement checksum verification in order to know for sure whether the frame is damaged or not.

[TheOldTaylor]

Forgive me but I struggle to follow you, not being a video editing specialist.
What I am interested in knowing with the next release is if you intend to solve the problem of the program crash.
As a software engineer with 50 years of experience on my shoulders, I understand very well that a problem like the one I have reported cannot be solved with a patch stuck on the fly: however, the important thing is that it will be addressed as soon as possible.