Duplicate frames missing, wrong audio delay

[/bin/dreams]

Hi everyone,
I'm not sure if this is the right place to report bugs, but I found that avidemux incorrectly handles (+) frames. I'm not sure what they are actually called, but this is what virtualdub marks them as in the GUI. I think they are just duplicated frames. Avidemux does not display these frames at all, but the next frame after (+) correctly displays the timestamp as if i moved through two frames instead of one.

For example, in an mkv video I encountered, VirtualDub shows frame types (K)-(P)-(+)-(+)-(K) and each frame adds 41ms to the timestamp;
Avidemux instead shows:
(I) - 0ms on the timestamp
(P) - 41ms
(I) - 166ms

The problem started when I tried to cut out the (K)-(P)-(+)-(+) frames. Avidemux reencoded the video, but added a delay of 83ms in the mkv container metadata. Presumably this is done to keep audio in sync, but the delay is incorrect. It should have been 166ms. I suspect it was calculated based on the number of frames and since two (+) frames were not displayed the delay was incorrect.

If it helps, the video steam was a HEVC format, V_MPEGH/ISO/HEVC codec id, 23.976 (24000/1001) FPS.

[eumagga0x2a]

I found that avidemux incorrectly handles (+) frames. I'm not sure what they are actually called

Never heard of such a thing. I suspect that this is just a fictional concept specific to VirtualDub to handle variable frame rate videos or videos with gaps in timestamps.

For example, in an mkv video I encountered, VirtualDub shows frame types (K)-(P)-(+)-(+)-(K) and each frame adds 41ms to the timestamp;
Avidemux instead shows:
(I) - 0ms on the timestamp
(P) - 41ms
(I) - 166ms

Please provide a sample via WeTransfer, Mega, Dropbox or Google Drive.

The problem started when I tried to cut out the (K)-(P)-(+)-(+) frames. Avidemux reencoded the video, but added a delay of 83ms in the mkv container metadata. Presumably this is done to keep audio in sync, but the delay is incorrect. It should have been 166ms.

Can't tell without a sample and exact steps to reproduce. Is audio of in the resulting file out of sync with video when played in a proper video player? Is it out of sync when played in Avidemux either?

[alexstorm]

bd,

Are you referring to content with 3:2 pulldown, every 4th frame in a series is duplicated.. 1,2,3,4,4,5,6,7,8,8...?

Your media is set to 23.976.  This usually happens when content has 3:2 pulldown removed and is reset to the slower frame rate that is very close to the original 24 fps.

29.97 / 5 * 4 = 23.976

If your copy is already on 23.976 fps and still has 3:2 pulldown with duplicate frames, then I think it fps was changed without successfully pulling out the duplicate frames. Ideally, get the original media running at perhaps 29.97 or better yet, the master running at 24 fps.  I think encoders often fail to do a good job at 3:2 pulldown conversion back to 23.976 for various reasons.  If any logo is added or any edit made, then the 3:2 sequence can get out of order.  Automatic dupe frame removal hardly ever works perfectly.  This is why the VirtualDub filter has a blend option.  This blurs over movement in the frame to reduce image stuttering.

If you don't have a previous generation of the media to use, then try using the blend option in the filter and see if the result looks better.

Hope that makes sense.

[/bin/dreams]

Please provide a sample via WeTransfer, Mega, Dropbox or Google Drive.

Here you go. https://drive.google.com/file/d/1B3gCBFA1pLinftLKu4_clGMrBnsbkvIB/view?usp=sharing
Try cutting out the first two frames, so the video starts from the second I-frame at 0.166 seconds. Then check the mkv start_time that was added:

Code Select Expand

ffprobe -hide_banner -show_entries stream=start_time "edited_file.mkv"
By the way, avidemux ALSO adds a delay when I cut frames AFTER the ephemeral (+) frames, such as from the end of the video. Obviously it should not have been adding any delay at all in such a scenario. Fun!

[eumagga0x2a]

Thank you for the sample. I don't see any buggy behaviour of Avidemux saving it in copy mode (you obviously implied copy mode) starting with the second keyframe. The delay you are concerned about is inevitable and a result of the choices made when Avidemux was designed: contrary to e.g. FFmpeg which uses signed values (int64_t) for timestamps, Avidemux uses unsigned ones (uint64_t). This means that while FFmpeg can assign negative decode timestamps to the first few frames which must be decoded before we can display the first picture, Avidemux can't. Instead, it has to delay all timestamps by the amount of time it takes to avoid decode timestamps wrapping around (as no negative values are possible).

[eumagga0x2a]

Ah, forgot about that "+" frames: there are none. As suspected, a purely fictional crutch VirtualDub needs to handle gaps in timestamps.

[/bin/dreams]

I don't see any buggy behaviour of Avidemux saving it in copy mode

The way I see it, only one of these two values can be correct:
1. The GUI that shows the second keyframe position at 166ms;
2. The offset after cutting which is 83ms.

I'm not saying that the offset should not be there. But, either we have just cut 166ms and should offset other tracks by 166ms, or the timestamp which showed 166ms in the first place was wrong. And since other editors also show the second keyframe at 166ms i think it's the offset that's wrong.

What am I missing?

[eumagga0x2a]

The delay has nothing to do with the presentation timestamp (PTS) of the second keyframe in the source video. It is required to avoid negative decode timestamps (DTS) for a video with B-frames present (frame reordering delay) and would be equal zero if B-frames were absent.