Detecting I-frames for entrypoints??

[MarioB79]

<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-06-21 15:28:25, MDK wrote:
Good Day,

Having a bit of difficulty. I am trying to make a SVCD with I-author and as far as I know, please correct me if I am wrong, an entrypoint must fall on an I-frame.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I don't know if it's true, but if you open your mpg with virtualdub it says for each frame the time and the type.
So you can detect the I-frames!

Bye
Mario

[hvr]

btw, entry points should not just fall on I-frames, but to be completely compliant on socalled access point sectors, which are usually made up of sequence header, GOP header and an I-frame...
otherwise your player might not have the necessary resolution information for recovering playback...

[BadAsh]

I have only tried EntryPoints once and VCDImager griped about the fact that most of my EntryPoints were NOT on an I-Frame.

If you really do have to plan your EntryPoints around an I-Frame shouldn't VCDImager use I-Frames for defining EntryPoints instead of seconds.

And while we are on the subject... why oh why did VCDImager decide to base EntryPoints on seconds whereas 99.9% of all players and encodes use minutes and seconds and even CUE Sheets require track listings in terms of minutes and seconds. It would be so much easier if you didn't have to figure up the total seconds from a minuteseconds point.

[digvid]

I wish that you could specify entry points in VCDImager as frame numbers. That would make it really easy to identify precise entry points that you have specified to be GOP I-frames in TMPGEnc or CinemaCraft.

- digvid

[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-07-26 06:53:28, BadAsh wrote:
I have only tried EntryPoints once and VCDImager griped about the fact that most of my EntryPoints were NOT on an I-Frame.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

This should be irrelevant as if you have the mpeg sequence header before each GOP, the furthest away a possible entrypoint should be is a quarter of a second from whatever you put down (I-frame every 15 frames = 1/2 sec). If you are going to be entering in your times at a resolution of seconds, this hardly makes a difference.

<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>If you really do have to plan your EntryPoints around an I-Frame shouldn't VCDImager use I-Frames for defining EntryPoints instead of seconds.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

The point is that you choose the time, and VCDImager chooses the CLOSEST possible entrypoint (which should be within 1/4 of a second). Entering entrypoints as "time" is probably a lot more user friendly than naming it as an I-frame.

<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>And while we are on the subject... why oh why did VCDImager decide to base EntryPoints on seconds whereas 99.9% of all players and encodes use minutes and seconds and even CUE Sheets require track listings in terms of minutes and seconds. It would be so much easier if you didn't have to figure up the total seconds from a minuteseconds point.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Look, converting minec to seconds is pretty easy. If you want this feature, why not send hvr an e-mail on your suggestion rather than whinging on the forum?

Regards.

[hvr]

btw, I don't know whether this makes will help or not,
but I've created a new tool for the 0.7.8 version to come out, which dumps some generic infos and the APS timestamps (+ pack number), so you can analyze your mpegs... and in order to aid upcoming GUIs to gather some informations about the MPEG streams.... the way vcdimager sees them...

[KoalaBear]

I like VCDImager, but I agree that "seconds" is an inefficient way to access an entry point because 1/4 second accuracy gives you 1/2 second uncertainty, i.e., a 66% probability that the entry point you specified will be missed.

I've read the supplied documentation and Vitualis' XML tutorial. VCDImager apparently supports sub-second time resolution ('30.00') but neither document tells you what fraction the decimal part is in. Tenths of a second? Hundredths? Frames? The answer is relevant to the topic, because if VCDImager is granular to the second +/- 0.25, the chances of reaching the correct chapter point is only 16%.

Wouldn't SMPTE timecode (hh:mms:ff) be a less ambiguous method of referencing these addresses?

<font size=-1>[ This Message was edited by: KoalaBear on 2001-07-26 14:11:27 ]</font>

[hvr]

well....

for those who want to play around with a preview of the 0.7.8 version
(but, this rls apparently fixes a firmware compatibility prob for people with those KISS54/A2 firmwares for SVCDs as well...)
you can go to
ftp://ftp.hvrlab.org/pub/vcdimager/.testing/
and grab the latest one...
it cointains a vcdxminfo.exe (be sure to check the --help for options... otherwise it won't output anything usefull..)

use it this way:

vcdxminfo.exe -v -i -a yourmpegstream.mpg

...then it should output some stuff about your mpeg... btw, try it on some smaller mpegs... maybe redirecting the output is agood thing as well...

btw, vcdimager uses fractional seconds, which have the granularity of the PTS mpeg timestamps (which is far beyond 1/75secs btw

there's just one thing to note, the PTS times get substracted an offset, which corresponds to the lowest seen PTS time in the mpeg stream,
that way the earliest PTS timestamp is set to 0-sec ... the offset used is displayed as DEBUG message (the -v switch enables that debugging output)

....

[Tommy]

So what if you just cap in I frames only.......

[KoalaBear]

Perhaps I'm just having an obtuse moment, but I'm not at all sure I understand what was said.

What people want to know is how to start playback from a properly constructed chapter point (sequence header, closed GOP, I-frame) wherever that happens to occur. Are you saying that the way to do this would be to locate the PTS of the particular frame and use that as the entry point address?

If so, it seems to be a rather Rube Goldberg-ish method of chapter construction.

[vitualis]

KoalaBear,

This is how I locate the places I want a chapter to start...

I load up my software DVD player and press "next" on the DVD playback and note down the time it goes to. I keep doing this until I have all the times for the chapters (I do this because I use the menus screens from the DVD on my VCDs as well).

I convert the time to seconds. Do the relevant offset calculations if I need to use two discs. Use the times as entrypoints on the VCD.

Obviously, I could be off by maybe up to a second doing it this way compared to the original DVD. However, even this makes very little difference to the final product. Finding the exact position of the sequence header + GOP + I frame is irrelevant as all you are achieving is 1/2 second resolution (that's the frequency of possible entrypoints available to you).

For example, say I wanted the chapter to start at exactly a particular frame. There is only a 1 in 15 chance that this frame will lie on a possible entrypoint position. Thus, the best I can hope for is the CLOSEST entrypoint to this position (which will be within 1/4 second). This is why I say it is somewhat irrelevant to be able to define the exact frame or I frame for the entrypoint to start.

In any case, you are not going to notice whether your chapter starts 1/4 second ahead or a 1/4 behind of the desired entrypoint position anyway.

As for the resolution of entry time in the XML, as hvr stated, it is more accurate than 1/75 of a second (which is the smallest achievable in terms of sectors on a CD). For example, you can enter a time as 10.04 = 10 seconds and 1 frame (for PAL).

Regards.

[KoalaBear]

I still don't get it. The "how" isn't so much the blocking point for me; it's the "why."

Your response seems to imply one of two things: either (a) all I-frames do and must occur at 1/2 second intervals, or (b) VCDImager simply isn't frame-accurate when it comes to authoring chapters.

Because (b) I can understand. It's a new tool, it will no doubt improve over time, and this is an opportunity to highlight what can be done to make a good thing even better, while it's still in the development cycle.

But if it's (a), any frame in an MPEG can be an I-frame if you tell the encoder to place one there, and if you precede it with the right sort of header it's supposed to be randomly accessible as well.

It doesn't sound bizarre to you that VCDImager has 1/75th second accuracy or better when it comes to specifying a playback point, but only half a second accuracy when it comes to referencing it? If the chapter access uncertainty exceeds more than a second, one may as well split them into separate tracks since you'd know at least what frame they'd be starting from.

<font size=-1>[ This Message was edited by: KoalaBear on 2001-07-27 22:41:40 ]</font>

[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-07-27 22:33:44, KoalaBear wrote:
I still don't get it. The "how" isn't so much the blocking point for me; it's the "why."

Your response seems to imply one of two things: either (a) all I-frames do and must occur at 1/2 second intervals, or (b) VCDImager simply isn't frame-accurate when it comes to authoring chapters. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

(a) is true. I-frames do and must occur every 15 frames (assuming you are looking at a VCD compliant MPEG-1 stream). As you can only start a chapter on an I-frame (which should also be the beginning of a GOP and have an mpeg sequence header if authored correctly), there isn't any point in being more accurate when entering times.

VCDImager can be frame accurate for entering times. Again, there is no point for this is the frame isn't an I-frame though.

<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>But if it's (a), any frame in an MPEG can be an I-frame if you tell the encoder to place one there, and if you precede it with the right sort of header it's supposed to be randomly accessible as well. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Perhaps. This isn't necessarily VCD compliant though, but it may (probably) will still work.

<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>It doesn't sound bizarre to you that VCDImager has 1/75th second accuracy or better when it comes to specifying a playback point, but only half a second accuracy when it comes to referencing it?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Again, you can ONLY start on an I-frame. This is an issue with MPEG-1, not VCDImager.

<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>If the chapter access uncertainty exceeds more than a second, one may as well split them into separate tracks since you'd know at least what frame they'd be starting from.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Entrypoints allow seamless playback which is the whole point of them. Multi-tracks don't. If frame-accurate starting is more important than seamless playback, you should use multiple tracks.

Regards.

[KoalaBear]

On 2001-07-29 00:10:24, vitualis wrote:
<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>Perhaps. This isn't necessarily VCD compliant though, but it may (probably) will still work.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Of course it will work. Where did you get the idea that in order to be 'VCD compliant' an MPEG file must consist exclusively of GOPs of a particular type and length?

An I-frame is the only frame a valid GOP must contain, as P and B frames are completely optional. You may not have considered the possibility of other GOP structures, but that doesn't make MPEG files which contain them non-compliant.

<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>Again, you can ONLY start on an I-frame. This is an issue with MPEG-1, not VCDImager.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Right. And an I-frame can occur by itself in a closed GOP anywhere within an MPEG-1 file, and not just on half-second boundaries. That's why it's called a "chapter mark."

If the XML entry point syntax isn't accurate enough to describe the location of a properly coded chapter mark, that's an issue with VCDImager and not MPEG-1.

<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>Entrypoints allow seamless playback which is the whole point of them. Multi-tracks don't. If frame-accurate starting is more important than seamless playback, you should use multiple tracks.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

I was being facetious. The point is that you've been defending an obvious limitation of the program as being the only (or at least the 'correct') way to implement this particular feature.


<font size=-1>[ This Message was edited by: KoalaBear on 2001-07-29 03:36:31 ]</font>

[digvid]

Here's how I make entry points exactly where I want them, at least when backing up a DVD:

1) Run ChapterXtractor (from http://www.flexion.org) on the .ifo file from the dvd and set the frames per second to 24. Look on the last tab and note the starting frame numbers of each chapter.

2) If I use TMPGEnc to encode, I go to the GOP tab, turn off automatic scene detection, and manually specify the chapter frames to be GOP I-frames. I also check the box that says to make all GOP's closed. If I use CCE demo to encode, I click the "Special..." button and specify the frame numbers as chapters. This makes them closed GOP's automatically.

3) After encoding I use vcdxgen to build an xml file from the mpeg. Then I calculate a value in seconds for the entry point by taking each frame number and dividing by 23.976 (or whatever the actual playback rate is).

During playback on my Philips DVD-711 player, this gives absolutely perfect accuracy with my chapter points. I have noticed that the accuracy is not perfect when playing on the computer with my Hollywood Plus player, but I suspect that is the Hollywood's fault.

Hope this helps somebody!

- digvid

[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-07-29 03:27:19, KoalaBear wrote:
Of course it will work. Where did you get the idea that in order to be 'VCD compliant' an MPEG file must consist exclusively of GOPs of a particular type and length? </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

There is a big difference to what is allowed for in MPEG-1 generally and what is allowed for in MPEG-1 for a compliant VCD. I am pretty sure that VCD2.0 asks for GOPs of a particular types and length.

<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>An I-frame is the only frame a valid GOP must contain, as P and B frames are completely optional. You may not have considered the possibility of other GOP structures, but that doesn't make MPEG files which contain them non-compliant.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Again the above point. I'm not talking about MPEG-1 in general but what is allowed under White Book.

<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>Right. And an I-frame can occur by itself in a closed GOP anywhere within an MPEG-1 file, and not just on half-second boundaries. That's why it's called a "chapter mark."

If the XML entry point syntax isn't accurate enough to describe the location of a properly coded chapter mark, that's an issue with VCDImager and not MPEG-1.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Please read my above post again carefully. I hate it when I have to repeat myself. VCDImager can describe the location of ANY I-frame in the MPEG-1 if you know where it is. It is the contraints on MPEG-1 in White Book that prevents you from putting them whereever you want. You could of course put them whereever you want and VCDImager will reference them, but you may no longer have a VCD compliant stream.

<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 was being facetious. The point is that you've been defending an obvious limitation of the program as being the only (or at least the 'correct') way to implement this particular feature.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Please read posts carefully before make accusations like this. I agree that having the entrypoints timing as mms:ff is probably easier, but it also gives the illusion of accuracy that doesn't functionally exist. If you used digvid's method, you will get frame accurate entrypoints but at the same time, I am pretty sure that the extra I-frames ARE NOT VCD compliant. However, I doubt that they won't work on most players.

If you still haven't understood my posts by now, let me summarise. VCDImager can reference anything to a frame accurate level. VCD compliant (as in White Book) only have I frames every 15 frames (thus the source of 1/2 second accuracy).

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-07-30 02:21:07 ]</font>

[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-07-29 06:10:14, digvid wrote:
1) Run ChapterXtractor (from www.flexion.org

I had been wondering for a while if such a proggy existed... Thanks for the link!

Regards.

[hvr]

btw, it should be noted, that vcdimager by default restricts the set of I-frames available as APS to those which have sequence/gop/I-frame in the same 2324 byte pack (the specs may even require the sequence header to be the first byte after the pack header... but I don't support this constraint yet... but it may be implemented sometime...)

I said by default since you can relaxed the constraints for APS qualification to just containing the start of the I-frame...

the vcdxminfo tool supports enabling the relaxed mode as well, so you can see how the set of APS changes with relaxed APS constraints...

I may support per-mpeg-item constraint settings in vcdimager some time...

[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>
On 2001-07-30 02:02:24, vitualis wrote:

There is a big difference to what is allowed for in MPEG-1 generally and what is allowed for in MPEG-1 for a compliant VCD. I am pretty sure that VCD2.0 asks for GOPs of a particular types and length.

Regards.

_________________
Michael Tam
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

For NTSC 29.97 the GOP length is 15. (I=1,B=2,P=4)
For Film and PAL the GOP length is 12 (I=1,B=2,P=3).

This is per VCD authoring specs. The GOP must be ~.5 seconds in length.

If you mux with bbMpeg it will put the correct flags on every GOP to allow correct entry points. You can also use Mpeg Sequence maker to do the same.

Following the VCD GOP rules and using bbMpeg, or Mpeg sequence maker allows for frame acurate entry points in both VCD Imager, and the Philips VCD toolkit.


For SVCD the only restriction is a GOP length less than 2 seconds. I-Author's entry points are screwed up, there's a formula to use I copied this from http://www.geocities.com/aussie01au/menu.html
<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>
There are 3 factors to apply in the process:

1) starting from zero with an out point less than the full clip length the applied factor in my tests was 2 so if I desired to come out a 3 minutes I entered 3x60x2=360 seconds as the out point.

2) starting from within the file the factor was 1.045, so my starting point for 3 minutes became 3x60x1.045=188 seconds as the value used in I-Author. Be careful which way you round the value, rounding down will mean a slightly earlier true entry.

3) If your out point for the chapter is before the end of the clip then the factor, for my system was 1.49. So a 5 minute 43 second chapter exit point was defined in I-Author by 343x1.49=513 seconds. Again rounding up will give a slightly longer chapter.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>



<font size=-1>[ This Message was edited by: disturbed1 on 2001-07-30 04:30:31 ]</font>

[KoalaBear]

Vitualis:

Would you mind showing us the white book specification, please? Because it appears to me that whenever somebody points out a weakness in your reasoning, you say things like 'Well, that might work in practice, but it's not really VCD compliant according to white book.'

Variable-length GOPs are fundamental to MPEG compression technology. It is highly unlikely that NV Philips would have imposed fixed-length GOPs as a condition of VCD compliance, because doing so would have an adverse impact on picture quality.

Try this experiment:

Load a few MPEG-1 files ('white book compliant', of course) into VirtualDub and use the keyframe advance button to have a look at the GOP stream. You'll see plenty of variations on the ibbpbbpbbpbbpbb theme, including ibb, ibbpbb and ibbpbbpbbpbb.

The simplest explanation for their presence is that fixed-length GOPs are not a compliance requirement, which in turn means that if VCDImager cannot reference a chapter mark with a precision greater than 1/2 second, strict adherence to VCD specifications is NOT the reason for this.

Thanks for the practical suggestions to those who contributed them.

[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-07-30 08:47:45, KoalaBear wrote:
Variable-length GOPs are fundamental to MPEG compression technology. It is highly unlikely that NV Philips would have imposed fixed-length GOPs as a condition of VCD compliance, because doing so would have an adverse impact on picture quality. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Fixed length GOPs are definitely part of White Book. Stop trying to reason things out from your knowledge base and consult some text on this subject. You are denying a point of fact and there is no point discussing this further.

<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>Load a few MPEG-1 files ('white book compliant', of course) into VirtualDub and use the keyframe advance button to have a look at the GOP stream. You'll see plenty of variations on the ibbpbbpbbpbbpbb theme, including ibb, ibbpbb and ibbpbbpbbpbb. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

This is because your MPEG-1 files aren't white book compliant.

<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>The simplest explanation for their presence is that fixed-length GOPs are not a compliance requirement, which in turn means that if VCDImager cannot reference a chapter mark with a precision greater than 1/2 second, strict adherence to VCD specifications is NOT the reason for this.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

PLEASE READ MY POSTS CAREFULLY BEFORE POSTING THE SAME TIRED ARGUEMENT. THIS IS THE SECOND TIME I'M TELLING YOU THIS. VCDImager can reference any thing to frame accuracy. It can reference EVERY frame if you had an I-frame only MPEG. If you have bothered to get VCDImager and try it out for yourself, you'd understand what I mean.

The issue is that you can't CREATE a compliant MPEG-1 stream with chapter marks whereever you want. However, this is a minor loss of compliance. If you follow digvid's post, he shows you how you CAN create chapterpoints where you want. He obviously also shows you how to use VCDImager to reference those chapterpoints exactly. There is NO issue with VCDImager. Please read ALL the posts before badgering this 1/2 second thing again.

The limitation is the fixed length of the GOP. This is what is required for VCD compliance. I do not presume to understand why Philips decided to impose fixed GOPs but there is an obvious reason. Early CD-i/VCD players could ONLY FFW and RWD a VCD on playback if it had the regular MPEG sequence headers. No sequence headers = no FFW or RWD. MPEG Sequence Headers in the context of VCDs are placed before each GOP. A regular and fixed GOP length helped facilitate this feature.

Obviously, MOST playback devices are much more relaxed about this which is why other MPEG-1 specifications play. If you read the forums, XVCDs using extremely high bitrates, higher framesizes and VBR still play in some devices. This is a good thing. If everything had to be exactly by the book, VCDs would be close to impossible to make with amateur/hobbyist tools.

Regards.

_________________
Michael Tam

<font size=-1>[ This Message was edited by: vitualis on 2001-07-31 03:54:30 ]</font>

[rayjr13]

arguing with Vitualis...appears to be futile

silly rabbits..

[KoalaBear]

Show us the holy White Book, Vitualis.

I'm convinced you have no knowledge of it.

[hvr]

afaik he's gone for a one week trip...

oh, and btw, maybe using (floating point) seconds may not be the perfect timebase, but it is surely the most common one, if you use a simple player which gives you a time index...

having used some other addressing type, like e.g. the pack number, would have been _much_ more easy to accomplish, but it would have been unpractical...

anyway, additional addressing method may be implemented in the future... (but not in the near one...)