Le lundi 24 mars 2014, 21:46:54 Luca Barbato a écrit : > > If suddenly libavcodec started offering AV_PIX_FMT_VDPAU for 4:2:2, > > decoding would break. VLC would not know that suddenly a pixel format > > that was 4:2:0 has become 4:2:2 (too). > > Nothing would happen "suddenly", you set in the global context which is > the pixel format (so you know by the time your callback is it in > get_format).
Oh yes it will break. The hardware might be able to decode a 420 bitstream into a 422 surface. But it definitely will not be able to decode a 422 bitstream into a 420 surface, because the memory allocation will be too small. Thus all applications that assume that AV_PIX_FMT_VDPAU or AV_PIX_FMT_VAAPI is 420 will break. Even your own avconv_vdpau will break! > > It would therefore allocate VDP_CHROMA_TYPE_420 > > surfaces from the hardware. That is obviously wrong and a backward > > compatibility breakage. > > > > The correct approach, should the need arise, would be to define > > AV_PIX_FMT_VDPAU_422 or whatever. Then old VLC versions would ignore and > > fall back to software decoding as before. New versions can add support > > safely. > No, and you got 3 different explanations why it is wrong. The only explanation I got was that it is possible for an application to work around the problem by checking the last pixel format. That is an ugly, limiting work-around and does not solve backward compatibility in any way. > vdpau according to the code I'm seeing for avconv and mpv does work as > I'm stating: As a matter of fact, the avconv_vdpau code hardcodes 420 chroma type both in hardware capability check and in surfaces allocation. If you ever feed it non-420 bitstream, it will break just as badly as VLC. > - on get_format you figure out what you need and set it in the global > context. > - on get_buffer you provide the buffer using the correct VDP_ > (CHROMA_TYPE|YCBCR_FORMAT). The read-back code supports 422, but the surface allocation code does not and will break. For ****'s sake, there is not a single mention of VDP_CHROMA_TYPE_422 in the entire libav tree. > Nothing breaks and nothing would break even by moving to hwaccel2 while > keeping a single pixel format for hwaccel. Oh yes things break. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
