Not to obsess on this issue, but can anyone with V7 confirm or deny this problem exists?

I will tomorrow morning; I would have known tonight, but the download is taking forever...... I just purchased the upgrade based partly on this functionality. While it won't be the end of the world if it doesn't work, I will admit dissappointment, especially since I really needed it for a client.

Hopefully it does work.

--Scott

checked this with the templates "PAL DV" and "PAL DV separate streams". I-Frames regularly set at 12 by template. Added two markers at 0:17 and 2:05. Both where indicated in DVDA4. What templates are you using?

I don't yet have V7 so I can't do any investigation myself, but I thought I'd just mention that the latest version of the excellent free tool GSpot now includes a splendid "Visual GOP Structure" viewer which allows you to see what's going on in terms of P,I,B frames, etc, in MPG2 files (and also a lot of other nice things).

It might be useful to have this tool available when you're investigating what is going on with this new feature of V7. You can download it here.

Mark

Thanks Thomas- good to hear it works for someone. I am using the "DVD Architect NTSC Widescreen video stream" template.

Update: I just got it to work on a simple project I started in V7! My problems were from a V6 project that I imported to V7. Could that be it?

Could be. I have crashes using JKL on a particular V6 project. Other V6 projects work well in V7.

There's certainly something going on here. I kept having the flag get cleared on me. I'd set the flag, then change to a different tab and when I went back to the video tab the flag had been cleared. This was on an existing custom profile. Then I cancelled out, selected the DVDA widescreen template and clicked custom - this time the flag was automatically set and nothing I did cleared it (except actually clearing the flag).

Hopefully this will work.

I had the same problem with the flag clearing by itself when I used a custom template. Haven't yet tried a preset template.

I can also confirm that this appears to work, I put about 8 markers in a row, one per frame and using the new GSpot that Mark provided a pointer to, could easily identify the sequence of I-frames that were generated.

--Scott

For what it's worth, I've already made more than a dozen DVDs using v7a. For each I've placed markers on the timeline then rendered to MPEG-2 and the I-frames have been exactly where I wanted them (in turn DVDA is putting chapters in the right spots).

The only proviso is that all my projects are PAL, most 16:9 and a couple 4:3. I've used the DVDA render settings in each case and the process has worked every time.

I've done some more testing, using the very helpful GSpot v2.60 Beta to assist locating the I-frames.

Unfortunately, I spoke too quickly with my earlier report of success. It looks like when converting HDV 1440x1080 60i HDV to MPEG2 (DVD-A NTSC Widescreen video stream profile) the "set I frames at markers" option places some I-frames as requested, but some are 1 frame off and some are 2 frames off. It does always make the GOP shorter (if your marker didn't happen to fall on a natural i-frame anyway) and it does make that GOP closed (GOPs without markers are open GOPs) but it doesn't always hit the I frame exactly. Below are two examples showing the frame number of the marker (first column) and the closest I-frame in the output MPEG in the second column.

Example 1
---------------------------------------------------
marker, I-frame
---------------------------------------------------
0, 0
23, 24
71, 72
115, 117
156, 156
213, 213


Example 2
---------------------------------------------------
Marker, I-frame
---------------------------------------------------
33, 33
34, 34
35, 35
36, 36
37, 37
38, 37
47, 49

-------(edited to format columns more clearly)--------

I've been doing some testing on this, and I don't think you can trust that GSpot is showing you where the I frames really are.

I was also finding that I-Frames appeared to be one or 2 frames off at the end of a run, when looking at the display in GSpot, but DVD Lab Pro claims that the I-Frames are exactly where they are supposed to be.

--Scott

Looks like I'm pretty confused. I generated a small 6-second (179 frame) MPEG2 file (29.97 fps) and looked at the I,P,B frame structure using GSpot 2.6, DVD-Lab Pro 1.6, TECO bitrate viewer 1.5.054, and DVD-A 4.0.

Each of these four programs displayed DIFFERENT frame numberings, for the very same MPEG file ! Interestingly, only DVD-A 4.0 showed (via the small triangles on the timeline when you manually move a chapter point) that the i-frames were indeed present where I had put the chapter marks in V7a.

The other programs all showed them to be off by 1 or 2 frames. It certainly is confusing, but it looks like V7a may be doing the right thing after all, and the other programs are simply incorrect. And/or I don't know what I'm doing at all.

For what it's worth, I've moved from DVD-Lab Pro to DVDA largely because I could never get DVD-Lab to put chapter markers in exactly the right places, it was always off by a few frames.

I don't have any of that bother in DVDA, the I-frames are where Vegas is supposed to have put them and the chapter markers are in exactly the right places when the project is compiled.

Well, I have to agree, DVD Lab certainly seems to be confused about something. However, DVD Lab would have the same issue that previous versions of DVDA did; the difference is that prior versions of DVDA wouldn't snap to the nearest I-Frame (which is what you are supposed to do), while DVD Lab does snap to the nearest I-Frame. So if you don't have an I-Frame exactly on or near your chapter mark, you're going to have problems in either case.

After more testing, I'm beginning to believe that GSpot knows what it's talking about. However, it does look to me like the MC encoder might be placing the I-frame one frame off of where it should be, but I need to do some more testing to confirm or deny this. If this is an off-by-1 issue it would make sense that DVDA and Vegas would work ok together sine they would both be either right or wrong.

--Scott

I have just tried "Insert I frames at markers" and for me it works perfectly. You can get yourself in all kinds of trouble looking at GOPs with Bitrate... For example the Vegas MC Mpeg encoder in Vegas 6 created two B frames ahead of the first I frame on the first GOP. It is perfectly legal, and verifiied by Sony tech support, but it throws the frame count off in GOP "analyzers'. I have not checked the mpeg encoder in V7 yet. Here is what I have done to verify Vegas is inserting the I frames correctly. I created an AVI file with a unque number shown on each frame so I can visually identify a specific frame. In Vegas I inserted a marker at a specific frame making sure the markers were spaced at a distance greater that 1 second between markers. If the markers are less that one second Vegas will not flag the error but it violates the DVD spec and you will get bizarre results. Next, I rendered the meg2. When I built the chapter file in DVDA4, the frame numbers shown in the thumbnails were exactly the frame numbers I picked as th ebeginning of chapters. I burned and played the DVD on my Sony stand alone player. When I selected a chapter I immediately hit pause on the remote and the DVD paused at the beginning of the chapter on the with the correct frame numberdisplayed and the time at 0. I also checked the location of the I frames using ProEx tools in DVDLab Pro. I trust this set of tools because it was the only set of tools that displayed the extra B frames in V7 closed GOPs. The I frames, chapter points and frame numbers displayed matched exactly. IMO It works perfectly. When you insert your chapter markers make sure they are greater than 1 second apart.

Ed Baldwin

In my latest test, V7a chapters work 100%. I tested with 7 chapters, and put "flash frames" with a single line of bold text just one frame long at each chapter mark, and contrasting "before-mark" text on 30 frames right before the chapter marks. Created the project with DVD-A 4, burned the DVD-R disc and played it on my Pioneer DV-343 player. I skipped to each chapter mark and all were exactly right, no "before" text showed, just the 1-frame flash at the chapter itself, so in hardware playback, all chapters were precisely correct. My WinDVD software player seemed to cut in late during playback when skipping to a chapter, but maybe it's just my PC is too slow.

As a check, the frame number and SMPTE drop-frame timecode of each chapter reported by V7a agreed exactly with the readout from the final VTS_01_1.VOB in PGCEdit (exported Celltimes.txt).

When I used the same MPEG file to make a DVD in DVD-Lab Pro 2.1, importing frame-indexed chapter marks, building the DVD and then reading out the chapters in PGCEdit, the first chapter was 2 frames early and the last was 1 frame early. The other chapters matched. Hardware playback of this DVD confirms the first & last chapters are early. Which is odd; it seems either DVD-Lab secretly re-encoded my MPEG, or it is violating the spec saying chapter points must be on I-frames.

I also noticed you can't get chapters closer than 1 second apart, or very close to (1 second?) the very last frame, but I think that's a DVD format limitation, not DVD-A per se.

it seems either DVD-Lab secretly re-encoded my MPEG, or it is violating the spec saying chapter points must be on I-frames.

Actually, chapter marks must be on I-frames, otherwise the DVD player wouldn't know how to display the picture if you jumped into the middle of the GOP, since all of the B/P frames are based on that initial I-frame.

I learned something else that I didn't know; the authiring software also has the responsibility of gathering up GOPs into a VOBU - VOBU's can have multiple GOPs and there are rules about how long/short a GOP can be. In addition, a chapter mark can only be on the first I-frame of the VOBU.

So in the case of DVD Lab, if it puts the short GOP that the encoder created especially for the chapter mark at the end of a VOBU, then the chapter mark can only go at the I-frame in the beginning of the next VOBU - hence you could end up being one frame off.

--Scott

The problem (as I see it) is Vegas 7 does not post an error during encoding for chapter markers set closer than one second (as infrequently as they occur except in test cases). When you import the mpeg file into DVDA 4 you will find the Chapter points and I frames were moved during compile. DVDA 4 does not detect any error but the chapter points and I frames and not the ones you selected. IMO Vegas 7 should have posted an error and not moved the chapter points and I frames.

Ed B

I thought I had DVDs figured out but the VOBU issue was news to me. I guess that explains why DVD Lab is getting some chapters misplaced, but I'm not sure why DVDLab and Sony DVD-A are arranging VOBU's differently in the first place. Do they just group the GOPs into VOBUs randomly? Is DVD-A using some secret "hints" from the Vegas 7 file to arrange the VOBU's into the right place for the chapter starts to work?

Ed, I think there's a reason that the MC encoder puts those 2 B frames first (that is first in presentation order), and it doesn't seem to be a mistake. If you take a look with GSpot and put it in bitstream order, you'll see that the I-frame actually is first in the bitstream as it is read.

This actually may make sense - a B frame is a predictive frame, but a B-frame cannot be decoded without an I-Frame, so in the datastream, the first frame is the I-Frame, but the first frame(s) displayed are the 2 B-frames.

I'm still seeing the MC encoder place things one frame off on occasion.

--Scott

Do they just group the GOPs into VOBUs randomly?

No, I dont think so. As this is a standard, you can bet there are rules. For example, a VOBU:

1. Cannot be shorter than .4 seconds
2. Cannot be longer than 1 second
3. may contain one or more GOPs
4. a typical VOBU contains a single GOP of 15 frames or .5 seconds

(no doubt there are other rules).

So, in the case where the MC encoder inserts a chapter mark, it appears to be inserting a GOP of type IBB at a minimum (it depends on where the chapter mark falls, because I've seen a number of variations in my experimenting). This is too short to be in a VOBU by itself, so DVDA would need to take this and either append it to VOBU(n) or prepend it to VOBU(n+1) while staying within the rules of VOBU length.

So for DVDA, the critical thing would be that these really short GOPs always appear at the beginning of a VOBU (bacause of the rule that a chapter mark must be at the first I-frame of the VOBU).

--Scott