I have checked with ProEx and with GSpot. Both seem to be in agreement about I-frame location.

DVDA will accept any location for a chapter point marker. When DVDA builds the DVD, DVDA will pick the nearest I frame to the chapter marker. If the MC encoder fails to put the I frame at the marker, DVDA will move chapter point to the nearest I frame. This is the way DVDA is supposed to work.

In my test, I exported markers with the media and also asked the MC encoder to put an I-frame at each marker. According to GSpot the MC encoder put the I-frame at 665, not 663 as I had asked. When I pulled the mpeg file into DVDA, it loaded the markers that were exported and showed a chapter mark at 663. DVDA did not move the chapter mark on the timeline to the I-frame position at 665 (which admittedly would be new functionality), however, when the DVD was compiled, the chapter did end up on 665 (which is what I expected to happen). If DVDA had no intention of setting the chapter point on 663, then it should have moved the chapter to the correct location for display purposes. It did not. Hence my statement that DVDA lies - if the authoring software can't show you what you're actually going to end up with, then I consider that a problem, especially when things are billed as frame accurate, when in fact they are near-frame accurate.

Here's my comparison chart for marker frame, DLP position, ProEx position, ProEx markers exported to DLP and GSpot presentation location and coded location:

http://www.allthingsparker.com/images/test1.jpg

Here's what DVDA says about things with Chapter 7 selected:

http://www.allthingsparker.com/images/test1a.jpg

And lastly, here's what PGCedit says about chapter 7:

http://www.allthingsparker.com/images/test3.jpg

This should be fairly easy to reproduce. I just took a 30 second clip, dropped some random markers on it and rendered it out asking for I-frames at marker position (elementary stream). Out of the 8 chapters, 4 of them were actually off by one or 2 frames.

--Scott

"DVDA did not move the chapter mark on the timeline to the I-frame position at 665, however, when the DVD was compiled, the chapter did end up on 665 (which is what I expected to happen). If DVDA had no intention of setting the chapter point on 663, then it should have moved the chapter to the correct location for display purposes. It did not. Hence my statement that DVDA lies - if the authoring software can't show you what you're actually going to end up with, then I consider that a problem."

DVDA does not move the Marker on the timeline. DVDA never has update the time chapter markers on the time line. When DVDA builds the DVD, DVDA places the chapter point at the nearest acceptable I frame. In your example you requested a chapter point at 663 but DVD found the nearest one at 665. If you used this same mpeg file with DVDA3 it would also place the chapter points on the same I frames. Building the correct mpeg is the key.

I did create a 60 second clip and put 8 chapter points ar random ( correct spacing) wiht chapter 7 at 663 in the avi. When I placed the DVD on my Sonys all capter pints were exactly on ie correct unique frame number on TV and correct chapter number and time count at 0. I will go back and try sveral other cases. Did you ever check the chapter points on a DVD player?

Ed

My eyes are unable to detect being 2 frames off on a DVD player; hence the reason I used PGCedit to view the chapter start point.

DVDA places the chapter point at the nearest acceptable I frame.

Really, I don't have a problem with this, but one of the new features with V7 is supposed to be frame accurate chapter points, and I'm not finding that to the the case. They are near-frame accurate.

I did create a 60 second clip and put 8 chapter points ar random ( correct spacing) wiht chapter 7 at 663 in the avi. When I placed the DVD on my Sonys all capter pints were exactly on ie correct unique frame

Unless you placed the exact same sequence before that, then you're not going to reproduce what I'm seeing at 663. You need to place a Vegas marker at:

47, 190, 307, 456, 629, 663

You should see the MC encoder being off at 47, 456 and 663.

<edit>
Ok, there'[s some factor in the template used that's influencing this. I've been using a custom template to output elementary streams - in my most recent test, 6 out of 7 markers were off by 1-3 frames. Using the DVDA NTSC template resulted in only 1 out of 7 being off, and then only by one frame.

The custom template I'm using is based on the DVDA NTSC template, but changed to elementary and 8000 cbr, so it's likely just the difference between program vs. elementary - I'll try changing the custom template back to program and see what happens.

--Scott

"My eyes are unable to detect being 2 frames off on a DVD player; hence the reason I used PGCedit to view the chapter start point."

That is why I created an AVI like a start countdown. Starting at frame 1 with a 1 size 360 in the middle of the frame, then 2..... all the way up to 1000. When I test I select the chapter and immediatley hit pause. My Sony's pause at the beginninng of the chapter. With the Sony DVP-S360 I can single step frame by frame back and forth through the chapter point and you can watch the chapter decrement or increment as you step 1 frame thru the chapter point. There is no missing anything.

I just created an avi that was 1008 frames in length. I put chapter markers at frames 47, 190, 307, 456, 629, 663, and 841. I mpeg encoded with DVDA NTSC Video stream template. Added the mpeg to the menu in DVDA4 and created the chapter menu. All markers were as listed correctly. I burned the DVD and checked each chapter point, several times, by jumping to each chapter and immediately hitting pause and then stepping frame by frame back and forth through the chapter point. In each and every case the chapter points were dead on.

Ed

<edit>

I just reran the same test with the DVDA NTSC Video stream with a CBR of 8000. Also elementary stream. All of the chapter points were dead on.

What does GSpot say about the I-frame placement?

I don't have GSpot. When Vegas 3 was released I discovered the closed GOP was "unconventional" , the first GOP had 2 B frames before the I frame (coded order) BBI. Spec wise the stream was correct but many of the GOP software analysis programs did not know how to deal with the leading B frames and flagged as an error or threw them away. The DVD players had not problem playing the streams. To me, these leading B frames, is what causes the frame counts appear to be in error.

I don't question what you are seeing, I do question the validity of the what the tools are reporting. The construction of the mpeg stream may be throwing them off. IMO

Ed

How about PGCedit? If you launch it, double click on the title and then click on the arrows on the right side of the window for each cell/chapter, does the initial frame displayed for the chapter match what you expect?

I've got basically 3 different tools telling me the same thing, which is that the I-frames are not always being placed where I asked for them. I'm trying to figure out if all 3 of the tools are wrong.

Unfortunately, my DVD player does not pause at the beginning of the chapter (when going directly to to the chapter) and in fact, using the previous chapter button it sometimes picks up a few frames before the start of the chapter.

<edit>

The latest GSpot is aware of that BBI coded sequence at the beginning and as it's doing just a dump of the frames, I don't know why its calculations # would be off. I can visually count and see that the first mark I asked for at frame 47 has the I-frame at 46.

--Scott

"How about PGCedit? If you launch it, double click on the title and then click on the arrows on the right side of the window for each cell/chapter, does the initial frame displayed for the chapter match what you expect?"

No, they are not what I expected. The same with ProEx. If those particular GOPs are closed the coded order could start with a B frame. If these tools are reverse enginneered it could account for the problem.

You mention GSpot is aware of BBI at the beginning but remember that was a close GOP stream. When you insert I frames for chapters you wil find both open and closed GOPs and the BBI could be introduced at the beginning of each closed GOP .

Try this. Setup everything as before but set GOPs to closed in mpeg template.

<edit>
"The latest GSpot is aware of that BBI coded sequence at the beginning and as it's doing just a dump of the frames, I don't know why its calculations # would be off. I can visually count and see that the first mark I asked for at frame 47 has the I-frame at 46.

Is this coded or presentation order?



Ed

Closed GOPs were specified on the template for my elementary stream mpegs, however, I just realized that for the DVDA template streams where the I-frame accuracy improved, that the GOPs weren't closed. I changed that DVDA template to have closed GOPs and now according to GSpot, the I-frame placement isn't as accurate with closed GOPs as it is with Open GOPs specified on the template.

When you insert I frames for chapters you wil find both open and closed GOPs and the BBI could be introduced at the beginning of each closed GOP

I'm seeing the mix of open and closed GOPs when I don't have "Closed GOP" set on the template; the closed GOPs only happen on an I-frame that matches the marker in Vegas (well, except for 2 of them that are off). However, I'm not seeing any BBI sequences on any of the GOPs except the very first GOP.

<edit>
Is this coded or presentation order?

Presentation. Coded order shows IBB - which makes sense to me since you can't decode a B-frame without an I-frame.

--Scott

I am out of gas. :) When you get some time I suggest you take the burned DVD and play it on a DVD player that you can pause and step and see what you find.

Ed

I created a DVD with DVDA3 using the same mpeg with I frames at chapter markers as I used in the tests with V& & DVDA4. The chapter frames on the scene selection menu were not pointing to the correct frame and when I burned the DVD, the chapter points were not frame accurate. Surprise, DVDA4 was doing 'some additional processing'. This may account for the chapter point problems encountered with DLP.

Ed

On a different aspect to this.
I had assumed / hoped that this new feature would have another use. Being able to force an I frame at a specific point can improve the quality of the resultant encoding. If it turns out that the encoder is not exactly following instructions and instead DVDA is making more tweaks to achieve the result then that idea seems lost.

Bob.

DVDA isn't touching anything. The main issue I'm seeing is that the MC encoder isn't reliably placing the I-frame at markers indicated in Vegas. It is placing an I-frame though, just not always exactly on the frame that I indicated.

--Scott

I checked the accuracy of the Vegas 7/DVDA4 chapter points this time using Windows Media Player and my test video (numbered frames) mentioned above. By selecting pause button (lower left corner) when the scene selection menu is displayed and then selecting the chapter, widows media player will pause on the first frame of the chapter. I checked each chapter and all the chapter points were correct. I did not see any chapter points located on the errant I frame locations reported by GSpot, PCGEdit,...

Ed

Thanks for not giving up on me Ed. I just checked one project authored with DLP via WMP this way and didn't see anything that invalidates my previous results with GSpot, etc. However, a second project authored with DVDA seems to support what you are seeing.

Unfortunately, I don't know any longer if these 2 projects were based on the same source material; so tomorrow I'm going to go at it with the same source and see what I can find.

--Scott

The feature is designed by give you frame accurate chapter stops on a DVD video disc played in a set-top DVD player (hardware).

Is anybody on finding that this is not working?

re: inspecting GOPs and I-frames in software...we'll post an FAQ about that soon.

All the DVDs I have created with Vegas 7 & DVDA4 have frame accurate chapter stops.

The 'problem' discussed in this thread arises when a user tries to use the 'frame accurate chapter stops' mpeg file created by V7 in another authoring program (DVDLab Pro) and finds that some of the chapter points (all on I frames) but are not accurate. Further analysis of the 'frame accurate chapter stops' mpeg with GStop, PGCEdit, ... all show that some the frame acccurate chapter stops are not accurate.

Ed B

ECB, I have an occassional need for a numbered Generated Media veg similar to the one you mentioned for your testing. Did you make your test file in Vegas? Could you post a veg? Did you use a script? Thanks, John.

Ok, my brain hurts. But I think I understand why I was confused.

When comparing the VOB files produced by DVDA with DLP using the same source mpg...

Coded order seems to be the important factor, not presentation. Markers in VMS get placed as I-frames in the MPEG stream in coded order, not presentation.

In my test, there is an I-frame at coded/presentation: 45/46 and 47/49. My Vegas marker was for frame 47. So, when DVDA builds the VOBU(4) the VOBU starts with coded I-frame 47 (which has a presentation value of 49). This satisfies the requirement that the chapter mark must be on an I-frame, and that it also be the first GOP in the VOBU. The actual contents of the I-frame don't matter, because the frames will be displayed in their presentation order. In the GOP in question, there's a B frame coded at 48 with a presentation of 47 - it's this B frame that when reconstructed has the correct frame to display.

--Scott

My results show: if you render MPEG2 from Vegas via MainConcept and author in DVD-A 4, all chapters are frame-accurate on a hardware player. So I can't point the finger at Sony. If you author the same project in DVD-Lab, some chapters are misplaced by a few frames, I'd love to know why and haven't yet figured it out. It's as if the authoring tool can freely choose between using presentation order and coded order when counting frames, assembling VOBUs and placing chapters, and DVD-Lab does it the opposite way as DVD-A? That seems unlikely but don't see how else it can be explained.

By the way: If you use Avisynth (free: www.avisynth.org ) you can generate a frame-numbered video with the script below. I put multiple colored versions of the frame numbers in, just for fun. I don't know how to use an AVS file directly in Vegas, so I opened the AVS file in VirtualDub, www.virtualdub.org and saved it as a DV AVI, and then opened that in Vegas.
Edit: ok, you can open an AVS in Vegas using a tool called VFAPI plus read_avs.dll which works but it's sort of kludgy. http://forum.videohelp.com/viewtopic.php?t=87270

---- clip below this line and save text file as frames.avs -------------------------

# AVS 2.56 script to create 720x480 video of frame number & timecode
# by J.Beale Sept.18 2006

# create Black clip, framerate 29.97, with a silent audio track
BlankClip(length=12000, width=720, height=480, fps = 30000, fps_denominator = 1001, color=$000000, audio_rate=48000)

ShowFrameNumber(scroll=true, offset=0, size=50, text_color=$10a010)
ShowFrameNumber(scroll=false, x=10,y=50, size=50, text_color=$c01010)
ShowFrameNumber(scroll=false, x=10,y=150, size=50, text_color=$a03060)
ShowFrameNumber(scroll=false, x=10,y=250, size=50, text_color=$804090)
ShowFrameNumber(scroll=false, x=10,y=350, size=50, text_color=$809070)
ShowFrameNumber(scroll=false, x=10,y=450, size=50, text_color=$40a010)
ShowSMPTE(offset="00:00:00:00", x=360, y=250, size=60, text_color=$d0d030)

Subtitle("SMPTE Drop-Frame", x=190, y=150, size=40, text_color=$2260e0)

J Mac, if you make your email address active in your profile I will email you the veg.

Ed

It's as if the authoring tool can freely choose between using presentation order and coded order when counting frames, assembling VOBUs and placing chapters

I don't think that's the case. This is more of a restriction in DLP that DVDA doesn't have.

Chapter marks must fall on I-frames, and the I-frame must be in the first GOP of a VOBU, agreed?

DLP is applying these rules via its GUI to the presentation order, when in fact they only apply to the coded order.

Here's an example. I have a Vegas project with a marker on frame 46, when I render this, the MC encoder places an I-frame on frame 46 (coded order), however, that I-frame does not contain the video contents of frame 46 from Vegas's perspective, instead it contains the video from frame 48 (presentation order), and that's fine.

In the following, the convention is frame-type/presentation, so what we have in coded order is:

I/48 B/46 B/47

When the decoder has re-arranged these into presentation order, we have:

B/46 B/47 I/48

This is where the engineers for DVDA were pretty clever - they realized that while the chapter mark had to be associated with the I-frame, the initial presentation frame of that chapter did not.

DLP doesn't appear to have made this leap and insists that the initial presentation frame of the chapter must be the I-frame. Period. As a result, when I import my markers into DLP, it picks the I-frame at 45 (coded), which in my test case also was the presentation number, so my preview display really showed frame 45. If I move the chapter mark manually to the next I-frame, which is 46 coded, the preview display shows presentation frame 48.

At least that's what I think is going on. I've been known to be wrong.

--Scott