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

[Laurent Aimar]

On Sat, Dec 10, 2011 at 06:07:21PM -0500, Rafaël Carré wrote:
> Le Sat, 10 Dec 2011 23:43:22 +0100,
> Laurent Aimar <fenrir at elivagar.org> a écrit :
> 
> > On Sat, Dec 10, 2011 at 11:00:07PM +0100, Rafaël Carré wrote:
> > > vlc | branch: master | Rafaël Carré <funman at videolan.org> | Sat Dec 10 16:58:35 2011 -0500| [fcc84608b67f3c3567b96604577bfdcc0de45b53] | committer: Rafaël Carré
> > > 
> > > avcodec: fix direct rendering with some codecs
> > > 
> > > Provide edge buffers when CODEC_FLAG_EMU_EDGE is set
> > > Fix ProRes playback with direct rendering
> > 
> >  From what I understand of avcodec, this is wrong. We need edge only when
> > CODEC_FLAG_EMU_EDGE isn't set while we always set it.
> 
> 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.

> > Besides, I think (but unsure) that you need to allocated edge on the right
> > *and* left side of the buffers, which won't work as is.
> 
> Right, I think it also includes top and bottom sides.
 That too.

> > Also, increasing the resolution won't correctly work, mostly due to filter
> > and vout modules (you will end up in some case with green pixels on the rigt).
> 
> What would go wrong? We don't change i_visible_width
 Most filters will use pixels beyong i_visible_width/height (up to
width/height). It's the same with some vout (ex: xvideo/opengl when they do
the resizing, it seems to depends on the driver though). If thoses pixels are
not set and end up in the visible part, you have artifacts.

 So basically, x/y offset, visible w/h are only safe to use if it's to crop
a picture and the left over part isn't garbage.

-- 
fenrir