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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel