On Sat, 1 Jul 2006 11:56:34 +0200 Christian Bodenstedt <[EMAIL PROTECTED]> wrote:
[...] > > For uncompressed frame, we have length == size, but for encoded frame > > (passed around between demultiplexor and decoder and between encoder > > and multiplexor), it will be length <= size, so length matters here > > and here it's supposed to be useful ;) > Thanks for taking care about this and for pointing it out. However I > wonder if "length <= size" is a safe assumption for encoded frames. Can we > be sure that also lossless codecs will always produce encoded frames that > are smaller than the decoded input frames? Well, I don't know how all codecs out there behave, but from theoritical point of view AFAIK the one we're talking about (len <= size) it's a sane assertion. In the worst(est) case, an encoded frame can be bigger than uncompressed one by the size of a small header that's supposed to carry, as well as codec-dependent informations, a 'payload-not-compressed' flag. We can take LZO codec (already present in our codebase) as sample. Pratically speaking, I think we can stay safe catching those corner case by allocating an 'extra landing zone' space in private framebuffer used into decoder and encoder (intended as transcode modules). At moment of writing, transcode just allocates frames of insane size (respectively SIZE_RGB_FRAME for video and SIZE_PCM_FRAME for audio) and don't mind about the situation we're talking about. I think that's highly subobtimal. Works (by luck, mostly), but is a useless waste of memory. Since I'm going to rewrite frame allocation code, and marginally framebuffer handling code, I'll take care of changing this doing like I've wrote above. Of course, more comments are just welcome ;) > > This concept was also explained with other words in a comment on > > CVS in src/framebuffer.h. Just let me know if neither explanation is > > clear enough (!!). > Both explanations look well understandable to me. Fine, I hope they are also understandable for everyone else interested. =) best regards, -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact : (email first, Antispam default deny!) icq://27-83-87-867 known bugs : http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)
