Merge Fields freezing in 2.8.1

[IcePlanet]

I'm very happy with Avidemux, but recently I see lot of freezes when processing interlaced content.

My Avidemux (2.8.1) is freezing when applying Merge Fields filter from Interlacing section. What I'm trying to accomplish is to convert from 50 FPS 1920x540 to 25 FPS 1920x1080.

The freeze occurs at end of first pass. Empty dialog box is thrown and Avidemux freezes.

Have found similar topic here but it seems as abandoned or resolved (depending what posts you look at).

Below is information about video file, py script and log file from Avidemux ending with:

[ADM_Composer::nextPictureInternal] 20:39:12-839 Next image PTS in ref is out of range: got 3951040000 us, wanted < 3951025378 us, discarding the image
[ADM_Composer::searchNextKeyFrameInRef] 20:39:12-839 Found nextkeyframe 3951780 1:5:51 at frame 197308
[ADM_Composer::nextPicture] 20:39:12-839 Cannot get next picture. Last segment
[ADM_videoFilterBridge::getNextFrameAs] 20:39:12-839 [Bridge] Base did not get an image
Saving crash file to C:\Users\Ice\AppData\Roaming\avidemux\crash.py
   ...   <Skipped some lines>   ...
Crash Dump for Assert failed :src->_height==_height at line 29, file F:\jenkins\workspace\VS2019_no_import\avidemux_core\ADM_coreImage\src\ADM_imageOperation.cpp

Have I done something wrong or is this bug?

Crash log of Avidemux: You cannot view this attachment.
Media info of file being processed: You cannot view this attachment.
Py script file of Avidemux (Filters applied in order "Merge Fields" - "DelogoHQ" - "Crop"): You cannot view this attachment. (zipped due to py not allowed to upload)

Edit: There are cuts done to the file, but cuts are done only on keyframes (with up and down arrows).

[eumagga0x2a]

I've fixed the issue of timebase being not recalculated in the "Merge Fields" video filter, not able to reproduce a crash (yet) using the current git master. Please try a future nightly.

[IcePlanet]

Thank you for the fix. Will check when next nightly is available. Currently I see latest nightly from 8 SEP 2024.

[IcePlanet]

I have downloaded latest nightly 241110_7baa0b8ab6b-fflibs 7.0.2.

The freeze is still there. Media info and .py file are the same as in first post. Log ends with:

<!>20:23:57-124 [ADM_Composer::nextPictureInternal] Next image PTS in ref is out of range: got 3951040000 us, wanted < 3951025378 us, discarding the image
  20:23:57-125 [ADM_Composer::searchNextKeyFrameInRef] Found next keyframe: frame 197308, ref time 01:05:51,780 (3951780000)
<!>20:23:57-125 [ADM_Composer::nextPicture] Cannot get next picture. Last segment
<!>20:23:57-125 [ADM_videoFilterBridge::getNextFrameAs] [Bridge] Base did not get an image

Attached is actual complete log file (zipped).

[eumagga0x2a]

Please provide a sample, I cannot reproduce the crash with videos from my collection.

[IcePlanet]

This error happens 'randomly' in cca 1 file from 20, but when it happens on the 1 file it happens there always.

File was recorded with VU+ (satelite receiver) and it was send like this via satelite (there is no re-encoding in the satelite box activated). From the box I download .ts file.
This .ts file can not be directly processed by Avidemux because the audio and video will be out of sync. As first step I used VLC to re-encode it.

Command for vlc re-encoding is (using windows, sorry):

"C:\Program Files\VideoLAN\VLC\vlc.exe" -I dummy "20240915 1640 - Markiza Klasik HD - A-Tím II (21).ts" ":sout=#transcode{scodec=none}:std{access=file{no-overwrite},mux=ts,dst='20240915 1640 - Markiza Klasik HD - A-Tím II (21) reenc.ts'}" vlc://quit

Then the re-encoded file is input for Avidemux.

If I cut only 10min sample it encodeds in Avidemux properly. For this reason I'm providing complete file (the file is already re-encoded by VLC no need to run the vlc re-encode, command above is provided only to explain the background). The password to open the archive is at end of this post. Download is available for 1 week from now.

In the archive there are two .py files. Because the regular 2.8.1. release .py file is not correctly read by nightly. For this reason for nightly please use the .py file named nightly and for release version use the one named release.

Link to download is https://www.filemail.com/d/indsxcstrddjiap

lh2eGxwZbjN7rpX5VcSmMU3yRIsvLK1Y

[eumagga0x2a]

This .ts file can not be directly processed by Avidemux because the audio and video will be out of sync.

Please provide a sample. This looks like a real issue worth of being investigated.

Please use one of recommended services (WeTransfer, Mega, Dropbox or Google Drive) for providing samples – I had to abort download from filemail due to analog-modem-like speed. Will retry overnight.

[IcePlanet]

Sorry, please see uploaded to

Google drive: https://drive.google.com/file/d/1o22DOnLGK-WAMVCEwi6oKKzi5J1Aa6UD/view?usp=sharing
Mega: https://mega.nz/file/QmUFQLJJ#DURxfwAuZi3oqqVsUtWZmr6T3TKVec9szHGW-FHXzyk
WeTransfer: https://we.tl/t-nOCvyr72uQ?utm_campaign=TRN_TDL_05&utm_source=sendgrid&utm_medium=email&trk=TRN_TDL_05

All 3 uplaods contain the same file. Please select the one fastest for you.

[eumagga0x2a]

Now my time to apologize, have successfully downloaded the sample from filemail and just waited maybe half an hour instead of immediately reporting it here.

(edit: Anyway, a download from WeTransfer runs ~20 times faster than from filemail for me, limited only by my internet connection.)

However, it would be great to obtain a (small if possible) sample of the original MPEG-TS which results in a bad A/V sync in your experience.

[eumagga0x2a]

Can reproduce the crash from logic error handling odd number of input pictures (fields). Fix inbound.

[eumagga0x2a]

Should be fixed by [fields] Fix crash with odd number of input pictures. Please try a future nightly.

This crash (assert failure = a safe termination of the application on an unrecoverable error) existed for the entire lifetime of the "Merge Fields" in Avidemux >= 2.6 (i.e. for over 12 years).

Thank you for your report.

[eumagga0x2a]

By the way, if a reference video in Avidemux consists of pictures which are actually fields, you absolutely must ensure that deletions inside such a video always start at an odd picture and end at an even one, else you would end up with inverted parity after applying "Merge Fields". As there are no comfortable means to accomplish this in Avidemux, fulfilling this requirement is definitely not fun.

[IcePlanet]

Thank you very much for fast investigation and response.

I'm looking forward to try the next nightly.

12 years: Wow, this is clear proof that satellite providers have moved to low quality video streams. Normally stream from satellite was 1920x1080@25 at cca 5Mbit. Now there are crazy streams like 1920x540@50 or 720x288@48 and the bitrate has dropped to cca 1Mbit.

Merge fields and number of frames: Not sure if it is related, but some videos are processed perfectly and some end up with very visible artifacts (in my understanding what happened is that picture 1&2 should be combined but instead 2&3 was combined - is this the inversed parity?), this is not nice, sometimes changing the cut points help, sometimes not. I have no idea how to 'correctly' identify the cut point. There is at the bottom frame type displayed, maybe it will help in identification of cut points if there will be also Frame number displayed?

To audio sync issue: Have deleted my old testing attempts (originally I was also encoding audio, but now shifted to copy only) running test encoding now and when the .py is ready and I have confirmed that shift is there will send more information. Will try to cut the file smaller, but the cut operation implies re-encoding and I have never observed the audio shift on re-encoded .ts. Please give me some hours on this as I expect more test encodings will be needed.

[eumagga0x2a]

I need to have a look at the original stream to assign blame.

Yes, exactly that regarding inverted parity. There is no easy way to tell that the A marker for a deletion is set to an odd picture while the B marker is set to the even one both markers are set to odd pictures other than counting pictures from the start of the video.

Maybe by identifying the approximate location of a cut, then using scripting to decode the video up to that location to check the parity.

No re-encoding or any other processing allowed to reduce the size of a sample. Please use tools which cut / split files just by number of bytes like head, tail or dd on *nixoid OSes.

[IcePlanet]

The cut-out was not working for me. Sorry for big file again.

In the zip file you can see 3 files.
.ts - original as satellite receiver has recorded - this file was re-encoded by VLC (command posted in this thread on November 29, 2024, 07:32:37 AM) and then included in previous big download (CrashTest.7z)
.py - Command for release version of Avidemux to create .mkv
.mkv - resulting file you can see beginning showing out of sync audio, end showing OK audio

Because we already started with this file I tried to keep it. Here the shift is not a lot, on some files it is bigger on some smaller.

Google drive: https://drive.google.com/file/d/1f4fFT5cuu7rDdWvgTg31W21LyxXktZKl/view?usp=sharing
Wetransfer: https://wetransfer.com/downloads/2e19c6fe1165efe717a02b774d000d6a20241130130513/c404e2eadeb31cf8a5c5ce492e5f497720241130130513/f9370e?t_exp=1733231113&t_lsid=48501fb7-b7c9-4e2e-a826-bd568e72e899&t_network=email&t_rid=ZW1haWx8Njc0YTJlYzViNjM1NTFjNmY2YWY4YWQ0&t_s=download_link&t_ts=1732971913&utm_campaign=TRN_TDL_01&utm_source=sendgrid&utm_medium=email&trk=TRN_TDL_01
Mega: https://mega.nz/file/knt2WbIC#cBLXmccXLIv9UThoTlw_eFLKjbTaYi5H0ZDJ-E17ZmA

Pass is the same as last time.