[vlc-devel] [vlc-commits] avcodec: fix direct rendering with some codecs

Rafaël Carré funman at videolan.org
Sun Dec 11 20:47:55 CET 2011


Le Sun, 11 Dec 2011 11:25:29 +0100,
Laurent Aimar <fenrir at elivagar.org> a écrit :

> On Sun, Dec 11, 2011 at 01:03:33AM -0500, Rafaël Carré wrote:
> > Le Sun, 11 Dec 2011 00:29:54 +0100,
> > Laurent Aimar <fenrir at elivagar.org> a écrit :

> > > > Hm right, EMU_EDGE shouldn't draw in this border.
> > > > 
> > > > I'm not sure why this fixes ProRes decoding when EMU_EDGE is set,
> > > > perhaps libav doesn't respect the flag, or perhaps video buffers
> > > > provide the edges already?
> > > 
> > >  Either the prores decoder doesn't respect EMU_EDGE or it expects a greater
> > > buffer/pitch alignment than we provide.
> > 
> > We use different picture sizes for vout and decoder when using direct
> > rendering.
> No. The pictures than a decoder in VLC receives can comes from 2 sources:
>  1. the vout.
>  2. picture_New() (through a picture_pool I think)
> 
> In the case 1., we don't always control the properties of the buffers except
> that it will be large enough for holding width/height (ie we may not have
> sufficient data pointer/pitch alignment).
> That's partially why we have a compatibility check in ffmpeg_GetFrameBuf().

ok

> > vout pictures are aligned on requested width/height, but decoder
> > pictures width/height are modified by picture_Setup()
> > 
> >     /* We want V (width/height) to respect:
> >         (V * p_dsc->p[i].w.i_num) % p_dsc->p[i].w.i_den == 0
> >         (V * p_dsc->p[i].w.i_num/p_dsc->p[i].w.i_den * p_dsc->i_pixel_size) % 16 == 0
> >        Which is respected if you have
> >        V % lcm( p_dsc->p[0..planes].w.i_den * 16) == 0
> >     */
>  Not always, picture_Setup() set what VLC wants, but the vout may not be using
> it or it can always force other values (ex: xvideo does not use it, see
> PoolAlloc() in xcb/xvideo.c).

Yes i noticed that.

For ProRes, vout and decoder chromas are not compatible so there is no
direct copy: swscale is used instead.

> > IIUC we modify picture width so all planes are modulo 16 (IIUC), so
> > when there is chroma subsampling, even if the width is modulo 16, the
> > chroma planes are not necessary.
>  I don't understand this part/what you mean.

Usually there is the requirement that width/height are aligned on 16
(pixels) as required by the encoder.

I do not fully understand the maths, I thought that we require the
stride of each plane to be aligned on 16 bytes, but for the sample I
have (720x486), the luma stride is 1472 (== 32*x) instead of 1440
(2 * 720 which is already aligned on 32).

The height is changed from 486 to 498, neither are aligned on 32; and i
don't understand the purpose anyway.

> > pointers welcome
>  I am a bit dubious about the fact that the proress decoder in ffmpeg doesn't
> seem to check the value of CODEC_FLAG_EMU_EDGE. (h264 decoder does for
> example).

I thought that perhaps edges are drawn by some helper function because
only a handful of decoders check this flag, or perhaps they are just
not drawn at all.

Why do we need libavcodec to draw the edges for us anyway?

-- 
Rafaël Carré



More information about the vlc-devel mailing list