[Libva] libva vs intel media SDK

Zou, Nanhai nanhai.zou at intel.com
Tue Feb 28 23:04:51 PST 2012


Hi,
         Thanks for reporting. We will improve macroblock type selection.
That requires moving most of CPU code into GPU kernels. We are doing that(move CPU code to GPU kernel) in staging branch.
After that is done, we will get rid of the hardcoded macroblock type selection.

Thanks
Zou Nanhai
________________________________
From: Joe Bloggsian [mailto:joebloggsian at gmail.com]
Sent: 2012年2月28日 18:06
To: Zou, Nanhai
Cc: libva at lists.freedesktop.org
Subject: Re: [Libva] libva vs intel media SDK

Hi - thanks for replying.

So far we tried master and vaapi-ext. I did notice staging appear but have not tried it yet. Will give it a go and let you know how I get on.
To be clear my main concern is the video quality. Whilst the windows performance might be much faster libva encode is still quite fast (compared to software) and the CPU usage is very low (as long as a recent kernel is used). What prevents it from being useful is the very poor video quality. In particular I'd highlight the mode selection in P-frames- not selecting I macroblocks, P paritions other than 16x16, poor skip mode selection, etc, none of which are problems in the Windows encoder. Is this something I can expect to already be improved in the staging branch?

Cheers,
Mark

On 28 February 2012 01:31, Zou, Nanhai <nanhai.zou at intel.com<mailto:nanhai.zou at intel.com>> wrote:
Hi,
         Which branch are you using?
         We’ve done a lot of optimization in ext branch now in staging branch. Those optimization are still not in master branch yet.

Thanks
Zou Nanhai

________________________________
From: libva-bounces+nanhai.zou=intel.com at lists.freedesktop.org<mailto:intel.com at lists.freedesktop.org> [mailto:libva-bounces+nanhai.zou<mailto:libva-bounces%2Bnanhai.zou>=intel.com at lists.freedesktop.org<mailto:intel.com at lists.freedesktop.org>] On Behalf Of Joe Bloggsian
Sent: 2012年2月28日 6:07
To: libva at lists.freedesktop.org<mailto:libva at lists.freedesktop.org>
Subject: [Libva] libva vs intel media SDK

Whilst evaluating intel processors for an embedded application I did some comparisons of H.264 video encode / transcode using libVA versus Intel Media SDK. I used the same i3/HD3000 sandy bridge machine dual booted to win7 & ubuntu. I built the latest kernel on ubuntu and tried both va-api/intel driver ext and master. On Windows I used the multi transcode sample app and modified it to transcode 8 parallel 1080p30 H.264 streams and used HW encoding (speed mode). For va-api I modifed the encode sample to encode 8 parallel streams I also preloaded and converted to NV12 etc all the video frames to take that out of the equation. Both encoded to the same bitrate, etc. I verified in each case (using intel-gpu-top / intel graphics performance analyzer) that the GPU was being used and 100% busy in each case.

Speed : Media SDK was nearly 2x faster than libVA.
Quality: Analysing the streams Media SDK is vastly better -the encode uses all I4 and I16 modes, P-partitions down to 4x4, skip and long motion vectors versus libVA which seems to use just I4x4 in I-frames and just P16 mode in P-frames. The quality difference in the encode is night and day.

To bring a long post to and end, my question is why the huge difference between Windows and Linux for what is essentially a hardware encode? Am I doing something wrong? I see that there is a lot of activity improving vaapi/intel driver from intel engineers - who presumably have access to the Intel Media SDK source/developers. Is there an expectation or roadmap to close the gap in the near future? Of particular interest is the low quality of the va-api encode which makes it unuseful for many applications. I'd be interested in getting involved improving the libva driver but the intel GPU PRMs seem to contain detailed information on everything *except* the video encode/decode HW.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20120229/2e463839/attachment.htm>


More information about the Libva mailing list