[vlc-devel] [PATCH] vdpau: VDPAU hardware decoding with avcodec
funman at videolan.org
Sat Jan 12 19:50:26 CET 2013
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) ?
- pad away from 0 (getting 'extra' pixels) ?
- reject unaligned dimensions and use software decoder ?
I guess it's 2nd choice if possible, else 3rd choice.
More information about the vlc-devel