Re: Ogg encapsulation

> If you want the full wish, we'd like to have libmng parse directly out
> of sparse buffer chains. This way we can do 'zerocopy' reads from
> whatever transport the data stream is using. We're going with this
> approach for the video-related Ogg implementation because the expense of
> copying around even compressed video is quite significant.
> 
> So not just push put complicated push. :) I have been thinking about
> writing something like this for VLC streams though.

Ah. So not really pushing the data but supplying pointers to where the actual 
data may be. This may actually not be such a big change, and could 
significantly improve the libmng reader. If they are really chunks, because 
right now libmng is keeping internal track of chunks (the playback-cache). So 
instead of creating them internally it would use your pointers. Unfortunately 
libmng is storing them in decoded style, so it would need some logic to re-
decode on playback, but perhaps not. Let me think about that one...

> Speaking of, I have an innocent question. Is there any way to write
> uncompressed IDAT chunks? If not, what's the fastest mode of encoding
> png data? There's a niche for a lossless video file format, and Ogg MNG
> + FLAC (our lossless audio codec) seems like it could fit the bill. I do
> understand that zlib is very fast on modern 2 GHz machines, but in live
> recording it's nice to be able to minimize overhead if necessary.

At the moment libmng doesn't compress the IDAT's for you. Eg. you have to 
supply it with the compressed data. I'm sure there are ways to tell zlib to do 
minimal compression or to bypass it completely while maintaining compatibility 
with the zlib-decoder on the display side. Others (Cosmin?) may give much 
better feedback in that area!

G


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