News:

--

Main Menu

Duplicate frames missing, wrong audio delay

Started by /bin/dreams, September 18, 2024, 12:06:56 PM

Previous topic - Next topic

/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

Quote from: /bin/dreams on September 18, 2024, 12:06:56 PMI 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.

Quote from: /bin/dreams on September 18, 2024, 12:06:56 PMFor 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.

Quote from: /bin/dreams on September 18, 2024, 12:06:56 PMThe 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.