Why have some DVDs GOPs starting with B-frames?

[LogicDeLuxe]

I wonder why some DVDs have many GOPs starting with B-frames (display order). It seems, I-frames are the obvious choice, so you can start decoding at any GOP, ie. making random access into the video possible. So what is the benefit of not starting a GOP with an I-frame but a B-frame instead?
Which encoders produce such streams anyway?

[SeeMoreDigital]

Which DVD's?

[Ghitulescu]

I also had this situation, and made my day hard in trying to synchronise the audio (which was mixed up during remuxing).

[bigotti5]

I wonder why some DVDs have many GOPs starting with B-frames (display order).
It is as GOPs are defined.
Starting with B-Frames (display order) does not necessarily mean starting B-frames cant be decoded without previous GOP.
The original concept of a group of pictures was a set of pictures that could be coded and displayed independently of any
other group. In the final version of the International Standard this is not always true, and any B-pictures preceding (in
display order) the first I-picture in a group may require the last picture in the previous group in order to be decoded.
Nevertheless encoders can still construct groups of pictures which are independent of one another. One way to do this
is to omit any B-pictures preceding the first I-picture. Another way is to allow such B-pictures, but to code them using
only backward motion compensation.
Staring B-frames gives slightly better compression.
i.e PAL max GOP length in DVD VIDEO == 15

BBIBBPBBPBBPBBP - 10 B-frames
IBPBBPBBPBBPBBP - 9 B-frames

Misinterpreting starting B-frames is the reason for the -67ms (NTSC) and -80ms (PAL) delay myth in decoding DVDs.
Near all hardware encoders does encoding this way.

[LogicDeLuxe]

Which DVD's?The German "Austin Powers 3" is such a title among many others. The authoring of that particular title is interesting, since they used seamless branching for the misreading subtitles joke. One would think that multi-angle would be the obvious choice, but it's not what they did. Maybe there was a reason against closed GOPs.

BBIBBPBBPBBPBBP - 10 B-frames
IBPBBPBBPBBPBBP - 9 B-frames
Only a valid point when you need a closed GOP, I suppose. IBBPBBPBBPBBPBB is also valid in open GOPs, right?

Misinterpreting starting B-frames is the reason for the -67ms (NTSC) and -80ms (PAL) delay myth in decoding DVDs.
Near all hardware encoders does encoding this way.I did't get why Smartripper apparently calculates the delay to the first I-frame instead of just relying on the given PTS. Any reason for that?

[bigotti5]

IBBPBBPBBPBBPBB is also valid in open GOPs, right?
A GOP must not end with a B-frame
Another property of a group of pictures is that it must begin, in display order, with an I or a B-picture, and
must end with an I or a P-picture.
Open GOP B-Frames can only reference to previous GOP, not to subsequent GOPs.

[LogicDeLuxe]

It seems, PTS and DTS in a GOP sector always refer to the I frames. If it refers to the leading b frames instead, my Panasonic is in trouble. Every time, the stream alters between a closed and an open gop, there is a jerk as the player apparently tries to resync the video to the time codes. I had this issue on a test DVD. When I changed the PTS and DTS to take this into account, the issue was gone. Is this the correct way to set PTS and DTS?

This would indeed leads to negative audio delays when audio and a video starting with an open GOP has the same PTS. This is the case on some DVDs, but not always.

I found this article about audio delays: http://www.mpucoder.com/guides/delaymyth.html
It does not tell how DTS and PTS is correctly set, though.

[bigotti5]

Only I frames have PTS and DTS values.
For VOBUs (GOPs) "Vobu Start Presentation Time" in PCI sector of NAV packs should be the point of interest.

[LogicDeLuxe]

For VOBUs (GOPs) "Vobu Start Presentation Time" in PCI sector of NAV packs should be the point of interest.So, should the "Vobu Start Presentation Time" refer to the first displayed frame or to the first i frame?
Same question for the "cell elapsed time". First displayed frame or first i frame?
Should the cell times in the PGC's cell playback information table calculated from the sum of the displayed frames? And the PGC header's playback time the sum of them (middle and last angle cells excluded)?

I have some tests running and still trying to figure out why on my Panasonic, the displayed time freezes sometimes at the beginning of a new VOB ID, and a few seconds later, it plays the start of that VOB ID again, this time with the time running as usual.

[bigotti5]

So, should the "Vobu Start Presentation Time" refer to the first displayed frame or to the first i frame?
First frame displayed
Same question for the "cell elapsed time". First displayed frame or first i frame?
First frame displayed
Should the cell times in the PGC's cell playback information table calculated from the sum of the displayed frames?
yes
And the PGC header's playback time the sum of them
sum using first angle blocks

[LogicDeLuxe]

Thank you very much.
I got all of that now, I think.
The particular freezing issue was caused by a programming error which set some discontinuity flags wrong. I got that sorted now too.

One last thing I have to solve though. If I have very short VOB IDs consisting of only one GOP, which I need to skip in certain PGCs. Obviously, those can't be really interleaved. I just skip those in the PGC, and even most players play them seamlessly, my Panasonic behaves the same as with that discontinuity flag error, eventhough it is set correctly on every new VOB ID now, and cleared on any following cell withing the same VOB ID. My PGCs have always all cells of a VOB ID in order, hence that should be correct, right?

Is it violating the specs to skip VOB IDs seamlessly when they are not interleaved, even when the distance is small enough (which certainly is the case when there is only one GOP)?

Or is the only valid way to solve this issue in cutting the VOB IDs longer? Is there a minimum frame count/GOP count/size/playing time an interleaved VOB ID should have?