On Mon, Jul 06, 2015 at 09:37:34AM +0200, wm4 wrote:
> On Sun,  5 Jul 2015 23:03:24 +0200
> Michael Niedermayer <michae...@gmx.at> wrote:
> 
> > the later is not optimal when the buffer size is well known at allocation 
> > time
> > 
> > This avoids a memcpy()
> > 
> > about 1% faster
> > 
> > Signed-off-by: Michael Niedermayer <michae...@gmx.at>
> > ---
> >  libavcodec/v410enc.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/v410enc.c b/libavcodec/v410enc.c
> > index f2f7d73..5537a12 100644
> > --- a/libavcodec/v410enc.c
> > +++ b/libavcodec/v410enc.c
> > @@ -50,7 +50,7 @@ static int v410_encode_frame(AVCodecContext *avctx, 
> > AVPacket *pkt,
> >      uint32_t val;
> >      int i, j, ret;
> >  
> > -    if ((ret = ff_alloc_packet2(avctx, pkt, avctx->width * avctx->height * 
> > 4)) < 0)
> > +    if ((ret = ff_alloc_packet(pkt, avctx->width * avctx->height * 4)) < 0)
> >          return ret;
> >      dst = pkt->data;
> >  
> 
> This seems unintuitive. Shouldn't the "2" version be better and a full
> replacement of the original function, with the original deprecated? If
> not, then the naming of the function is utter misleading crap. What's
> the deal with this?

ill post a patch that deprecates it and solves this differently

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please

Attachment: signature.asc
Description: Digital signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to