Philips VCD Toolkit and chapter

[smc327]

Anyone using Philips VCD Toolkit! The chaptermarks kind of work but don't always end up where I want them to go. The discrepancy is usually no more than a second but occasionally it's as much as seven or eight minutes e.g. I place a chapter mark at 40 minutes it ends up at 46 minutes and 20 seconds. If the chapter mark is moved to 41 minutes in the authoring, it still ends up at 46 minutes and 20 seconds on the disk. Does anyone know what I'm doing wrong!

[Simon_Haddad]

I have been using toolkit for months now, and have had the same problem as you. I have since found the cause.

The problem is that toolkit (as if you haven't noticed) is very particular, and has to have it's own way, such as the *.mmd specifically multiplexed MPEG files. In this case it's the chaptermarks that are causing trouble.

The solution:

First off, start the build process for the album as usual. You'll notice (for more than half the chaptermarks) a bunch of these:

[warning] 
took picture at 00:15:05:22 for chapter mark 00:15:05:18

You'll have to exchange your well-thought-out chaptermarks for toolkit's snapshots, and alter the rest of your project (sequence play time, etc.) to accomodate them. If you do this, then your DVD player (or whatever) will skip to the exact frame you specify every single time. Now, if these chaptermarks are too far off for your liking, you can do one of two things (both of which suck):

Either:
a)Move the chaptermark to an earlier point in time in the MPEG.

Disadvantage: You'll have to build the album yet again (and possibly again and again) to find the correct chaptermark.

Or:

b)Forget it.

If the MPEG doesn't vary much from frame to frame, toolkit may not be able to find a suitable snapshot near your chaptermark. A perfect example would be the closing credits of most movies: a black screen with white credits scrolling upwards. In one of my projects, the snapshot ended up eight minutes after the chaptermark because I wanted to skip to the beginning of the closing credits after a very dark final scene. Oh, well, who sticks around for the credits anyway?

So, after you build your album and get no chaptermark warnings you're in the clear.

Glad I could help.

[vitualis]

Or try creating chapters with VCDImager... I've never had any trouble getting my entrypoints to within a fraction of a second (generally < 1/4 away) and if I encoded my MPEG with specific frames as chapters in mind, I get frame perfect chapters...

For more info:
http://www.geocities.com/medinotes/vcd/chapters.html
http://www.vcdimager.org/guides/chapters.html (mirror)

Regards.

[RFontenot]

The problem of chaptermarks being off the mark isn't a Toolkit problem, it's a problem with the MPEG file. So using VCDImager won't solve the problem. In fact, you'll have the same problem, with a slightly different error message.

While chaptermarks are in SMPTE timecode format, you can only enter the MPEG stream at an actual entrypoint.

[warning]
took picture at 00:15:05:22 for chapter mark 00:15:05:18

The above warning message is merely telling you there is no entrypoint at 00:15:05:18, the nearest one is at 00:15:05:22, and it's going to use that instead.

Generally, there should be no more than a few tenths of a second difference between a chaptermark and an actual entrypoint. More than that means something is wrong with the MPEG file.

vitualis has written some good stuff on chaptering with entrypoints. Read the info at the links he has provided. In there you'll find that in order for entrypoints to work, you must have a valid MPEG sequence header at the entrypoint.

When you request a chaptermark, Toolkit looks for the nearest entrypoint with a valid sequence header. It will search all the way through the MPEG file until it finds one. If the chaptermark is off by several seconds, or worse, several minutes, it's because the sequence headers aren't where they need to be.

vitualis describes a fix for this, which requires demuxing the MPEG file and running the video stream through MPEG Sequence Maker v0.2. Remux the file using either VCDMUX or bbMPEG. (Don't use TMPGEnc to remux if you are using Toolkit.)

If you are using TMPGEnc to encode, you should configure the GOP structure as he recommends.

If you want to know exactly what entrypoint timecodes Toolkit will try to use, there is a tool called Entrypoint Assist, which you can download from here:

http://www.icdia.org/cdprosupport/ftp/pc/pc.htm#epassist.zip

To see ALL available entrypoints, set the "Seconds between Entrypoints" to 0. I only use the logfile. Look in the logfile and you'll see all of the possible entrypoints in SMPTE timecode format. This tool doesn't check to see if the sequence header is valid at a given entrypoint, so if Toolkit can't use an entrypoint listed in the logfile, it's because sequence header is invalid. In that case, use MPEG Sequence Maker to fix the headers up.

RF

[mzidanic]

Just wondering if I got this straight. If one encodes with tmpgenc using the standard GOP structure (IBBPBBPBBPBBPBBP) and set the sequence header output interval to 1, then that's one sequence header every 16 frames or every half second. So at most your desired chapter entry point can be off by 8 frames or 1/4 second.

This is slightly off-topic, but where can I get an explanation of what I, B, and P frames are, and for that matter, a detailed description of mpg-1 format?

[RFontenot]

The GOP structure represents the maximum, not absolute number of IPB frames. Also, when encoding at 30fps (or 29.97fps to be exact), a half second is 15 frames.

For MPEG-1 29.97fps NTSC, the GOP structure should be 1 I-frame, 4 P-frames, and 2 B-Frames, which permits a maximum of 15 frames in a GOP. If you want the flexability to enter the MPEG stream at any point, include 1 sequence header for each GOP.

Every GOP always starts with an I-frame. If you select "Detect scene change", a new I-frame will be created for every scene change, improving picture quality. As a result, the number of frames in a GOP may vary.

I-frames are complete pictures and contain no references to other frames. P and B frames reference other frames and are smaller in size than I-frames. B frames are the smallest.

I recommend searching the web for more information about MPEG encoding.

RF

[RFontenot]

In short, the length of a GOP varies, but should be no more than a half second in length. As a result, the distance between sequence headers will vary.

As for an entry point not being where you want it, you can only enter the MPEG stream at an entry point with a valid sequence header. You can't "be off" something if you could never "be there" in the first place.

If you have a need to be able to select any specific frame as an entrypoint, then try encoding using I-frames only, which will give you a GOP of 1, and create a new sequence header for each GOP.

Not very efficient, but it may give you what you want.

RF

[vitualis]

The problem of chaptermarks being off the mark isn't a Toolkit problem, it's a problem with the MPEG file. So using VCDImager won't solve the problem. In fact, you'll have the same problem, with a slightly different error message.

Perhaps, but VCD Toolkit seems to have a much bigger problem finding valid entrypoints compared to VCDImager, even if every GOP already has an MPEG sequence header in front of it... which is why I suggested trying VCDImager.

For MPEG-1 29.97fps NTSC, the GOP structure should be 1 I-frame, 4 P-frames, and 2 B-Frames, which permits a maximum of 15 frames in a GOP. If you want the flexability to enter the MPEG stream at any point, include 1 sequence header for each GOP.

This is already the default NTSC "VCD" setting in TMPGEnc so shouldn't be an issue...

Every GOP always starts with an I-frame. If you select "Detect scene change", a new I-frame will be created for every scene change, improving picture quality. As a result, the number of frames in a GOP may vary.

This isn't particularly relevant (my reply) to the original problem but "Detect scene change" with a new I-frame can also WORSEN video quality as well -- especially if the encoder starts putting in too many I-frames inappropriately starving the overall bitrate.

Regards.