[VCDImager Bugs/Devel] Re: tracks.svd & stuff... (fwd)

[Herbert Valerio Riedel]

...another bunch of info...

---------- Forwarded message ----------
Date: Thu, 21 Sep 2000 17:56:54 -0500
From: Jens B. Jorgensen
To: Herbert Valerio Riedel
Subject: Re: tracks.svd & stuff...

Herbert Valerio Riedel wrote:
> On Thu, 21 Sep 2000, Jens B. Jorgensen wrote:
> > Actually, the mandatory files are:
>
> > SVCD\INFO.SVD
> > SVCD\ENTRIES.SVD
> > SVCD\SEARCH.DAT
> > SVCD\TRACKS.SVD
>
> > Actually it says the SEARCH.DAT file is mandatory only if the System Profile
> > Tag in INFO.SVD is 0x00 (which corresponds to the System Identification 
> > being
> > "SUPERVCD"), otherwise it's optional. INFO.SVD must be at 00:04:00,
> > ENTRIES.SVD at 00:04:01, LOT.SVD at 00:04:02 - 00:04:33, PSD.SVD at 00:04:34
> > with a variable length of up to 256 sectors.
> ...just to have it explicit :-)
>
> 1.) ext/scandata.dat _is_ optional? (I'm just confused, cause there's some
> philips technical 'explaination' of the SVCD standard from philips, which
> isn't that clear on this issue...)

Yeah, basically if the System Profile Tag is 0 then SEARCH.DAT is mandatory and 
if
the System Profile Tag is 1 then EXT/SCANDATA.DAT is mandatory. This makes sense
(as much as is possible under the circumstances) since both files basically do 
the
same thing--map real-time indexes into sectors on the disc. This probably 
resolved
an issue between competing proposals for the standard. Probably both of the
proponents had existing investments in silicon/design-time they didn't want to 
burn
up by losing their version of this resource.

> 2.) the access point sector addresses file 'svcd/search.dat' and the
> tracks.svd has no sector position requirement?? I'm just wondering, since
> that would mean, that a SVCD player would have to inteprete the ISO
> filestructure in order to locate those files... just for that 2 files...

Nope, the standard doesn't specify a fixed location. Perhaps they figured this
feature wouldn't be implemented in low-end boxes? This data doesn't necessarily
need to be used to jump forward second-by-second anyway since that data can be
embedded into the MPEG stream in the USER DATA.

> > As to the format of these files I'm emailing you separately (so they don't
> > get screwed up!) a cvs diff of changes to vcd_files_private.h containing
> > structures and information about these files. If all is to your liking you
> > can patch your copy and commit it. The analyzing the mpeg streams part is
> > going to be a bit icky I think also. 8( Ah well, we must press on.
> btw, have you found any pointers on mpeg(2) format info? the only info
> I've found so far (not that I've done an exhaustive search on that topic
> but...) are just a few tools for analyzing and demultiplexing mpeg1
> streams... that's where I got that little bit of information for
> vcd_mpeg.? from...

Well, I've got two different copies of source. There's the UC Berkeley stuff and
then the stuff from Heroine Virtual (http://heroine.linuxave.net/). Of course 
this
is just source but I imagine it'll help. In case I didn't mention it before I
looked up the price of the MPEG standard (well the main part anyway) and it's
180CHF! Greedy bastards! I'm loathe to drop the cash for that one if I can avoid
it.

> anyway, I'm off to bed... /me's got quite tired...

Ok, checkout my changes. I'm making a real effort follow your coding conventions
and style. Just point out something I'm not doing right if you see something.

--
Jens B. Jorgensen