Re: Ogg encapsulation

Gerard Juyn wrote:
> 
> > >> Note that leaving them in allows the new code to read old
> > >> spec-compliant PNGs, too, only faster.
> > >
> > >An "old spec" didn't include crc then? Otherwise how would
> > >spec-compliant and invalid CRC exactly rhyme???
> >
> > "leaving them in"
> >
> > new code reads a dummy CRC where the file has an actual one.
> >
> > As opposed to "leaving them out"
> >
> > new code reads nothing and is 4 bytes out of sync when it tries to
> > read the next chunk's length bytes.
> 
> If I understand Ralph's description correctly, the OGG stream doesn't contain
> MNG chunks in the normal sense. When it's ready to pass data to libmng it's
> got a field containing the length and a pointer to the chunk data without the
> crc. So to accomodate libmng it would still need to supply the 4-byte length
> first, but can then pass the data-pointer without prepending it with a dummy
> crc. libmng is always requesting 4 bytes first and then request a chunks
> length of data including the crc. If there's a flag to say the stream doesn't hold
> crc's it would just request 4 bytes less, which would be exactly the size of
> the OGG buffer, hence no extra fiddling required to resize buffers and stuff....

OK. But to be generally useful we ought to set up two flags (or a 3-way
int)
then; one that says ignore the CRC and another that says there's no
CRC.  It's
a little more (but not very) complex for libmng to avoid adding and
subtracting 4 bytes to/from the expected length a couple of places.

--
Send the message body "help" to [email protected]