bug-vcdimager
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VCDImager Bugs/Devel] Svcd : DIVIDO perfect !!!!! (fwd)


From: Jorgensen, Jens
Subject: Re: [VCDImager Bugs/Devel] Svcd : DIVIDO perfect !!!!! (fwd)
Date: Mon, 22 Jan 2001 10:28:12 -0600

"Jorgensen, Jens" wrote:

> Herbert Valerio Riedel wrote:
>
> > welcome back! :-)
> >
> > On Sat, 20 Jan 2001, Andrew Stevens wrote:
> > > On Friday 05 January 2001 18:23, you wrote:
> > >> ....just wanted to let you know....
> > > Hi Herbert,
> >
> > > O.k. next stage for mpeg2enc is to produce SVCD streams.  What is the 
> > > state
> > > of play with vcdimager.   Does it suffice to generate a plain SVCD 
> > > compliant
> > > MPEG-2 program stream (I have the parameters I need from the guy who 
> > > offered
> > > to look stuff up).   Or do you also need a file with indexing information?
> >
> > no indexing information required...
> > ...just valid mpeg streams with the usual 2324 byte blocksize :-)
> >
> > ...btw, (vcdimager doesn't need/use it yet, but the svcd standard may
> > require it), there ought to be scan/indexing information in mpeg "user
> > data" blocks...
>
> As Herbert suggests, SVCD's use User Data blocks in the MPEG2 stream to 
> implement "trick play" features, i.e. jumping forwards and backwords. I don't 
> have the standard in front of me at the moment but basically a User Data 
> block is included at the end of each I frame indicating the sector offsets of 
> some incremental points in time (don't remeber exact amount in seconds, one 
> is 5 seconds) of I frames forwards and backwards in time. These blocks are 
> not mandatory.

I'm looking at the standard now and actually the User Data with offset info 
actually is mandatory. The structure starts with the tag 0x10, then the 
one-byte length of 14, then 4 3-byte BCD encoded mm:ss:ff offsets, so it's like:

typedef struct {
  uint8_t type;
  uint8_t len;
  uint8_t prev_i[3];
  uint8_t next_i[3];
  uint8_t backwards[3];
  uint8_t forwards[3];
} scan_info;

These offsets are from the beginning of the track as noted in the TOC. 
Additionally the 2nd and 3rd bytes of these offsets both have to have the 
high-bit 0x80 set. The prev_i and next_i offsets point to the first sector of 
the previous and next I-frames. If there isn't one then the offset must be 
0xffffff. The backwards offset points to the sector containing the start of an 
I-frame 5-10 seconds ago. If there isn't such a fram then it points to the 
sector containing the first I-frame. The forwards offset likewise points to the 
sector containing the start of an I-frame 5-10 seconds forward. If there isn't 
one then it points to the last I-frame of the track.

--
Jens B. Jorgensen
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]