Merge Fields freezing in 2.8.1

[IcePlanet]

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?

[eumagga0x2a]

Thank you for the sample of the original MPEG-TS stream. The issue here is missing support for interlaced HEVC in FFmpeg (in libavcodec).

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.

[eumagga0x2a]

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?

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.

[IcePlanet]

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...):

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.

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...

[eumagga0x2a]

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.

[eumagga0x2a]

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.

[IcePlanet]

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.

[IcePlanet]

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?

[eumagga0x2a]

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.

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.

In 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.

[IcePlanet]

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

No, there are no financial interests involved, no donations expected or even possible.

OK, and even bigger THANK YOU!

[eumagga0x2a]

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).

[IcePlanet]

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.