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:joebloggs...@gmail.com]
Sent: 2012年2月28日 18:06
To: Zou, Nanhai
Cc: libva@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....@intel.com<mailto:nanhai....@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....@lists.freedesktop.org<mailto:intel....@lists.freedesktop.org>
[mailto:libva-bounces+nanhai.zou<mailto:libva-bounces%2Bnanhai.zou>=intel....@lists.freedesktop.org<mailto:intel....@lists.freedesktop.org>]
On Behalf Of Joe Bloggsian
Sent: 2012年2月28日 6:07
To: libva@lists.freedesktop.org<mailto:libva@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.
_______________________________________________
Libva mailing list
Libva@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libva
