MC encoder and I-frames

ScottW wrote on 9/20/2006, 8:39 AM
Just a quick "beware" for folks using the new V7 feature with having I-frames set at markers from Vegas.

After I lot of research into a different problem, I've found that the MC encoder is not always frame accurate when placing the I-frames, and DVDA seems to match up with Vegas, but doesn't really know the truth, since it appears to be only taking it's cues from the marker info exported from Vegas and isn't confirming it against the actual MPEG data).

Anyway, I had a project that I put the timecode on the video showing frame numbers, with a marker at frame 663. GSpot was claiming that the I-frame was actually on frame 665, DVDA said the marker (chapter 7 in this case) was on 663 (and even showed me a preview showing frame 663).

However, when I authored this with DVDA and examined the result with PGCedit, asking it to display the frame at Chapter 7, the resulting image was frame 665, just as GSpot had been claiming was the location of the nearest I-frame.

This didn't just happen once in the project, but a total of 3 times in 8 chapters where things were off by 1 or 2 frames.

This wouldn't be noticed probably if you had a few frames around the area that were similar.

<edit>

Further testing suggests that this may be influenced by whether open or closed GOPs are specified on the template. If you don't force the encoder to close all GOPs, then it only closes the GOPs where a marker was placed in Vegas (if you indicated that you wanted an I-frame placed for the marker). If you force the encoder to close all the GOPs, then the I-frame placement accuracy goes down.

--Scott

Comments

ScottW wrote on 9/21/2006, 8:02 AM
Ok, retraction time. The MC encoder does appear to be placing accurate I-frames.

So for those that might stumble across this. There are 2 values related to a frame to be concerned with, the coded order and the presentation order. Coded order is the location that the frame actually appears in the datastream. The order of the frame in the data stream is not related to the actual order that the frame is presented for viewing, that's handled by the presentation order.

So, for example, we may have a data stream that looks like IBB in coded order, but the actual presentation order is BBI.

Anyway, the rule with chapter marks is that they must fall on an I-frame, and that the I-frame in question be the first GOP in the VOBU. The contents of the I-frame don't matter, just that the chapter mark falls on an I-frame.

So, I place a marker at frame 47 in Vegas, this gets an I-frame a coded position of 47 in the MPEG file, but, the I-frame may have a presentation value of 49, and a B frame at coded order of 48 has a presentation of 47.

So, when the decoder picks things up, the chapter starts on an I-frame as required, but as the I-frame has a presentation value of 49 it's not the frame that's shown. It's the B-frame with the presentation value of 47 that follows the I-frame which gets shown.

Now, you can get lucky and have your I-frame coded order and presentation order be the same, but there's no requirement for that to be the case.

So, why would anyone care about this? Well, other authoring programs (such as DVD Lab Pro) may display things a little differently such that it causes confusion. For example, a chapter mark on the DLP timeline shows the coded order of the frame, but the preview display gives you a representation of the presentation order and this can be confusing.

--Scott
ForumAdmin wrote on 9/21/2006, 12:14 PM
Your initial post has inspired a knowledge base article to be written.

http://www.custcenter.com/cgi-bin/sonypictures.cfg/php/enduser/std_adp.php?p_faqid=2340&p_created=1158861067

Thanks,
DaveS