Segment skipped in copy mode when first cut not on keyframe

[tommy_tek]

The latest versions of Avidemux have several nice features, but I don't use them since a semi-random corruption problem is present.

I've tried to post this info to the forum in the past, but they're rejected as "spam"...  So here goes again.

It appears that if the first edit/cut point is not started on a key frame, then sometime later all the video (only!) will be dropped between two edit points.  The audio is still present and video resumes at the next edit point.  This sounds a lot like a buffer corruption issue.

Version 2.7.5 does NOT exhibit the issue, all versions since do.  Here are pointers to source, good, and bad outputs at Dropbox:
[ I can't post the links to the forum! ]  It drops the post saying it's spam:
The latest versions of Avidemux have several nice features, but I don't use them since a semi-random corruption problem is present.

I've tried to post this info to the forum in the past, but they're rejected as "spam"...  So here goes again.

It appears that if the first edit/cut point is not started on a key frame, then sometime later all the video (only!) will be dropped between two edit points.  The audio is still present and video resumes at the next edit point.  This sounds a lot like a buffer corruption issue.

Version 2.7.5 does NOT exhibit the issue, all versions since do.  Here are pointers to source, good, and bad outputs at Dropbox:
[ I can't post the links to the forum! ]  It drops the post saying it's spam.
*** CleanTalk: *** Forbidden. Contains contacts. Message seems to be spam. ***

Send email to tkloos@yahoo.com and I'll send the links to you.

[eumagga0x2a]

I'm sorry for inconvenience caused by CleanTalk. Please provide the link to the source video and an exact description of steps necessary to reproduce the issue via personal message.

[tommy_tek]

Pointers are in the attached text file -- including them here causes the whole post to be classified as spam.   Here are the instructions:
delete 00:00:00.000 to 00:01:12.972
delete 00:14:48.954 to 00:18:19.131
delete 00:20:04.169 to 00:24:18.957
Save as MKV with both video and audio in copy mode

The resulting file has 00:14:48.821 to 00:20:04.636 audio only
and no video.

-Tom  You cannot view this attachment.

[eumagga0x2a]

Thank you, I had this sample already, just could not quickly find the topic where you reported the problem for the first time.

The good news: I have identified the issue.

The bad news (or good news number two, as starting saving video in copy mode not on a keyframe makes exactly zero sense): The fix will automatically correct user error to start saving video not on a keyframe.

The background of the problem: when starting saving not on a keyframe, Avidemux has to skip detection of minimum PTS following the first frame of a segment in stream order. As a result, we eventually used wrong (outdated) values when checking whether PTS of the previous segment collide with those after segment switch – and switched segments prematurally. With the given steps to reproduce, this led to the entire second segment being omitted.

Versions prior to 2.8.0 didn't check for PTS collision with early B-frames following segment switch, often resulting in damaged segment boundaries even when users followed all the best practices.

[tommy_tek]

Excellent!  Thanks for looking into this problem.  You are correct that not starting on a keyframe is kind of weird, but starting on the previous keyframe ends up with stuff I don't want displayed and starting at the next keyframe often drops an unfortunate amount of frames thanks to the massive h.264 compression that the CATV systems are doing.  If I can't start cleanly, I almost always aim for black frames to start on.  Some pixelation at the start is less objectionable than the alternatives.
I'll watch for a new nightly to show up and give it a try.  Thanks again.

[eumagga0x2a]

You are correct that not starting on a keyframe is kind of weird

Starting on a frame which is not a keyframe is plainly invalid when in copy mode because the part prior to the first keyframe cannot be decoded. Usually, Avidemux rectifies such a decision automatically by setting the starting point to the previous keyframe, but deleting the part of the video closes this way out.

starting at the next keyframe often drops an unfortunate amount of frames thanks to the massive h.264 compression that the CATV systems are doing.

This is related not to "massive compression" but to the structure of the H.264 stream ("Open GOP") where most keyframes are not IDR (instantaneous decoder refresh) frames but mere "recovery points". This strategy reduces bitrate peaks and thus improves quality when using a channel with constrained bandwidth like in case of a digital broadcast.

The fix I have in mind (I did not commit and push it to the repository yet) will automatically select the next keyframe as the starting point if the original start of selection is not on a keyframe and there is no previous keyframe in the given segment layout.

The warnings Avidemux displays when it detects that cut points are not suitable for copy mode are meant seriously. You really should re-encode video is you need frame-accurate cuts.

[tommy_tek]

Re-encoding for most of what I edit is a major time sink I'm trying to avoid.  Version 2.7.5 generated good enough results with edits not always on key-frames. I'm hoping that the future fix will generate something close to 2.7.5's output.  That's why I included output from 2.7.5 in the Dropbox samples.

You're correct on the "compression" comment.  What I've noticed over the past couple of years is reduced key-frames in the CATV streams.  It used to be that content changes (ie. Program to ad switches, etc.) usually had a key-frame at the boundary, but that's rarely the case now -- often just a few frames of all black.
... eagerly awaiting something to test...  -Tom

[tommy_tek]

It's looks like it's fixed with avidemux_r221015_win64Qt5_145.  As near as I can tell the edits create output that is now the same or nearly the same as 2.7.5.  No missing video.  Many thanks!

[Elstar`]

I guess, fix for last frame in mp4 container solved this one too.