On Mon, Mar 24, 2014 at 9:40 PM, Rémi Denis-Courmont <[email protected]> wrote: > Le lundi 24 mars 2014, 21:24:47 Hendrik Leppkes a écrit : >> > The point is that currently those surface types are used by 4:2:0 surfaces >> > only. If support for 4:2:2 or Hi10p or whatever gets added to libavcodec, >> > the newly used surface types should be assigned new pixel formats, >> > consistently with the underlying acceleration APIs as well as with >> > libavcodec software pixel formats. >> > >> > It would suck for applications to have to second-guess libavcodec. >> >> IMHO, it would suck for applications to need yet another mapping table >> to map surface types to pixel formats, when one pixel format that says >> "there is a hardware surface in there" is all thats needed. > > I don't think it would suck. But most importantly, what you propose would > *break* existing applications, both at source and binary level. This is not > acceptable. > >> For most HWAccels, avcodec just doesn't need to know, nor should it know. >> >> If I take DXVA2 as an example, since thats what I know best, the >> application negotiates with the GPU driver which format is used, which >> can in theory be anything. In practice, most GPUs support NV12, some >> support YV12 additionally. > > DxVA2 negotiates the format while instantiating the decoder, but I somewhat > doubt that the drivers will actually do any good if the application does not > match the chroma sampling manually. In practice, applications just work > because so far, device drivers only ever exposed 4:2:0 8-bits such that there > is no way to hit a mismatch. But I would hardly be surprised if DxVA2 > applications started breaking if/when 4:2:2 or Hi10p-capable hardware comes > out. > >> avcodec does not care, nor should it care, which format I negotiated >> for with the driver. It just passes the opaque surfaces around, from >> the user app to the hardware decoder, and back again. > > avcodec *has* to care because it the application needs to know this. This is > needed for VA-API's vaCreateSurfaces() and VDPAU's VdpVideoSurfaceCreate to > work, period. > > Not only that, but it obviously affects semantics when dumping the frame to > main memory, or when exporting it to OpenGL/EGL/OpenCL/CUDA/NVENC/QSV/whatever > via interoperability functions. >
But this is all stuff the user app calls, *not* avcodec. If you create the surface in some format, you better remember which format that was when you interact with it after decoding again. avcodec does *not* interact with the surface, therefor it does *not* need to know which format it is in. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
