Re: Ogg encapsulation

"Gerard Juyn" <gjuyn-qWit8jRvyhVmR6Xm/[email protected]> Fri, 2 Apr 2004 09:08:22 +0200
Newsgroups gmane.comp.graphics.mng.general
Organization Triple-T
Message-ID <406D2D86.6607.36816CC8@localhost>
> I notice no one's commented directly on whether OggMNG *should* omit the
> length and CRC field on encoding. :) Sounds like a "don't check" flag in
> libmng is generally useful in either case.

You obviously have a special use for MNG, where it is cut to pieces inside a 
larger whole, so the rules don't really apply anyway. We're just helping you 
figure out how to utilize a tool that does expect things as a whole.
 
> Can libmng be relied upon to ask for the length field atomically? From
> my point of view as a user, if I have to insert a length field between
> chunks, it's as easy to insert a (dummy) crc field. 

Yes. It will first pull the signature, and then do as I wrote earlier. Always 4 
bytes to determine a chunk's total length, and then everything of that chunk 
(including the crc currently). This will repeat until it has encountered the IEND 
chunk in a PNG/JNG or the MEND chunk in a MNG. It may check for extranous 
data after the closing chunk, but I'm not sure (off the top of my head).

However the process could be interrupted if you're running in "suspension" 
mode, which means the library will return to your app when your readdata() 
callback indicates there currently isn't enough data to fulfill the request by 
libmng. Once resumed on the basis that there is enough data, libmng will 
simply request the same size again.

Gerard


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