Issues with cutting of h264

[Jan Gruuthuse]

You missed "could be" in my previous posting.
Development goes faster then documenting. Most documentation is from 2.4/2.5 Some parts are newe/updated/under review. On Bottom page of avidemux wiki you would find a Last modified date, this would give you an idea on recent or not
This is a slow process and has lesser priority. There is a great time deficit on the development side (Huge time shortage).
This is my understanding as user of the whole process.

[dosdan]

This is a voluntary affair, with most of the work coming from "mean".  Coding is more intellectually stimulating than writing documentation, so it's understandable that the documentation for most small projects is way behind.

Some users, although not good at coding, are OK at describing how to perform specific tasks, and contribute a tutorial. Sometimes this helps to fill in the information void.

But the main documentation is usually stale. For example, look at the user manual for the RawTherapee project

Dan.

[framesurfer]

Please don't get me wrong, I really see and appreciate the huge effort behind this how you call it "small project"!!
I still try to figure out, which reason / usecases could have been led to the design change from [A,B) to [A,B] during saving.
I could think of if B is at the end of the video, you would like to save until the last frame, maybe there are other of such usecases (?).
In the case you save snippets of a video in copy mode at keyframes, I would rather prefer the old design.
Maybe there should be a differentiation between last frame is an Iframe or not.
What do others think of the best design?

[mean]

Some frames could be orphans
i.e. they depend on frames that are showing later and have been cut out, as a result they are dropped as impossible to decode without their non existing reference

[framesurfer]

Hello mean,
yes thats clear and I tried out with my initial experiment how Avidemus copes with it and it does well.
In case the selection is IBBBPBBBPBB the saved GOB is IBBBPBBBP to avoid orphans.
In case the selection is IBBBPBBBPBBBPI (which I saw as quite common) IBBBPBBBPBBBP would be a good decision to save.
In case the selection is IBBBPBBBPBBBI just avoiding the last IFrame would lead to orphans, but IBBBPBBBP (ommitting the succedding BFrames) would be the best compromiose in my opinion.
I read a lot about referencing over severeal frames and even Iframes, what could of course still lead to artefacts, but here I am missing the detailed know how.
One solution could be to make the behaviour configurable(?).

What do you think about the noncontinous pts_time at the end of a saved snippet nd the start pts_time greater than 0 in case BFrames are present (I even had a look in the source code, but couldn't figure it out so far, since I am not much used to C and never did C++ programming)?

[mean]

The reorderding introduces a delay
If you video is IPBB, it will decode I & P but their PTS will be in the future as it must wait 3 frames to start outputting frames
i.e.

IPBB
xxxIBBP

[framesurfer]

Thanks a lot for information.
I will have to think about that.
Can you tell me in which source file and function this waiting procedure is performed?

Btw: Is the writing of the container performed by ADM directly or by a call of ffmpeg?

[mean]

There is no wait, the PTS is computed depending on the use case
There is no call to ffmpeg, only calls to libavformat when appropriate