Re: Ogg encapsulation

"Gerard Juyn" <gjuyn-qWit8jRvyhVmR6Xm/[email protected]> Thu, 1 Apr 2004 17:51:03 +0200
Newsgroups gmane.comp.graphics.mng.general
Organization Triple-T
Message-ID <406C5687.9728.3339DDA8@localhost>
> >> 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....

Gerard


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