[vlc-devel] [vlc-commits] avcodec: fix direct rendering with some codecs
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().
> > 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
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?
More information about the vlc-devel