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

[Laurent Aimar]

On Sun, Dec 11, 2011 at 02:47:55PM -0500, Rafaël Carré wrote:
> > > 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.
Nope, no such things.
What avcodec requires:
 - each pitch/stride must at least be a multiple of 16
 - the base pointer of each plane must be aligned (16)
 - the stride/pitch of the luma has the right ratio against the chroma (eg: *2 for 420).
 - the buffer provided can at least store a picture of the wxh returned by
   avcodec_align_dimensions()
 - the pitch/stride of consecutives pictures are the sames.
and that suppose that we do request EMU_EDGE. If we don't, they are more
constraints that we cannot support at the moment.

> 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.

 Which colorspace? And what do you mean by width/height? (width/height or i_pitch/i_lines).

> > > 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?
 It's not that we require the edges, it's because we cannot provide a
buffer suitable for avcodec if we don't ask for EMU_EDGE (or if we could,
we would probably end up doing a copy later anyway, at least for playback).

-- 
fenrir