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 (https://avidemux.org/smif/index.php/topic,16420.0.html) 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: admlog_crash.txt
Media info of file being processed: MediaInfo.txt
Py script file of Avidemux (Filters applied in order "Merge Fields" - "DelogoHQ" - "Crop"): Crash test.zip (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).
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.
Thank you for the fix. Will check when next nightly is available. Currently I see latest nightly from 8 SEP 2024.
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).
Please provide a sample, I cannot reproduce the crash with videos from my collection.
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
Quote from: IcePlanet on November 29, 2024, 07:32:37 AMThis .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.
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.
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.
Can reproduce the crash from logic error handling odd number of input pictures (fields). Fix inbound.
Should be fixed by [fields] Fix crash with odd number of input pictures (https://github.com/mean00/avidemux2/commit/7f025309edda9ae9cd02cffdeb5fb0664a1336b6). 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.
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.
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.
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.
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.
I made small experiment (in analyzing the even/odd frames) and I'm not sure about the results. Can please someone explain me why I keep getting one frame more than expected.
Steps to reproduce:
1. Load the reenc.ts video to Avidemux
2. Put marker B anywhere in video and cut (cut from beginning of video to the randomly placed marker)
3. Place marker A precisely on position 00:00:00.600 and cut (cut frame at position 00:00:00.600 and all future frames) this should result in 30 frames remaining in our (50fps) video
4. Validate that timer shows your first frame as 00:00:00.000 and last frame as 00:00:00.580 (=30 frames)
5. Place marker A on 00:00:00.200 and B on 00:00:00.380 (this should be 10 frames) and cut out this section
6. On paper calculate how many frames should remain (my result is 20, which should equal time 00:00:00.000 to 00:00:00.380)
7. In Avidemux go frame by frame and calculate frames - there are 21 frames remaining and the last frame is 00:00:00.400
Sorry if my question is too newbie, but it is first time that I'm looking at frames in this level of detail. Did I misunderstood the markers positioning? Or I'm doing something wrong? Where the +1 frame comes from? Is B marker part of selection or not?
In mathematical representation do we speak about interval [A,B) or about interval [A,B] when cutting by markers?
Thank you for the sample of the original MPEG-TS stream. The issue here is missing support for interlaced HEVC in FFmpeg (in libavcodec) (https://trac.ffmpeg.org/ticket/5514).
However, Avidemux indicates clearly which picture is actually a top field (TFF) and which is a bottom one (BFF). Just make sure markers for a deletion are both set to pictures which are TFF and you should be fine.
No issues with A/V sync with the original stream whatsoever. Video, processed by "Merge Fields" and VDPAU deinterlacer in picture-per-field mode and re-encoded with Nvidia HEVC with audio in copy mode, muxed into MKV, plays with perfect sync in mpv and in Avidemux on my system.
Quote from: IcePlanet on November 30, 2024, 08:58:43 PMDid I misunderstood the markers positioning? Or I'm doing something wrong? Where the +1 frame comes from? Is B marker part of selection or not?
Nothing wrong with your logic, I've messed up (again). B is not a part of a selection, thus a picture marked as B stays when selection is deleted. This means that both markers must be set to pictures representing top fields, a trivial task when using the original MPEG-TS stream and nearly impossible after VLC has destroyed the field info.
Thank you for explanation of the markers, this is confirming my experiments and now I hope I understand.
I'm not sure if I can understand your explanation with the audio timing (to be precise I'm sure I can not...):
QuoteNo issues with A/V sync with the original stream whatsoever. Video, processed by "Merge Fields" and VDPAU deinterlacer in picture-per-field mode and re-encoded with Nvidia HEVC with audio in copy mode, muxed into MKV, plays with perfect sync in mpv and in Avidemux on my system.
In the AudioTest package (the one where was original file as recorded by satellite box) was also mkv file as encoded by Avidemux (using the original recording - without VLC step, py script attached also). If you look at
3:12,
7:43 you clearly see the audio is late - sorry it is not English, but it is clearly visible, in original recording you can see the same positions at
11:38,
16:11 and the audio is perfectly in sync.
Getting rid of VLC pre-processing would be great (see also description below, one more reason to get rid of vlc as middle step), but I can not understand what should I do? How to get it in sync? Can you please advise more what should I do to get correctly timed result (audio + video in sync)?
The TFF and BFF indicators are showing in my Avidemux (release 2.8.1) for both, the original TS as recorded and VLC re-encoded TS.
After your last information I made one more test where I paid extreme attention to cut correct number of frames. For example when searching for A cut pointer I always use only times ending with 000,040,080 (odd frames)... For B pointer the same (because real cut is one frame earlier - even frame). In theory after cut only even number of frames should remain. But still received crash (that is supposedly caused by odd number of frames). Checked both files (still working with the same files as in provided archives) and when I opened both files (the original recording and the VLC processed one) and go to time 01:09:24.940 then in original recording I see BFF (which should be correct because .940 equals to 48th frame in second = even frame = BFF), but in the VLC processed one I see TFF. By the preview on the screen you can guess that some frames have been added (?!) by VLC processing because VLC processed one is showing "Guest stars..." but in original the last frame with "Guest stars..." is 01:09:24.660 (34th frame, marked as BFF = ?correct?), in the VLC processed one the last frame with "Guest stars..." is 01:09:25.760 (39th frame, marked as BFF =
?WRONG by number? but
?correct because of corresponding frame in original is also BFF?)
Still I do not understand this somehow, will continue trying...
First of all, please just forget the release version (2.8.1). I'll request a refresh of nightlies shortly.
No A/V sync issues means no matter how hard I tried, my Avidemux, built from the latest git master and using hw accelerated decoder and video display, played the original file with a satisfactory A/V sync. I checked about a dozen of segments in the video for a few minutes each.
I processed the original file deleting adverts, combining fields into deinterlaced progressive pictures, re-encoded by a hw accelerated HEVC encoder rather than x265 for the sake of speed (took approx. 10 minutes for the entire video to complete) especially as the visual quality of the source is very poor.
The result played in mpv and in Avidemux with the same apparently perfect sync as the source.
Your processed file showed poor sync, indeed.
To avoid the crash in the "Merge Fields" video filter without the patch, please set the B marker to a top field rather to the end of video when saving.
Spend some time now with the nightly (10.11.2024), tried multiple configurations and still see the timeshift of audio when using original recording directly in Avidemux.
The only way to guarantee sync is to have "copy" for audio and video. As soon as I start encoding one of them (or both) AND use the original recording (without VLC re-encode) the shift is there. Can you please provide your py file I would like to test and see what I have configured different/wrong.
In the encoded video I always check the 2 places as mentioned before (3:12, 7:43 - which correspond to original time 11:38, 16:11).
Sorry not yet tried the crashing solution, was playing with audio.
Have tried nightly from 12.12.2024 and it is not failing any more on the videos where old version was failing. Shift between audio and video is also resolved - thank you very much!!!
During testing the new version there is one small problem remaining: When identifying cut points it is difficult to create them only based on video. The audio inside Avidemux is significantly shifted. It is shifted when playing inside avidemux 'normally' and also in situation when "play filtered" is used inside avidemux. Is any possibility to fix audio also inside Avidemux?
In Avidemux I do not see any donation option or 'buy me coffee'. Do you have anything like this?
Quote from: IcePlanet on December 15, 2024, 12:22:24 AMThe audio inside Avidemux is significantly shifted. It is shifted when playing inside avidemux 'normally' and also in situation when "play filtered" is used inside avidemux.
Can it be that you use bluetooth headphones? I don't experience any noticeable loss of sync on my PC with conventional loudspeakers connected to the line out jack.
Quote from: IcePlanet on December 15, 2024, 12:22:24 AMIn Avidemux I do not see any donation option or 'buy me coffee'. Do you have anything like this?
No, there are no financial interests involved, no donations expected or even possible.
I'm using standard speakers connected to line out. I have not experienced any audio shift in finished encoded file, no audio shift in other media, with different players...
Please try to look at the original .ts (not the reenc) and check
16:08, there is only one word said (by the woman in car) so it is easy to check if there is audio in sync or not.
If the .ts plays OK on your Avidemux, maybe there is something in settings of Avidemux or windows?
Attached is short video (camera pointed on display) where the delay is visible. It is quiet you need to add volume to hear it. It is only 2MB here https://we.tl/t-OJ0Qfr4pdc
QuoteNo, there are no financial interests involved, no donations expected or even possible.
OK, and even bigger THANK YOU!
Confirming significant and seemingly hardly correctable audio delay at that "Ahoj!" moment when playing the original stream, removable by saving the video to MPEG-TS with both video and audio in copy mode and also not present when video is re-encoded (audio still in copy mode) and saved as MP4 or MKV. Not sure what is going on here.
The most remarkable issue is Avidemux being unable to open an MP4 (probably also MKV) file produced by saving the original stream in copy mode (MPEG-TS seems the only option that works).
And if I take the .ts file showing delay in Avidemux, run the VLC (reencode) command, the resulting file does not show any delay in Avidemux.
The question for me is if this is something inside Avidemux (?) or something inside the .ts recording that makes this strange behaviour?
Can I be somehow helpful in analyzing this more?
Edit: Only to explain background, I not always cut by screen, sometimes the audio stream is equally important when creating cut points.