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

[Michael Niedermayer]

On Thu, Nov 18, 2010 at 10:18:08PM +0100, Reimar D?ffinger wrote:
> I'll try once more to fix the palette issues...
> 
> On Wed, Apr 15, 2009 at 08:47:24PM +0200, Michael Niedermayer wrote:
> > On Wed, Apr 15, 2009 at 05:29:14PM +0200, Reimar D?ffinger wrote:
> > > On Wed, Apr 15, 2009 at 04:17:24PM +0200, Michael Niedermayer wrote:
> > > > On Sun, Apr 12, 2009 at 01:26:33PM +0200, Reimar D?ffinger wrote:
> > > > > +int av_grow_packet(AVPacket *pkt, int grow_by)
> > > > > +{
> > > > > +    void *new_ptr;
> > > > 
> > > > > +    if (!grow_by)
> > > > > +        return 0;
> > > > 
> > > > for what is that good for?
> > > 
> > > Avoiding a pointless realloc in case someone does something stupid like
> > > av_grow_packet(pkt, 0);
> > 
> > people should not do such stupid things
> > 
> > 
> > > 
> > > > > +    if (pkt->size + FF_INPUT_BUFFER_PADDING_SIZE > INT_MAX - grow_by)
> > > > > +        return -1;
> > > > 
> > > > could you write this in a way that is free of overflows please ;)
> > > 
> > > Hm. Bad "documentation", I hadn't decided what grow_by < 0 is supposed to
> > > mean or if I should just make it unsigned (the latter I admit would not
> > > help here).
> > > So
> > 
> > > > if (grow_by < 0 || pkt->size + FF_INPUT_BUFFER_PADDING_SIZE > INT_MAX - grow_by)
> > > good enough?
> > > I also assumed that pkt->size + FF_INPUT_BUFFER_PADDING_SIZE would not
> > > overflow since the allocated buffer must already be that big, if you
> > > dislike that.
> > 
> > maybe
> > 
> >    (unsigned)grow_by > INT_MAX - FF_INPUT_BUFFER_PADDING_SIZE 
> > || pkt->size > INT_MAX - FF_INPUT_BUFFER_PADDING_SIZE - grow_by 
> > 
> > ?
> > 
> > > > > Index: libavformat/utils.c
> > > > > ===================================================================
> > > > > --- libavformat/utils.c	(revision 18467)
> > > > > +++ libavformat/utils.c	(working copy)
> > > > > @@ -277,6 +277,20 @@
> > > > >      return ret;
> > > > >  }
> > > > >  
> > > > > +int av_append_packet(ByteIOContext *s, AVPacket *pkt, int size)
> > > > > +{
> > > > > +    int ret;
> > > > > +    int old_size;
> > > > > +    if (!pkt->size)
> > > > > +        return av_get_packet(s, pkt, size);
> > > > > +    old_size = pkt->size;
> > > > > +    ret = av_grow_packet(pkt, size);
> > > > 
> > > > isnt av_grow_packet already checking for pkt->size==0 ?
> > > 
> > > Yes, but it only allocates a new packet then. av_get_packet also sets
> > > pkt->pos. Sure, maybe a bit overkill for a single assignment, just
> > > thought it might be more future-proof.
> > 
> > well, fine leave that then
> 
> One more try...

is it intended to change the table to dynmically generated in this patch?
is the code even smaller than the 256 bytes?


>  libavcodec/avcodec.h   |    8 +++
>  libavcodec/avpacket.c  |   20 +++++++-
>  libavcodec/xan.c       |  117 ++++++++++++++++++++++++++++++++++++++++++++---
>  libavformat/avformat.h |   11 ++++
>  libavformat/utils.c    |   14 +++++
>  libavformat/wc3movie.c |  120 +++++++------------------------------------------
>  6 files changed, 180 insertions(+), 110 deletions(-)
> 9a9e24da63ec55a4343383c70e733205f50f2f9c  wc3_pal.diff
> Index: libavcodec/avcodec.h
> ===================================================================
> --- libavcodec/avcodec.h	(revision 25765)
> +++ libavcodec/avcodec.h	(working copy)
> @@ -3027,6 +3027,14 @@
>  void av_shrink_packet(AVPacket *pkt, int size);
>  
>  /**
> + * Increase packet size, correctly zeroing padding
> + *
> + * @param pkt packet
> + * @param grow_by number of bytes by which to increase the size of the packet
> + */
> +int av_grow_packet(AVPacket *pkt, int grow_by);

maybe this should be size_t

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101120/d10a2cd2/attachment.pgp>