VCD Toolkit Problem.....seriously need help here...

[wildcatfan]

OK, I am authoring a VCD and when I build the project I get this error:


Start generation of VCD av sequence track AVSEQ01.DAT;1
Start generation of VCD av sequence track AVSEQ02.DAT;1
Start generation of VCD av sequence track AVSEQ03.DAT;1
[warning]
took picture at 00:08:16:00 for chapter mark 00:07:59:22

[warning]
took picture at 00:40:52:05 for chapter mark 00:20:34:00

[warning]
took picture at 00:53:49:03 for chapter mark 00:53:49:00


So I checked the disc and sure enough, the chapter are put in the wrong place (well 2 and 3 are) and so my question is does anyone know what would cause this problem. I encoded in Tmpgenc 12a and the file DOES have sequence headers every GOP. I even ran MpegSequence maker over it to make sure. Is this a bug in this version of Tmpg? Also I had detect scene changes selected could this cause the problem? Also for the experts what files contain the data for controlling the entrypoints on a VCD? Appreciate any help guys, I need it.

[branch]

I think you and I are the only ones trying to use that program. Which is a pity since it was the orignal from the people who invented the standard.

Unfortunately I haven't been able to get nero to burn the images produced by the program. Perhaps their latest update will do that (though I'm not optimistic about those guys )

[wildcatfan]

Oh I can get Nero to burn the images. You need tocsplit 1.2 and choose either the 1st or 3rd option. the 2nd (cue and bin) doesn't work right. download tocsplit 1.2 from the cdi website and read the readme file. cue and bin is said to work with the newest nero but option 1 is the fastest anyways.

[RFontenot]

I believe the SCANDATA.DAT is the file with the entrypoint data.

The VCD2TK help guide's description of chaptermarks:

"Chaptermarks define named entrypoints in MPEG streams to which a user may jump while viewing the encoded video
segment. Because MPEG encoding compresses the video, an individual video frame may not contain enough data to
display a complete picture. Chaptermarks contain all the data required to display a complete picture at a specified
timecode and, therefore, are valid assets that can be associated with Toolkit events."


The location of a chaptermark is defined by a SMPTE timecode, which points to a specific frame. That frame can be an I, P, or B frame. Usually only I-frames contain a complete picture. P and B frames require data from other frames to create a complete picture. So a chaptermark that points to a B-frame requires information from I,P, and possibly other B-frames to produce a complete picture, whereas a chaptermark that points to an I-frame would have all the information it needs to produce a picture.

A Group Of Pictures or GOP is a sequence of I,P,and B frames. I believe the standard GOP configuration for VCD is 1 I-frame, 4 P-frames, and 2 B-frames. This configuration gives you the following 15 frame sequence:

IBBPBBPBBPBBPBB

The I-frame is the anchor frame for the next 14 frames of the sequence. When you select "Detect Scene Changes", you are basically telling TMPGEnc to create a new I-frame and start a new sequence whenever there is a scene change, such as when the camera switches from one actor to another.

A sequence header gives the decoder all the info it needs to initialize itself so it decodes following frames properly. An End of Sequence code tells the decoder when the sequence has ended.

VCD2TK is a very unforgiving authoring program and demands strict compliance with White Book specs. The fact that your chaptermarks are off by so much indicates there is a problem with the internal structure of your file. This could include the sequence header and/or the GOP structure. Maybe not enough to make a difference when playing back through most MPEG players, but enough to piss off VCD2TK.

Some things you may want to try:

1. Use a later version of TMPGEnc. I don't remember for sure, but I think the earlier versions had some problems with sequence headers.

2. Use a GOP sequence of 1 I-frame, 4 P-frames, and 2 B-frames. Use an output interval of 1 sequence header per GOP.

3. Turn off "Detect Scene Change"

Good luck.

[KoalaBear]

Actually, a chapter point in MPEG-1 is defined as a sequence header followed by a GOP header followed by a closed GOP.

I believe the way Wildcatfan was compiling them (correct me if I'm wrong) is to make a stream of closed GOPs and later insert sequence headers in front of all of them.

While this will work, you're at the mercy of wherever the encoder happens to insert an I-frame. An MPEG encoder can and will abandon a GOP in progress and construct a new GOP wherever it can gain an advantage by doing so (a scene boundary for example is "cheaper" to construct by inserting a fresh I-frame than by representing the difference with several Ps and Bs), and the length of each GOP will vary for similar reasons.

So if your desired chapter point falls in the middle of a GOP, the authoring program will compile the address of the next available I-frame (53:49:03 instead of 53:49:00), which may not be the frame that you want.

The way to fix this is to force an I-frame wherever you plan to have your entry point. A good encoder will compile a legal chapter mark (<seq hdr> <gop hdr> <closed GOP>) at that address, meaning you don't have to close all your GOPs or insert additional sequence headers afterwards. But unless you tell the encoder exactly which frames must be I-frames, you'll have to take whatever it gives you.

[vitualis]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-12-07 03:11:55, wildcatfan wrote:
took picture at 00:08:16:00 for chapter mark 00:07:59:22

[warning]
took picture at 00:40:52:05 for chapter mark 00:20:34:00

[warning]
took picture at 00:53:49:03 for chapter mark 00:53:49:00


So I checked the disc and sure enough, the chapter are put in the wrong place (well 2 and 3 are) and so my question is does anyone know what would cause this problem.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I personally don't use VCD Toolkit, but that second entrypoint seems to be WAY off. Is this actually the case?

As for the solution to your problem, if you've encoded with TMPGEnc, there is probably little you can do (in a compliant way) short of re-encoding your MPEG. You could try using VCDImager +/- APS relaxed setting.

If you use TMPGEnc, I believe that you can use it to set pre-determined frames as I-frames so you can get frame accurate entrypoints. Even if you don't use this, you can still encode your MPEG in such a way so that there is a potential entrypoint every 0.5 second or so... i.e., a set entrypoint should be within a 0.25 of a second of the target one. This is usually unnoticable. With TMPGEnc, set it to close all GOPs. Although there is a theorectical loss of quality with this setting, the end result looks fine to me.

As for the "detect scene change" setting, I don't think that that is the cause of your problems. Of course, you could try turning it off to see what happens.

Regards.

[wildcatfan]

Ah maybe I didn't make myself clear. See the problem isn't that it doesn't have sequence headers, cuz it does. At least mpegsequencemaker said it did. See i ran it through that proggy and it would always say at every gop sequence header found nothing to do. That is why I am stumped.

[KoalaBear]

Wildcatfan, friend, what part of this are you not getting? Several knowledgeable people have stepped in to help you. Throw us a bone here.

What it all boils down to is that in order for VCDTK to reference a chapter mark, there has to be one at the place you told it to look. It's as simple as that.

But there are at least two ways to compile chapter marks depending on how precisely you need to access them later: you can make every GOP a potential entry point, or you can insert entry points only where you want them to be.

There are pros and cons to each method, some of them arcane in the extreme, but the principal difference is that the first method (every GOP) is accurate to the second, and the second method (select GOPs) is accurate to the frame.

In either case, in order for a chapter mark to be accessible, it has to be properly constructed with respect to MPEG-1 syntax. That means a sequence header followed by a GOP header followed by a closed GOP. This is the rule, and there are no exceptions.

In the "every GOP" system, you encode your MPEG as a stream of closed GOPs ('output bitstream for editing' is the way TMPGenc refers to this function, I think). The GOP header is required by MPEG-1 syntax so you don't have to do anything to put them there -- they get inserted prior to every GOP by design. All that remains is to insert sequence headers ahead of those, which is what MPEG Sequence Maker takes care of.

If you do this, you'll be able to access the closest entry point to any time code that you enter. Because you can't predict exactly where those entry points will be in advance, you'll be a bit off (plus or minus 1 GOP) but that's usually close enough.

In the "select GOP" system, you choose the frames you want to become entry points in advance. You tell the MPEG encoder to compile a chapter mark ('forced I-frame' is usually the way it's described) on the frames that you want to access later, and the MPEG encoder inserts a closed GOP at that location at least, or a proper chapter mark at best. Behavior varies from encoder to encoder but in the worst case all you'll need to do is insert the sequence header afterward.

If you do this, you'll be able to access those very frame(s) just by entering their timecode. If you can't, it's because your timecode (hh:mms:ff) itself is off.

Now, if you follow one of these protocols, or even both -- there's no reason you can't mix the two together, you will be able to access entry points with a greater or lesser degree of precision as you see fit -- they will work.

We know that they will work because we use the same techniques ourselves. If they don't work for you, you need to start from scratch and encode a new MPEG because you can't fix the problem afterwards.

Try it again based on these instructions and see what results you get.

[wildcatfan]

ah well, see kinda the question I was getting around to then was is this a flaw in Tmpgenc? I have tried so many GOP settings it isn't funny. and I KNOW that the stream has sequence headers, so I was wondering what ELSE could cause the problem of the toolkit not finding the chaptermarks. BTW Videopack4 didn't complain about em.

[RFontenot]

Just because you have sequence headers doesn't mean they are formatted exactly as required per the White Book spec.

Most of the freeware, and many of the commercial VCD tools do not strictly follow the White Book spec. VCD2TK, on the other hand, demands strict White Book compliance.

What tool are you using to multplex your audio and video files?

[disturbed1]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
Also I had detect scene changes selected could this cause the problem?
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

That's your problem. Detect scene change will force a new I frame (GOP sequence) where/when ever TMPG thinks it's needed.

Your GOP should be ~.5 fps. 29.97=15, 25/23.976=12. IBBPBB.....

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
I have tried so many GOP settings it isn't funny.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

NTSC I=1, B=2, P=4.
Film/PAL I=1, B=2, P=3.
Those are the only GOP sequences considered to be correct.

And yes, early versions of TMPG are flawed in every aspect. Haven't bothered to use any of the newer versions.

I use PWI, then Mpeg Sequence maker, and get entrypoints +/- 1 second every time.

[wildcatfan]

First of all, thanks guys for the responses....as to RF's question...I was encoding in tmpgenc, demuxing then reencoding the audio (to get around the read past end of file thing in vcdmux). Then I tried muxing with vcdmux and bbmpeg both gave the same problem however.

[RFontenot]

wildcat,

Get the latest version of TMPGEnc and configure GOP according to distrubed1's specs.

I've run into problems with TMPGEnc's MPEG-1 VCD multiplexing. Here are two encoding methods that work for me:

A. Encode using Video Only, then Audio Only, then multiplex the two streams with VCDMUX.

B. If you want to encode using System(Video+Audio), (which makes it easier to use Source Range), modify the VideoCD template as follows:

1. Start a new project
2. Load the VideoCD template
3. Unlock the template and change the stream type to MPEG-1 System (automatic). DO NOT USE the VideoCD stream type!
4. Modify the GOP settings and save the template so you can use it again.
5. Encode your initial MPEG-1 .mpg files.
6. Use MPEG Tools to demux each file.
7. Use VCDMUX to mux new .mmd files
8. If you get a "Read Past End of File" error from VCDMUX, go back to TMPGEnc and use the Merge/Cut tool to create a new .mpg file with the last second cut off from the initial .mpg file. (The cut tool seems to do a better job of properly closing the streams than the encoder.) Demux the new .mpg file and remux with VCDMUX.

Try building your project with chaptermarks without running the .mmd file through MPEGSequencer. If the .mmd file is in good shape, you shouldn't need to.

I use both TMPGEnc 12i and ATI Radeon AIW for encoding my initial MPEG-1 files. I've never used bbmpeg, so I don't know if it could be contributing to the problem.

You may also want to go to:

http://www.icdia.org/cdprosupport/ftp/pc/pc.htm

Download an install the EPASSIST.ZIP program. This tool will examine your .mmd file and extract all of the entrypoints. I would recommend setting the interval to something like 10 seconds and enable only the log file. Review the log file and make sure there are no huge gaps in the intervals. (If you set the interval at 0, it will log every single entrypoint.)

The bottom line is that to miss an entrypoint by 20+ minutes, there must be something screwed up with the internal structure. Hopefully we can figure out what the cause is.