On 2012-12-07 12:17:41 +0000, Måns Rullgård wrote: > Janne Grunau <[email protected]> writes: > > > This allows us to use avcodec_get_edge_width() for the edge width > > without breaking svq1 fate-vsynth tests. > > --- > > cmdutils.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/cmdutils.c b/cmdutils.c > > index 42029d5..c374114 100644 > > --- a/cmdutils.c > > +++ b/cmdutils.c > > @@ -1293,7 +1293,7 @@ static int alloc_buffer(FrameBuffer **pool, > > AVCodecContext *s, FrameBuffer **pbu > > int i, ret; > > int pixel_size; > > int h_chroma_shift, v_chroma_shift; > > - int edge = 32; // XXX should be avcodec_get_edge_width(), but that > > fails on svq1 > > + int edge = avcodec_get_edge_width(); > > int w = s->width, h = s->height; > > > > if (!desc) > > @@ -1304,12 +1304,13 @@ static int alloc_buffer(FrameBuffer **pool, > > AVCodecContext *s, FrameBuffer **pbu > > if (!buf) > > return AVERROR(ENOMEM); > > > > + avcodec_align_dimensions(s, &w, &h); > > + > > if (!(s->flags & CODEC_FLAG_EMU_EDGE)) { > > w += 2*edge; > > h += 2*edge; > > } > > > > - avcodec_align_dimensions(s, &w, &h); > > if ((ret = av_image_alloc(buf->base, buf->linesize, w, h, > > s->pix_fmt, 32)) < 0) { > > av_freep(&buf); > > -- > > Can you please explain why svq1 breaks if the padding is added first? > I don't see why a codec should need to access more than the edge width > beyond the actual image.
svq1 needs alignment of 64 pixels (chroma aligned to 16 with AV_PIX_FMT_YUV410P). The fate sample is 352 pixels wide, adding two edge of 16 pixels results in a multiple of 64 and the dimensions are not further aligned. luma linesize is 96 and the decoder will decode six 16 pixel blocks, i.e. there is no edge padding. This results in smaller buffers for all codec except svq1. Svq1 is the only codec that needs more than 32 pixel alignment. The order of the operations matter only if edge width is not an integer multiple of the alignment. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
