[Libva] How to detect the type of memory returned...

[Gwenole Beauchesne]

Hi,

2014-06-17 9:13 GMT+02:00 Jean-Yves Avenard <jyavenard at gmail.com>:
> [was replied privately by mistake. Resending it to the list]
>
> Hi
>
> On Tuesday, June 17, 2014, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
>> Yes, I know, I only answered to Rainer and wanted to experiment
>> something on your case before commenting.
>
>
> And what did your experimentation returns? :)
>
> Right now; what I've done (currently only in use in mythtv) is a
> USWCCopy class that the first time it is called to perform either a
> frame copy or a nv12->yv12 conversion, is timed the two different
> routines and select the fastest one for future use.
> It's certainly not pretty, nor elegant; but it works reliably seeing
> that the USWC copy methods is clearly faster in one case, and clearly
> slower in the other.
>
>
>
>> > Any recommendations?
>>An optimization is indeed possible on the driver, in case you create a VA image.
>>BTW, for VLC, the issue with using vaGetImage() is that the driver
>>currently does not provide bitexact conversion from NV12 to I420/YV12.
>>This is an issue that needs to be fixed at lest for same size
>>conversions. Otherwise, the the "Advanced Video Scaler" (AVS) engine
>>is always used, which tries to enhance the image along the way.
>
>
> I can't say I've been able to visualise the difference with moving
> images. But I haven't looked in that much details anyway.
> VaGetImage returned frame certainly good enough.

Note: I am not in the business of doing things "good enough", I want
100% correctness. :)

So, for same-size transfers (uploads / downloads) with the same
sub-sampling requirements (i.e. YUV 4:2:0), there shall be a way to
produce and guarantee that what we get on the other side exactly
matches the source. Otherwise, you are risking propagation of errors
for subsequent frames (postprocessing in terms of downloads, quality
of encoding in terms of uploads), thus reducing the overall quality.

The next fix to get in is also a patch that disables AVS for same-size
/ same-subsampling transfers on the Intel HD Graphics driver side.

> With vaDeriveImage, 30% of the time spent in processing a frame from
> file to display is actually the NV12->YV12 conversion.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199