Avidemux Forum

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

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.