On 20/09/17 09:14, Christian König wrote: > Am 20.09.2017 um 00:01 schrieb Mark Thompson: >> This is a new interface in libva2 to support wider use-cases of passing >> surfaces to external APIs. In particular, this allows export of NV12 and >> P010 surfaces. > > First of all thanks a lot for taking care of this. > >> Signed-off-by: Mark Thompson <s...@jkqxz.net> >> --- >> Trivial update for a minor change requested on libva side (1/2 identical). >> >> Still unsure on what to do about size and interlacing. I'll have a look at >> the postproc code just posted soon, though I think it's pretty much entirely >> orthogonal to this. > > Probably best to convert the interlaced representation into the progressive > form before exporting.
I'd prefer not to do that, because a use-case of this is to be able to modify surfaces in-place. (E.g. decode, scale, export, blend something else onto the surface, fence, encode.) > Only alternative I can think of is to define new DRM > formats/modifiers/attributes, but then the application needs to be aware of > this as well. I'm not really sure what form that would need to take. The modifiers are meant for something else importing the surfaces, so what would support it and how? That would also require keeping the format part the same, I think (so an NV12 surface would still be an R8 plane and a GR88 plane, but with some modifier meaning it is actually present as two fields). It could work with the current construction by adding a way to indicate the surface is interlaced with separate fields. For NV12 it would then export four handles, one for each field of each plane. mpv at least should be able to handle this (there is already support for something similar for some nvidia vdpau cases), but I don't know how acceptable that would be to other users. Certainly it would be quite a lot harder to modify a surface in-place in a sensible way with that setup. I'm still unconvinced by the comments in the other thread about using interlaced surfaces by default - a lot of things would be easier if progressive were the default, and I have yet to find any case this actually fails in. Thanks, - Mark _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
