On 24/03/14 21:32, Rémi Denis-Courmont wrote: > 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). 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). > 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. > I don't know how it is with VDA. But both VDPAU and VA-API work that way. vdpau according to the code I'm seeing for avconv and mpv does work as I'm stating: - 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). Nothing breaks and nothing would break even by moving to hwaccel2 while keeping a single pixel format for hwaccel. Probably would be easier if I get you a patchset for vdpau (libav and vlc) so what I mean is clear. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
