Le lundi 24 mars 2014, 20:32:39 wm4 a écrit : > > > to YUV420Planar to ... > > > > There are several cases whereby the application needs to know the > > underlying type of a surface: > > 1) A function is the acceleration framework requests it as a parameter. > > 2) The application wants to copy the surface content back to main memory. > > 3) The application wants to show the chroma sampling as meta-data. > > 4) The application exports the surface via interoperability (e.g. to > > OpenGL). > > > > Hence, it seems more reasonable to allocate separate pixel formats for > > separate samplings and depths... if the situation ever arises. > > My code in theory supports different hardware formats (although in > practice it's always 420, and anything else wasn't useful yet).
With VDPAU, VLC supports 4:2:2 already (and it has even been tested succesfully for post-processing and rendering). But it uses different pixel formats for 4:2:2 than 4:2:0. 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). 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. I don't know how it is with VDA. But both VDPAU and VA-API work that way. And it is not like the libavutil pixel format enumeration is short on numbering space. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
