MFX_ERR_ABORTED from simple_transcode_opaque_async_vppresize

[celli4]

Hi,

First, I sometimes see some snarky and complaining comments about help here, and to weight in, I just thought I'd say I think the whole IMSDK team is awesome, it is obvious a huge complex multi-platform offering, and I am impressed how well it works! I think you guys deserve some credit.

I do want to report a minor issue for others who run into the same issue, and with the hope that someone can explain what is going on, and maybe make a fix for the next release.

This relates to the original [unmodified] 0.0.3 tutorial sample: simple_transcode_opaque_async_vppresize

This sample transcoder take 264 input and generates 264 output with the frame height and width divided by four.

The sample works great in hardware mode, or in software mode when ((input_width/4)%16==0)

If the input width divided by four is not mod 16, then when running with '-sw' the sample will fail on a Sync operations with MFX_ERR_ABORTED.

If you want to confirm the issue try this:

simple_transcode_opaque_async_vppresize.exe -sw -b 2000 -f 30/1 \w\bbb480.264 \w\bbb480out.264

Where \w\bbb480.264 is big buck bunny at 854x480. Any sample 264 input should show the problem as long as (input_width/4)%16!=0

This can be fixed, albeit not well, by changing the following line of code:

// original line
​mfxEncParams.mfx.FrameInfo.CropW = VPPParams.vpp.Out.CropW;

// fixed line
mfxEncParams.mfx.FrameInfo.CropW = MSDK_ALIGN16(VPPParams.vpp.Out.CropW);

This fix is a little inelegant, as the aspect ratio isn't quite right, and the VPP cropw is not matched to ENC cropw, but this narrows down what is causing the software transcodes for this sample to abort with MFX_ERR_ABORTED.

Please let us know if the software encoder requires CropW%16==0

End

important metrics:

Processor Type: Haswell 1225
Driver Version: Issue happens with libmfxsw64 and libmfxsw32-IMSDK2014Clients
Operating System: Wittnessed on Win7[+Clients-Imsdk] WinServer2008[+Clients-imsdk]
Quick Reproducer Code:  simple_transcode_opaque_async_vppresize.exe -sw -b 2000 -f 30/1 \w\bbb480.264 \w\bbb480out.264
Concise Description of the Issue:
Priority: Medium

[Sravanthi_K_Intel]

Hello there - Firstly, thank you for your kind words about the MSDK team! Now regarding your question - "Please let us know if the software encoder requires CropW%16==0" --> Yes, MSDK (HW and SW) require the width be aligned on 16. If you want to go ahead with unaligned resolutions, set the width aligned to 16, but use the original value for the crop.

Regarding --> "If the input width divided by four is not mod 16, then when running with '-sw' the sample will fail on a Sync operations with MFX_ERR_ABORTED." We expect the MSDK to tell you when you are working with non-aligned resolutions, and fail much earlier. (Not as late as Sync operation). I will check with the tutorials and get back to you if something is missing.

[Sravanthi_K_Intel]

Hello again. I was able to reproduce the issue you observed, and I found that the HW implementation of the tutorial worked without any issues, but the SW implementation failed for the same resolution and input (as you mentioned above). So for your question - "Please let us know if the software encoder requires CropW%16==0" --> NO, it does not have to be aligned to 16!

What you are observing is a bug in the SW implementation, and we will try to fix this soon. Although, you can use the HW implementation without any issues.

Thanks again for pointing out the issue.

[celli4]

Just a note for the historical record, I am now seeing this issue in certain combinations of driver/librarys on libmfx32.dll, NOT libmfxswxx.dll

In the situation I am seeing, cropw is evenly divisible by 16. So this is not the cause. 

Relevant version info where I see the issue.

HW version:1.3 API Level: 1.8
libmfxhw32 File Version: 5.14.3.6
libmfxhw32 Product Version: 5.0.33351.19917

[Sravanthi_K_Intel]

Hello there-

Thanks for getting back to us with this information. Can you kindly provide more details on the issue you are seeing (system, driver, experiment, sample/tutorial used, input, error observed and tracer log output)? This information could help us understand the behavior and escalate if needed. Thanks.