[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl

[Reimar Döffinger]

On Wed, Apr 15, 2009 at 04:21:01PM +0200, Michael Niedermayer wrote:
> On Wed, Apr 15, 2009 at 03:50:56PM +0200, Reimar D?ffinger wrote:
> > On Wed, Apr 15, 2009 at 03:26:28PM +0200, Michael Niedermayer wrote:
> > > On Wed, Apr 15, 2009 at 02:40:43PM +0200, Reimar D?ffinger wrote:
> > > > If you had a look at the CDXL demuxer I think the issue is similar:
> > > > you have a header which contains the size of video and palette packets
> > > > and some other information the decoder needs anyway. You can either
> > > > manually write the information the decoder needs into a manually
> > > > allocated AVPacket, hoping someone will notice the missing integer
> > > > overflow check, or you just read the header via av_get_packet,
> > > > extract the sizes, and use av_append_packet to have a full video
> > > > packet with all the info necessary.
> > > 
> > > realloc() is not free, it needs time and i dont like doing 1 realloc
> > > call per packet if it can be avoided.
> > 
> > We are talking about packets that will often be 4 - 32 bytes before, it
> > may not be free, but AV_WL32 or whatever isn't free either.
> 
> And what is the relative speedof AV_WL32() and realloc(4) ?

It depends? :-) But seriously, it's not like I don't see your point,
I was thinking about e.g. adding functions that would just build the
packet data into a buffer created via e.g. av_fast_realloc, but then
you'd still need extra code to track the right value for e.g. pkt->pos, and
you'd still need a function that creates a AVPacket from a buffer
and in the end went with "forget it, those formats were for 286 and 386 PCs
making this convenient to use _is_ more important than speed".
I know you are more reluctant to just ignore the speed implications
which was another reason to think a bit longer about it, but so far
those functions still seem like the best speed vs. usability compromise
for those low complexity, "fringe" formats.