Determining GOP structure - open or closed?

[Sotee]

Hi Avidemux team,

I really enjoy using your program and I want to find a way (even if it is 95% accurate) to determine the GOP structure of a video file once loaded into Avidemux.

Are there any tips from you about this?

For example if the following warning appears: "This video uses non-IDR recovery points instead of IDR as keyframes..." does this mean the video is open GOP? Or if the majority of frames preceding keyframes are B-frames instead of P-frames?

Thank you for the great product!

[eumagga0x2a]

I want to find a way (even if it is 95% accurate) to determine the GOP structure of a video file once loaded into Avidemux.

If you mean just frame type and timing, you could open the shell ("Tools" --> "Scripting Shell") and run the command

Code Select Expand

for frame in range(0,300): Editor().printTiming(frame)

to inspect the first 300 frames. On Windows, the output is directed to the Avidemux log file admlog.txt in %localappdata%\avidemux\ directory. If you see a line with "B" (like "B-frame") directly following a line with "I" (like "intra" or "IDR", Avidemux doesn't communicate the difference between the both, unfortunately), the stream is encoded in open GOP mode.

However, the above doesn't work for mp4 files as the mp4 demuxer doesn't flag B-frames (this is why mp4 are loaded very fast, almost instantly, while opening mkv can take minutes to index as we decode every slice header to determine frame type).

For example if the following warning appears: "This video uses non-IDR recovery points instead of IDR as keyframes..." does this mean the video is open GOP?

Yes, exactly that.

Or if the majority of frames preceding keyframes are B-frames instead of P-frames?

No, this is completely unrelated apart from the fact that in a stream with keyframes (which can be either an IDR or a recovery frame), open GOP is impossible without B-frames. However, the presence of B-frames doesn't imply open GOP.

Please note that one cannot delete parts from within an H.264 or HEVC stream of open GOP type and expect the cut point being free of artifacts (i.e. all reference frames being available). This is a fundamental limitation.

The warning you cited is shown when a possibility of a much bigger issue has been detected (the video playback will be stuck at the cut boundary at least until the next keyframe or stop alltogether).

[Sotee]

This is a fundamental limitation.

Yes, I know about that from what I managed to find as available information in Internet. And it's the main reason to make this thread. The error I cited was just in addition to it.

Thank you for the answer. I would really like if you can elaborate more on the GOP topic and how can I detect open/closed GOP through inspection of the frames, or just point me to a resource where a complete explanation of the fundamentals is given.

For example, from the image below I see examples of closed/open GOP, but are these universal aka always valid?



Also, what is Avidemux ordering of frames - presentation or stream?

For example, if we have the following scenarios, can we make a deduction about GOP:

1) BBIBB
2) BBIPP
3) PPIBB
4) PPIPP

Sorry for bombing you with questions, but I really can't find a proper place where this information is explained fully. Anything you write would be of help. Thank you again!

[eumagga0x2a]

The picture you posted is a simplification as in advanced codecs like H.264 B-frames can reference other B-frames, not necessarily just I- and P-frames, but apart from that it is correct.

In the output of the command I mentioned frames are numbered in the stream order. You can't deduct anything about GOP structure with presentation order alone, it is the stream order which matters. If your examples show frames in stream order, examples 1 and 3 match open GOP.

[Sotee]

And I suppose Avidemux timeline (keyframes and markers line at bottom) is in presentation mode, that's why you mentioned the command which is stream?

But in the OP picture stands "display order"... Is that the same as presentation?

[eumagga0x2a]

And I suppose Avidemux timeline (keyframes and markers line at bottom) is in presentation mode, that's why you mentioned the command which is stream?

Exactly. This has significant implications when dealing with non-droppable early B-frames in copy mode.

But in the OP picture stands "display order"... Is that the same as presentation?

Yes, it is.

[Sotee]

apart from that it is correct.

You can't deduct anything about GOP structure with presentation order alone, it is the stream order which matters.

How can the OP picture be correct when it's presentation order?

From link: "I would recommend to bite the bullet and to always re-encode such open GOP streams when deleting a middle portion."

Yes, the problem I have is I lack the ability to properly identify open GOP. I am searching for ways to do this. For example, you wrote: "If you see a line with "B" (like "B-frame") directly following a line with "I" (like "intra" or "IDR", Avidemux doesn't communicate the difference between the both, unfortunately), the stream is encoded in open GOP mode."

Is this rule always valid - for every file I'll inspect this way? And if there are no B frames after I, does this mean it's closed GOP, or there would still be exceptions?

[eumagga0x2a]

The textual explanation in the linked picture is correct.

Is this rule always valid - for every file I'll inspect this way? And if there are no B frames after I, does this mean it's closed GOP, or there would still be exceptions?

In my understanding, this rule is just a rule of thumb with very high quote of success in real-world H.264 streams. To know for sure, we would need to clearly discern keyframes which are IDR and those which are just recovery.

[Sotee]

The textual explanation in the linked picture is correct.

Okay, I think I finally got it. Let's see if this thought process of mine is correct.

Here is open GOP in presentation order:


The same file - open GOP in coded order:


Looking only at the presentation order may not give us the needed information since the B frame (white-circled in first image) theoretically could be after the I frame in the coded order (as is our case here). But when we look at the coded order we could see that the B frame is referring to both the P frame from the previous GOP and the I from this GOP thus we can conclude that the GOP is open.

However, could there exist the following case:
Presentation -> BI
Coded -> IB
But the B frame not referring any P frame at all, which would mean we could have B after I in coded and no open GOP, no?

[eumagga0x2a]

By definition, a B-frame references at least two pictures (in reality, two lists of pictures), one preceding it in time (display order!) and the other following it. Obviously, both sets of references must have been already decoded (in stream order!). Thus it is impossible to have B directly following a keyframe in a closed GOP.

If I haven't missed something, a presence of a P-frame between a keyframe and a B-frame does not guarantee that the keyframe is an IDR, but the real-world occurrence of such cases seems to be at least low for H.264.

In an ideal world, it would be enough to check the NAL unit type to tell whether the keyframe is an IDR or not. In the real world, we get samples with NAL lying and marking non-IDR frames as IDR.

[Sotee]

Thus it is impossible to have B directly following a keyframe in a closed GOP.

Okay, all seems so easy now. Thank you for the quick replies and detailed information!