Re: Ogg encapsulation

Ralph,

> Is there any plumbing in libmng that could be exposed to let us hand in
> chunks with the header already parsed? Limitations of libmng's api
> design are a poor decision criteria for our spec, but the overhead of
> the two fields is so small it's almost an aesthetic decision. I'd like
> not to include them, but practical simplicity has weight too and I've
> argued myself to an impasse. :-)

What you're also implying is that you'd rather push the data into libmng, rather 
than have libmng pull it thru the callbacks. This is the same discussion I had 
with Alex about the Mozilla integration where the same problem applied. 
However he decided on a solution within his glue-code.

Changing libmng to be able to accept arbitrary data would be a fairly big 
undertaking. Eg. it would need to do more internal buffering of the data before 
processing it. The advantage however would be that  I/we could add two API 
calls. One to allow streaming data in arbitrary packets, the other to allow data 
neatly chopped up into MNG chunks. And of course the latter would have 
additional parameters for the length and a boolean to indicate if the chunk 
contains a CRC or not (eg. already checked by the stream-reader). That last 
one would make your life a lot easier I reckon...

But, like I said, it's a rather big undertaking. One that needs some major 
planning on my side. So if you're impatient, the alternative would be to add a 
simple API function to set an internal flag whether or not to expect the CRC as 
part of the data. It would still need the 4-byte length in the data-stream, as 
that's the way the libmng-reader functions at the moment, but we'd get 
around the double re-calculation of the CRC and save a lot of cpu. This is one 
I could add within the next few days, as it seems I'm doing odd bits and 
pieces on this aging lib as it is....

How's that sound?


Gerard


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