[vlc-devel] [PATCH] vdpau: VDPAU hardware decoding with avcodec

[Rémi Denis-Courmont]

Le samedi 12 janvier 2013 20:50:26, Rafaël Carré a écrit :
> Le 12/01/2013 15:51, Rémi Denis-Courmont a écrit :
> > Le samedi 12 janvier 2013 16:42:16, Rafaël Carré a écrit :
> >> What happens if width % 4 == 1 ?
> >> 
> >> Do we end up with the 3 rightmost columns filled with random pixel data?
> > 
> > I don't know. That is what the VdpVideoSurfaceCreate documentation says:
> > 
> > "Note that certain widths/heights are impossible for specific values of
> > chroma_type. For example, the definition of VDP_CHROMA_TYPE_420 implies
> > that the width must be even, since each single chroma sample covers two
> > luma samples horizontally. A similar argument applies to surface
> > heights, although doubly so, since interlaced pictures must be
> > supported; each field's height must itself be a multiple of 2. Hence the
> > overall surface's height must be a multiple of 4."
> 
> Indeed it's a mess.
> 
> > Maybe we should only pad the width to an even value, but that would not
> > answer your question.
> 
> Yeah it seems width requirement is more lax than height.
> 
> 
> To reformulate my question, should we:
> - pad towards 0 (losing pixels) ?

I doubt the hardware decoder will work that way.

> - pad away from 0 (getting 'extra' pixels) ?

It should work. Unfortunately, if it does not, we will only know too late.

> - reject unaligned dimensions and use software decoder ?


-- 
Rémi Denis-Courmont
http://www.remlab.net/