On 2013-03-21 10:24:56 +0100, Anton Khirnov wrote:
>
> On Wed, 20 Mar 2013 15:59:32 +0100, Janne Grunau <[email protected]>
> wrote:
> > On 2013-03-12 12:48:35 +0100, Anton Khirnov wrote:
> > > Needed e.g. for h264 cropping to work properly.
> > > ---
> > > libavcodec/utils.c | 23 ++++++++++++++++++++---
> > > 1 file changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > > index b4c294e..bec0b3f 100644
> > > --- a/libavcodec/utils.c
> > > +++ b/libavcodec/utils.c
> > > @@ -549,14 +549,19 @@ static void compat_release_buffer(void *opaque,
> > > uint8_t *data)
> > >
> > > int ff_get_buffer(AVCodecContext *avctx, AVFrame *frame, int flags)
> > > {
> > > + int orig_width = 0, orig_height = 0;
> > > int ret;
> > >
> > > switch (avctx->codec_type) {
> > > case AVMEDIA_TYPE_VIDEO:
> > > if (!frame->width)
> > > - frame->width = avctx->width;
> > > + frame->width = FFMAX(avctx->width,
> > > avctx->coded_width);
> > > + else
> > > + orig_width = frame->width;
> > > if (!frame->height)
> > > - frame->height = avctx->height;
> > > + frame->height = FFMAX(avctx->height,
> > > avctx->coded_height);
> > > + else
> > > + orig_height = frame->height;
> >
> > under which conditions would frame->{height,width} be set? reusing a
> > frame? Why are we trusting those values for allocation? Especially
> > since a zeroed frame gets height and not MAX(height, coded_height). If
> > that frame is reused later we would allocate buffers not large enough
> > for the coded dimensions if those are larger.
> >
>
> A decoder might want to allocate a slightly larger frame for whatever reason.
> AFAIK no decoders do that currently, but Justin requested overriding the
> channel_layout in this way and it made sense to me to allow this for all the
> other parameters as well. We assume that if the decoder set those values
> explicitly, it knows what it's doing.
It doesn't make much sense to me. We have coded_{height,width} to
allocate a larger frame buffer. I don't see the need to add another one.
Janne
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
