output RGB32 frame is corrupted using HW decoder and VPP

[Ramashankar]

Hi,

I am referring the 'sample_decvpp.exe' (64 bit version) from media sdk sample (6.0.0.49).

I am decoding a input h264 stream and doing the video post processing for converting the YUV frame into RGB32. When I configure decoder to use SW decoding then it is providing proper RGB frames, but when I configure decoder to use HW decoding and d3d memory type, then all my output RGB frames are corrupted.

Initially i thought there could be some issue with my implementation, but then I checked and observed this same issue with original sample_decvpp.exe application also.

So can you suggest if there is any known issue/limitation as such?
details:

input stream: h264 with resolution (1600x912)

graphics card: Intel HD graphics 3000, driver version: 9.17.10.3517

OS: windows7 64 bit

~

Ramashankar

[Ramashankar]

Some more information related to this issue:

This issue is specific to one of my test machine which has two display adapters installed.

1. AMD Radeon HD 7600M Series

2. Intel HD Graphics 3000 (driver version 9.17.10.3517)

When I tried after disabling AMD adapter (just for testing purpose) then sample_decvpp application Init() failed.

When I run my application and sample_decvpp application on second test machine which has only one card which is Intel HD graphics 4400 card (driver version 10.18.14.4170) then both the application provides proper RGB32 frames using HW decoder with d3d11 & d3d9 memory both.

So please suggest if it is any issue related with dual graphics card on first test machine or driver version for HD 3000 graphics card.

Attaching the Media SDK System Analyzer logs for both machine:

1. sys_analysis_Test1.txt (it has this issue)

2. sys_analysis_Test2.txt (no issue here)

[Jiandong_Z_Intel]

Hi There,

Your graphic driver for Intel HD Graphics 3000 is not an up-to-date one.

Can you please download from following URL and setup the up-to-date driver.

https://downloadcenter.intel.com/product/81500 and select "Intel® HD Graphics Driver for Windows* 7/8-64-bit"

Let's see if the same issue happened.

Thanks

Zachary

[Ramashankar]

Hi Zachary,

Thanks for your reply. I am downloading the driver now and will check the behaviour once again after updating it.

Meanwhile, I have a doubt: When I check for updating this driver (using windows GUI to 'check for update software' ) then OS always tells that your driver for this graphics card is up-to-date.

So is it recommended that we should manually check for driver update on Intel's site?

[Ramashankar]

Hi Zachary,

I have updated the driver (version is 9.17.10.4229 now), but problem is still same. Output RGB32 frames are corrupted (a green color is spread over all the frames mostly).

Can you suggest me what to do now?

To reproduce this issue, you can run the sample_decvpp.exe and configure it to decode h264 stream and get the output using -rgb4 option.

Note: while updating the driver, the new setup warned that the driver which you have currently is already higher than the one which you are going to install. So this will overwrite your driver to older version. Do you want to continue?

Though i ignored this message and update the driver and it was updated to higher version.

So I think there is some error in version checking in this new setup.

[Sravanthi_K_Intel]

Looking at your sysAnalyzer files, it seems like your first system is a SNB processor with graphics 3000 - which had a very initial version of HW decoder and some basic implementation of video processing. That version did not have YUV->RGB conversion. Your second system is much more recent and has these implementations in HW - hence, its working fine.

So, this issue you are seeing is not related to having multiple display drivers, its because of old system/graphics on it.

[Ramashankar]

Thanks for the information Sravanthi.

but there is some more observation here:

1. If i run sample_decode.exe (output is in yuv420 now) with rendering mode and output dump mode both are ON, then also this corruption issue occur when i play the dump yuv420 file. It is using "HW decoding with D3D memory" in this case.

Command: [sample_decode.exe h264 -i test.h264 -r -o out.yuv]

2. If i run smaple_decode.exe without rendering mode and with only dump mode ON then there is no corruption in dump yuv420 file. Here it is using "HW decoding with SYSTEM memory".

Command: [sample_decode.exe h264 -i test.h264 -o out1.yuv]

Here I am understanding  that there is no YUV->RGB conversion being perform in first case but still output yuv420 frame is corrupt. So my doubt is that issue is not in YUV->RGB conversion on this graphic card, but in h264 HW decoder implementation using D3D memory for this card.

what do you think and suggest?

[Sravanthi_K_Intel]

Hello Ramashankar - Are you observing this behavior on your system config 1 (MAD+intel gfx 3000) or config 2 (intel gfx 4400)? Also, can you give some more details on the version of samples package you are using, and also the complete command-line and output (API version).

[Ramashankar]

Hi Sravanthi,

yes, this behaviour is only on system config 1 (MAD+intel gfx 3000, driver version is now 9.17.10.4229) while using HW decoding with D3D memory.  Version of media sdk is 6.0.0.349 and sample's version is 6.0.0.49. API version is 1.4. 

Command to run the app:

Case1:  sample_decode.exe h264 -i test.h264 -r -o out.yuv

Here out.yuv (yuv420 format) file is corrupted. Refer the image Case1_Corrupted-YUV420.jpg.

Case2:  sample_decode.exe h264 -i test.h264 -o out1.yuv

Here out1.yuv file is proper. Refer the image Case2_Proper-YUV420.jpg.

The only difference in both cases is that 1st one is using D3D memory and second one is using System memory.

[Jiandong_Z_Intel]

Hi Ramashankar,

When using -r parameter, Did you see any render window ?

I found Samples for Intel Media Client version 6.0.0.68 is newer than the one your are using (6.0.0.49).

Can you try Samples for Intel Media Client version 6.0.0.68 ?

Thanks,

Zachary

[Sravanthi_K_Intel]

Hi Ramashankar - Thanks for the information. The version of MSS and the platform you are testing on are quite old and unfortunately, we do not have enabling efforts for versions that old. The latest version of MSS (and their associated platform) have many fixes that were not there previously, and it is non-trivial to compare the exact version you have to the one we support now. So, I am afraid you will not find much debug support coming for that old a config.

For config (1), you are using D3D9 -> and as we have discussed in many previous threads about D3D9 limitations in the case of discrete graphics, and how D3D11 fixes that issues. In addition, for system you have, we have known limitations in our HW capability with Gfx 3000 (rather, the HW we have now is much improved over the HW then), and the MSDK API 1.4 is very very old and lacks many fixes that were introduced since then (you are at 1.4 and today the latest is 1.16). In addition, the samples package being used with MSDK may or may not be the correct version. In short, there are too many variables here with such an old system, and unfortunately, we cannot provide much support on that. If you have a product that is gated on this particular issue, please feel free to send us more information via private message (you can click "Send Author A Message" to send private messages), and we can take a look. 

Having said that, why are you using "-r -o out.yuv" together? If removing "-r" and simply doing "-o" works, can you use that instead? Also, if you can remove the AMD card (disable it at boot, may be) and only enable Intel integrated graphics on your config (1), do you still observe the issue?

[Ramashankar]

Hi Zachary and Sravanthi,

@Zachary: 

>> When using -r parameter, Did you see any render window ?

NO. there is no render window when I use -r option with -o.

>> Can you try Samples for Intel Media Client version 6.0.0.68 ?

I have tried this sample version also. Sample_Decode and Sample_Decvpp both exe work perfectly in SW decoding mode, but both exe are getting crashed in HW decoding mode. I guess it could be due to running this latest hw decoder implementation on a very old graphics card n driver.

@Sravanthi:

Thanks for clarification. Yes i understand that my card and driver are very old and outdated now (supports till API version 1.4) .

Actually I want to implement a h264 HW decoder which can provide output frames in rgb32 format. I need to support this solution on Windows8 and Windows7 both environment with maximum possible performance. So I was configuring my decoder for hw decoding with d3d memory. On windows8 machine (my test machine 2) i am getting the best performance using d3d11 meory, so i was trying to use d3d9 memory on windows7 machine (my test machine 1). But here i was getting corrupted rgb32 frames.

>> Having said that, why are you using "-r -o out.yuv" together? If removing "-r" and simply doing "-o" works, can you use that instead?

I was actually investigating whether issue is in my implementation, or in intel's sample vpp module or in sample decode module. So i came to conclusion that on this particular environment (test machine1) h264 HW decoder itself is giving corrupt YUV420 frames while using d3d9 memory.

But as you mentioned that there is no support from Intel side for this old environment so you can close this thread. I might need to go with Intel's SW decoding mode for such old environment.

Thanks.

[Jiandong_Z_Intel]

Hi Ramashankar,

I am closing this issue, if you have any questions in the future please start a new thread.

Thanks

Zachary

[Ramashankar]

Hi Zachary,

Yes I have one last question. As it is totally related to this thread/issue only so i am asking it here only. Please support and reply.

As per my investigation on test machine 1 (with graphics card intel HD 3000 and HW MSDK API version 1.4):

1. using sample_decode.exe:

a. SW decoding + system memory => output YUV420 is fine

b. HW decoding + d3d memory => output YUV420 is 'corrupted'

c. HW decoding + system memory => output YUV420 is fine

2. using sample_decvpp.exe

a. SW decoding + system memory + VPP for output conversion in RGB32 format => output RGB32 is fine

b. HW decoding + d3d memory + VPP for output conversion in RGB32 format => output RGB32 is 'corrupted' (assuming that it is because of case 1(b))

c. HW decoding + system memory + VPP for output in RGB32 format => output RGB32 is 'corrupted' (But referring case 1(c), I was expecting this case to work fine as output of decoder would be proper. but probably vpp module is also injecting some frame corruption in conversion).

When i checked the code of sample_decvpp (CDecodingPipeline::CreateAllocator()), I observed that sample_decvpp application is always creating d3d surfaces allocator even if we set memory_type to SYSTEM_MEMORY, while this is not the case with sample_decode application.

So my question is that: is it necessary to provide only d3d surfaces to vpp module for frame conversion (even if i use system_memory)? or it is kind of any bug or unimplemented support in this sample application?

I have a slight hope that by making some correction in this surface allocation mechanism in sample_decvpp, I can run my case 2(c) successfully and so can utilize HW decoding capability on that test environment also.

Please let me know if you can provide some info/help on this.

Thanks.

[Jiandong_Z_Intel]

Hi Ramashankar,

For test vpp module for frame conversion, You can try sample_vpp.exe, this MSDK sample only test vpp,  

Thanks

Zachary

[Ramashankar]

Hi Zachary,

With reference to my these observations:

1. using sample_decode.exe:

    c. HW decoding + system memory => output YUV420 is fine

2. using sample_decvpp.exe

    c. HW decoding + system memory + VPP for output in RGB32 format => output RGB32 is 'corrupted' (But referring case 1(c), I was expecting this case to work fine as output of decoder would be proper. but probably vpp module is also injecting some frame corruption in conversion).

I found a fix for this case 2(c) issue which I want to confirm here, just to check if it has any side effect or not. In Sample_Decvpp, I configured to use System memory for frame processing between Decoder output and VPP input, in case of HW decoding with SYSTEM_MEMORY option. Earlier it was configured to use video memory in this case.

So I commented below implementation:

    // m_bSysmemBetween = (pParams->bUseHWLib) ? false : true;

and added this:

   m_bSysmemBetween = (m_memType == SYSTEM_MEMORY) ? true : false;

With these changes, I could get correct RGB32 frame from Decoder+VPP combination in case of HW decoding + SYSTEM_MEMORY option.

Though HW decoding with D3D_MEMORY option is still corrupt but it is expected due to old hardware and driver (as you people explained above).

So can you let me know if there is any negative impact of my above code changes. One, i could guess, is slight performance decrease.

Thanks