MPEG-2 GOP Anomaly

[jdobbs]

Just wondering if anyone else has run into this... In DVD-RB development I have a routine that reads a source MPEG-2 stream (VOB file from DVD) and records information about it. In my routine I am using the Temporal offset value as an index into an array (for a GOP) so I can deal with frames in temporal order.

I recently got a bug report and upon investigating I found that the original DVD has this sequence as the last GOP in a cell

IBBP

not unusual... but when I look at the temporal values they are:

I = 2
B = 0
B = 1
P = 5 <---???

The temporal value of the last entry threw me... the number 5 is what I'd expect if there were two more B frames afer the P... but they don't exist.

Is this something that happens often? Am I confused about what is a legal temporal value?

Any help would be appreciated. I'm guessing it is just bad editing on the original... but I want to make sure I'm not out there somewhere.

[fccHandler]

I think you are correct, and the 5 should be a 3. But perhaps the first GOP of the cell which follows this one contains the two B-frames which are missing from that cell? (I.e., neither GOP is closed.)

Maybe it would be easier not to rely on those values, and instead bubble-sort the frames into display order based solely on the picture coding type.

[Guest]

Originally posted by fccHandler
Maybe it would be easier not to rely on those values, and instead bubble-sort the frames into display order based solely on the picture coding type. That's always the best approach! After all, the MPEG2 specification itself defines display re-ordering based on the picture types without reference to the temporal order field.

[mpucoder]

My first response was that is normal for a closed GOP, but then I read the part about frames 3 and 4 not being there. That's not Kosher, and whatever is in the next GOP does not matter, temporal sequence numbers are within each GOP. So you have a gap in the numbering, that must disturb a few decoders.
Were any frames removed via a cutter, or is this straight from a commercial DVD? I wonder, then what encoder created it (and it wasn't TMPGEnc, as its closed GOPs have no initial B pictures)

And, yes, neuron2 is correct, you can deduce the order by the types

[jdobbs]

Originally posted by mpucoder
My first response was that is normal for a closed GOP, but then I read the part about frames 3 and 4 not being there. That's not Kosher, and whatever is in the next GOP does not matter, temporal sequence numbers are within each GOP. So you have a gap in the numbering, that must disturb a few decoders.
Were any frames removed via a cutter, or is this straight from a commercial DVD? I wonder, then what encoder created it (and it wasn't TMPGEnc, as its closed GOPs have no initial B pictures) It was straight from a commercial DVD, in fact if anyone wants to check it out, it's from Pirates of the Caribbean, NTSC, R1, VTS_07, VOBID 8, CELLID 1.. It's a preview for "Freaky Friday" -- I'm pretty sure it was just a bad cut... it was the last frame in the cell -- there were definitely no more frames after...

ADDED: I guess my biggest mistake was making the assumption a commercial DVD was "pristine"

[Guest]

Originally posted by mpucoder
And, yes, neuron2 is correct, you can deduce the order by the types For the record, fccHandler pointed it out first. I just qualified his "maybe".

[fccHandler]

Originally posted by mpucoder
temporal sequence numbers are within each GOP.
I was about to argue with you because the specs don't really say that, but after I examined the situation further, it turns out that your statement is 100% correct! It seems there can't exist a scenario in which jdobb's P-frame would be number 5 in display order, because the next GOP must begin with an I-frame (by definition). This forces the P-frame to be the last displayed frame of the previous GOP, regardless of whether the GOPs are open or closed.

So yes, it definitely ain't Kosher. ;)

[jdobbs]

Thanks all. I appreciate it.

[fu2k]

Sorry if I'm coming in late. Here's a snippit from the FairUse changelog for version 0.30:

"Changed the video decoder to ignore the MPEG2 temporal reference field; this field can sometimes be wrong ..."

I found the same as you: some (commercial) DVDs seem to have "unclean" cuts/transitions, mostly at chapter changes or at the end of the video. So for correct decoding, you must ignore the temporal reference, and use the picture coding type to determine the display order.

[fccHandler]

FWIW, here's the bubble-sort I used in VirtualDub-MPEG2 (in pseudo-C):

for (x = 1; x < numframes; x++) {
if (frame[x] is a B-frame) {
swap frame[x] and frame[x-1];
}
}

It's that simple. :cool: