On 12 March 2018 at 22:46, Mark Thompson <s...@jkqxz.net> wrote: > On 12/03/18 17:40, Rostislav Pehlivanov wrote: > > On 12 March 2018 at 00:23, Mark Thompson <s...@jkqxz.net> wrote: > > > >> On 12/03/18 00:01, Rostislav Pehlivanov wrote: > >>> On 11 March 2018 at 22:41, Mark Thompson <s...@jkqxz.net> wrote: > >>> > >>>> The old vaAcquireBufferHandle() API works in fewer cases and provides > >>>> less information than the current vaExportSurfaceHandle(), but it > exists > >>>> on older versions and is already used by the OpenCL code. This > probably > >>>> doesn't have much use directly, but it will be used to replace the > >> ad-hoc > >>>> OpenCL code in a following patch. > >>>> --- > >>>> libavutil/hwcontext_vaapi.c | 191 ++++++++++++++++++++++++++++++ > >>>> +++++++++++--- > >>>> 1 file changed, 179 insertions(+), 12 deletions(-) > >>>> > >>>> ... > >>> > >>> Why? libva 1.1.0 is 6 years old now. It doesn't make sense to have 2 > >> pieces > >>> of code to do the same thing. > >> > >> VAAPI 1.1.0 != libva 1.1.0. VAAPI 1.1.0 is in libva 2.1.0, released > last > >> month. > >> > >> (This is not confusing at all.) > >> > > > > ABH seems pretty much worse than ESH, and considering you can't get the > > format modifiers makes it useless for Vulkan. I don't see why we need to > > support it in addition to ESH. > > It's what it currently used by the Beignet/OpenCL interop (since it was > the only thing which existed when that was written, and the format modifier > isn't needed), and I don't want to break that. > > Since it was only released a few weeks ago it will probably be a while > before it lands in all distributions, and it isn't implemented at all by > the Intel ex-blob driver yet. > > - Mark > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
In this case wouldn't it be better if the ABH mapping function is moved to hwcontext_opencl? Then hwcontext_vaapi can be trusted to always produce completely mapped to DRM frames. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
