[vlc-devel] [PATCH] vdpau: VDPAU hardware decoding with avcodec
remi at remlab.net
Sat Jan 12 20:01:35 CET 2013
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 ?
More information about the vlc-devel