Hi, On Mon, Feb 13, 2012 at 6:28 AM, Kostya Shishkov <[email protected]> wrote: > On Mon, Feb 13, 2012 at 03:13:53PM +0100, Anton Khirnov wrote: >> >> On Sun, 12 Feb 2012 19:22:37 +0100, Kostya Shishkov >> <[email protected]> wrote: >> > On Sun, Feb 12, 2012 at 06:15:59PM +0100, Kostya Shishkov wrote: >> > [...] >> > > >> > > New version will be sent with interface changed to encode2() >> > >> > and here it is >> > From 93afd2d5e913f653e9029906890ac66d3bcc49d7 Mon Sep 17 00:00:00 2001 >> > From: Kostya Shishkov <[email protected]> >> > Date: Thu, 2 Feb 2012 20:54:53 +0100 >> > Subject: [PATCH 2/3] prores encoder >> > >> > --- >> > Changelog | 1 + >> > doc/general.texi | 2 +- >> > libavcodec/Makefile | 1 + >> > libavcodec/allcodecs.c | 2 +- >> > libavcodec/proresdsp.c | 17 + >> > libavcodec/proresdsp.h | 3 + >> > libavcodec/proresenc.c | 836 >> > ++++++++++++++++++++++++++++++++++++++++++++++++ >> > libavcodec/version.h | 2 +- >> > 8 files changed, 861 insertions(+), 3 deletions(-) >> > create mode 100644 libavcodec/proresenc.c >> > >> > + >> > + pkt_size = ctx->mb_width * ctx->mb_height * 64 * 3 * 12 >> > + + ctx->num_slices * 2 + 200 + FF_MIN_BUFFER_SIZE; >> >> What a nice number you have there. >> >> > + >> > + if ((ret = ff_alloc_packet(pkt, pkt_size)) < 0) { >> > + av_log(avctx, AV_LOG_ERROR, "Error getting output packet.\n"); >> > + return ret; >> > + } >> >> ff_alloc_packet() means 'ensure that we have at least that much space', >> it's meant to be used when you know exactly how much space you need. I >> suppose that pretty number above is the upper bound, so encoding might >> work even if a user provides a smaller buffer. > > Indeed, in theory it should need about > (ctx->mb_width * ctx->mb_height * ctx->bits_per_mb) / 8 + headers_size > bytes, but currently encoder is limited by quantisers and may produce bigger > frame than that. > >> And it'd be really nice if you actually checked that you don't write >> outside of it. > > The funny thing is that put_bits should do that in theory but buffer size > doesn't seem to be used anywhere. At least it shouldn't overflow that frame > size even theoretically.
That's outside the scope of this patch, and I doubt it's useful. I wonder if we shouldn't just keep put_bits() unchecked and add checks to individual encoders. After all, corrupt input isn't an issue. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
