Problem when saving a selection of mp4 (H264/AVC) with B-frames in copy mode

[Elstar`]

For example, https://www.youtube.com/watch?v=7NE3jpRT11w (youtube 25fps / 3 ReFrames , yt-dlp format 137+140)

Avidemux allows to select end point even if it is not on I-frame but often fails to save entire selection, several frames are missing in resulted video and I forced to search for suitable cut point manually (it is not necessary an I-frame though).

I'd prefer auto-search (shown in GUI) for next viable cut points, both backward and forward or at least an error message instead of silent fail resulting in incomplete video.

And when I do multiple cuts of same video (deleting sections) when start marker of deleted section is not a keyframe, it results in a variable frame rate video even if source is constant frame rate. Maybe, this is because all audio frames in selection are written properly, but video frames are not.

This problem does not appear in P-frame only videos (for example, youtube live streams).

[eumagga0x2a]

This is not a bug but a fundamental limitation of copy mode in video streams which use frame reordering (i.e. B-frames). We need to stop copying frames from a segment when we encounter a frame with presentation timestamp higher than the end of the segments. Such a frame may happen earlier in the stream order than the one right before the cut point.

And when I do multiple cuts of same video (deleting sections) when start marker of deleted section is not a keyframe, it results in a variable frame rate video even if source is constant frame rate. Maybe, this is because all audio frames in selection are written properly, but video frames are not.

We drop so-called early B-frames to reduce the number of pictures which cannot be fully decoded due to missing references. This produces some "holes" in decode timestamps which some players (and mediainfo) interprets as "variable frame rate". The alternative would be more damaged pictures at cut points.

[Elstar`]

This is not a bug but a fundamental limitation of copy mode in video streams which use frame reordering (i.e. B-frames). We need to stop copying frames from a segment when we encounter a frame with presentation timestamp higher than the end of the segments. Such a frame may happen earlier in the stream order than the one right before the cut point.

Could you implement at least a warning when cut point is on wrong position? A GUI scan for valid cut points could be useful too...

[eumagga0x2a]

Could you implement at least a warning when cut point is on wrong position?

There is a warning if there is a sufficient reason to warn (the warning about retrograde POC, a situation FFmpeg-based video players don't master gracefully). But I don't think that displaying a warning almost every time (depending on the structure of the video stream) users edit a video in copy mode is a good way to educate them. Basically, stream copy mode is a best-effort adventure, with no guarantees whatsoever.

A GUI scan for valid cut points could be useful too...

...to show a user in an all-intra video of one hour duration at 25 fps a list of 4,049,955,000 valid cut points?

[Elstar`]

But I don't think that displaying a warning almost every time (depending on the structure of the video stream) users edit a video in copy mode is a good way to educate them. Basically, stream copy mode is a best-effort adventure, with no guarantees whatsoever.

I mean, warn when saving such selection in copy mode (when saved video length is not equal to selection).

A GUI scan for valid cut points could be useful too...

...to show a user in an all-intra video of one hour duration at 25 fps a list of 4,049,955,000 valid cut points?

No, jumping to nearest valid cut point forward or backwards (like jump to keyframe) could be enough. I mean, if it is technically possible to cut not on I-frame, it's better to reveal valid cut points, instead of manual trial and error.

[eumagga0x2a]

Setting a cut point at a picture and having the output being cut short of it doesn't make the cut point invalid and – much more – it doesn't make the action of setting a marker to that picture (to the PTS of that picture) invalid as Avidemux cannot know in advance what this marker is for (it doesn't detect emanations of brain waves). Editing video streams with frame reordering is a best-effort operation and cannot provide frame-accurate results. Just accepting that is the right way to handle the reality, IMHO.

Regarding the unrelated issue with warnings about retrograde POC, warnings, which have become necessary only due to a particular way libavformat, a part of FFmpeg, (mis)handles the case of discontinuities in POC changes between adjacent frames (a lot of non-FFmpeg-based software and devices handles POC discontinuities just fine), it depends both on relative and absolute positions of both "ends" of a deletion or of an insertion and needs to know in advance the action the user is going to perform on the future selection. This means, we are back to the brain waves thing.

[Elstar`]

Setting a cut point at a picture and having the output being cut short of it doesn't make the cut point invalid and – much more – it doesn't make the action of setting a marker to that picture (to the PTS of that picture) invalid as Avidemux cannot know in advance what this marker is for (it doesn't detect emanations of brain waves). Editing video streams with frame reordering is a best-effort operation and cannot provide frame-accurate results. Just accepting that is the right way to handle the reality, IMHO.

Well, the length of selection is known and the length of actually written video from this selection could be known too, so we can compare those values and output a warning.

And implementing a way to determine the exact safe cut point (when selection = actually written frames) would be great.