Closed GOP and IBBPBB GOP structure issue

[Zenitram]

(I don't know if it is the right place for this kind of question, let me know a better place if any)

I have a encoded MPEG-2 Video file with closed_gop=1 and a GOP structure IBBPBB (bit stream order, with temporal_reference=2, 0, 1, 5, 3, 4)
I am surprised, I always thought that:
- a closed GOP (closed_gop=1) should have 2 I/P frames before the B-Frames, and that the I-Frame should have a temporal_reference = 0.
- an open GOP (closed_gop=0) can have a GOP structure IBBPBB (the 2 first B-frames would be calculated from the last P-frame in the previous GOP)

Could someone say where I am wrong? Is the encoder right in its closed_gop value? what would be the reference frames for the 2 first B-Frames?

Thanks!

[hank315]

That is possible, the first 2 B-frames are only predicted from the I-frame so in fact they are actually P-frames.
This means the GOP is closed, no motion info is needed from the previous GOP, a cut can be made at the I-frame.

[bigotti5]

only predicted from the I-frame so in fact they are actually P-frames.
No... P-frames are forward referenced only.
...A Predictive-coded (P) picture is a picture which is coded using motion compensated prediction from a past I-Picture or P-Picture...

A Bidirectionally predictive-coded (B) picture is a picture which is coded using motion compensated prediction from a past and/or future I-Picture or P-Picture...

...However, in general, in display order, there may be B-Pictures preceding the first I-Picture in the group of pictures, even for the first group of pictures to be decoded.


ISO 11172

This picture order is common for hardware encoders and has confused dvd2avi, dvddecrypter and early dgindex versions to determine a (wrong) -67/80 ms delay for NTSC/PAL.

[Zenitram]

Thanks hank315 and bigotti5, I have my answer!
They are not P-frames because they are displayed before the I-frame, but they are calculated only from one frame (the I-frame), this makes more sense now.

This picture order is common for hardware encoders and has confused dvd2avi, dvddecrypter and early dgindex versions to determine a (wrong) -67/80 ms delay for NTSC/PAL.

My tool too in a development snapshot correcting another bug :( (this B-frame bug in my tool was hidden by anotehr bug, funny that bug+bug=right value), I calculate delay too, so I am correcting it.

[hank315]

This picture order is common for hardware encoders...True, AFAIK no software encoder will do that, it's also not recommended, it hurts compression.