On Mon, 24 Mar 2014 10:09:45 +0100, Luca Barbato <[email protected]> wrote: > On 24/03/14 09:31, Rémi Denis-Courmont wrote: >> On Mon, 24 Mar 2014 06:09:58 +0100, Luca Barbato <[email protected]> >> wrote: >>>> no .log2_chroma_w/h? >>>> >>> >>> Monsieur de Lapalice states: >>> "Opaque pixel formats are opaque" >>> >>> I'll add a note about it in the wiki soon. >> >> Then again, the current hardware surface pixel formats are all 4:2:0 >> 8-bits YUV, aren't they? > > In case of VDA and VT it could be anything from UYVY422
Last I checked, libavcodec did not support hardware acceleration for anything other than 4:2:0 - just looking at the pixel format lists... Anyway, is there even *real* hardware slice-level decoder that supports 4:2:2? As far as I know, hardware video acceleration frameworks support 4:2:2 for post-processing and rendering, not (really yet) for decoding. > 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. >> Presumably new pixel formats would be required to >> unambiguously convey another chroma sampling or depth to the >> get_format() implementation. > > Nope, opaque is opaque, you know nothing of what's is inside and the > opaque must be able to describe itself. Sorry but that is crap. The application typically knows (and needs to know) the surface size. And sometimes it also needs to know the colour space, chroma sampling and composent depth. It is one thing that the surface content is not directly accessible. It is a completely different thing to know nothing of the surface properties. -- Rémi Denis-Courmont Sent from my collocated server _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
