in our own video decoder software we use the IPP to decode simple CIF videos with 352x288 as resolution.
On our target this video format is scaled to fill the complete LCD aera with 800x600 as resolution.
Our customer is not happy about the video quality. Indeed VLC manages it to show the same video better than our own software using the latest IPP.
We analysed that deinterlacing and hardware overlay support cannot be the difference between our software and VLC. We supposed that VLC uses another YUV format and other scaling functions for their better video decoding result.
We do not know if we are using all features of the ATOM's hardware video decoding acceleration, but it is sure, that it is possible, to get a better decoding quality. At the moment we do not know how we can reach the same quality as VLC has it.
VLC needs a bigger amount of the system's performance to decode videos. Most of the system's load for VLC are in kernel mode. I suppose that VLC uses special driver calls of Intel's hardware to ensure the best video decoding quality even in spite of other parallel processes in user mode.
How can we configure video decoding of MPEG2 in different YUV formats by using the IPP and does this have any influence on the ATOM's scaling functions?
Is it possible to use Intel standard drivers or special IPP functions to shift copying of decoded frames from the renderer to the graphics device from user level to kernel level during execution?
With help of the IPP support I got the informations that the IPP itself does not provide any special functions to use acceleration features of the IEGD driver.
Are there any known tricks how to see if all hardware acceleration features of Intel's ATOM are active and how it is possible to use them with the IPP?
How can we get such special support to use all features of our given hardware and software libraries in the best way?
I would like to check with our IPP team to see how we can best assist you. In the meantime, can you let me know which exact Intel Atom Processor you are using? Since many Intel Atom Processor based platform have different SoC components the answer may differ based on your design.
I am sorry to tell you that there currentlu are no Atom platform graphics chip specific hardware accelerations in the Intel IPPs.
If you provide us more detailed about the operating system you are looking at and the specific Intel Atom Processor you are targeting we can however escalate this as a feature request. We would use the Intel Premier Support issue you alrerady filed for this escalation.
I may also check whether there could be a non IPP based way to help you.
we use two different Q7 modules with an ATOM on it.
Intel ATOM CPU (Z510 and Z530) with US15W chipset.
First one has 1.6GHz and 1GB RAM and 4GB Flash memory.
Second one has 1.1GHz and 1GB RAM and 2GB Flash memory.
here are some more informations about out environment. As OS we have Xpe.:
Version: IPP 7_0_1_104 Edit
Subcomponent: Video Coding Edit
Development OS: Windows* XP Professional Edit
Development Host: Intel Atom processor Edit
Target Host: Other (note below) Edit
Target OS: Windows XP* Edit
Other Environment (not listed above): ATOM on Q7 module with 1.1GHZ or 1.6GHz Edit
Windows* Development Environment: Microsoft Visual C++* 2008 Edit
One interesting hint came from the IPP's support, see the following point 3:
3) Regarding the software decoder quality itself.
You mentioned," We analyzed that deinterlacing and hardware overlay support cannot be the difference", so the problem mainly are YUV format and scaling function.
Could you tell what scaling function/deinterlacing and YUV format are you using????
If IPP scaling function and deinterlacing function, IPP experts recommended that the best quality for 352x288 -> 800x600 will be achieved with ippiResizeSqrPixel with Lanczos interpolation mode instead of NN
or use ippiDeinterlaceFilterCAVT or ippiDeinterlaceMotionAdaptive instead of ippiDeinterlaceFilterTriangle.
YUV format, it call IPP color conversion function to produce what you expected. For example, YUV420->YUV422, ippiYCbCr420ToYCbCr422_8u_P3R
I talked with our developer then. We cannot do scaling in software because our hardware platform is not fast enough. Therefore we must do scaling with help of the hardware. At the moment we do not know how to use other YUV formats or other scaling functions on the ATOM's hardware. It seems to be that VLC knows it how it can be done to get the best video quality. The IPP itself do not support the using of special hardware features. I suppose that we have to find out how the can use better scaling function on our hardware.
that sounds good.
I am looking forward to hearing from you.
Our OS is XP embedded and we are using IEGD 10.3 on our ATOM platform as graphics device driver.
Currently I try to get more informations from our developer so that I can tell you the kind of calls which we are using now. Maybe this can be helpful to identify other calls which will lead to better scaling results.
as driver we use the IEGD 10.3 for the ATOM US15W chipset.
YUV conversion is done by IPP functions on demand. Deinterlacing is done by IPP functions.
As color format we use UYVY at the moment. The simple MS function IDirectDrawSurface7::Blt() is used to show video frames. This Blt() function does the scaling from 352x288 to 800x600.
With regard to VLC I can say that VLC uses hardware overlay and acceleration on our hardware platform. Even conversion from YUV to RGB is activated. Deinterlacing is set on blend mode. To see a video on the screen DirectX output must be activated in VLC's preferences for video decoding.
So the hardware and the OS should support various hardware accelerated functions. VLC manages it to show a better scaling result of the SIF video on the 800x600 screen.
Nevertheless VLC consumes a lot the system's performance in kernel instead of Windows' user mode. For example VLC needs 20% of the system's performance and 15% of the 20% runs in kernel mode. Our player with the IPP needs 15% of the system's performance and a maximum of 3% are in kernel mode. I guess VLC does a lot with the graphics driver in a direct way.
in addition to previous mail I havefurther version informations ofour driver for you.
As driver we use the IEGD 10.3 for the ATOM US15W chipset. Driver iegdmini.sys has the version 220.127.116.110. It is the Intel EGMD or Embedded Graphics Miniport Driver.
I appreciate all the input. Currently it looks as though we won't be able to help you much from an IPP perspective. Ying and myself both are currently actually already talking to the EGMD driver team. Hopefully they can come up with a driver update along with some additional guidance.