Problem with sample_transcode* between SW and HW DLL and

[ME]

Using the current tutorial sample_decode and sample_decode-d3d, this is my problem I am working on getting around.

The attached file (I named it t.264) runs very differently through the HW and SW DLLs.

 simple_transcode and -d3d (in the current tutorial) using only the SW DLL

   simple_transcode.exe  (SW DLL)
   Frame number: 691
   Execution time: 3.70s (186.58fps)
 
   simple_transcode-d3d.exe  (SW DLL)
   Frame number: 21
   Execution time: 0.19s (109.49fps)
 
Each same EXEs run using HW DLL v 10.18.10.3349  dated 3 Nov 2013

   simple_transcode.exe  (HW DLL)
   Frame number: 2
   Execution time: 0.02s (98.11fps)

   simple_transcode-d3d.exe  (HW DLL)
   Frame number: 2
   Execution time: 0.01s (142.31fps)

The t.264 source file was created by the IM SDK encoder.

The 691 frames is correct.

The only change to any of the source files (src, common, whatever) was the line

    fopen_s(&fSource, "bbb1920x1080.264", "rb");

was changed to

    fopen_s(&fSource, "t.264", "rb");

Now here is hoping I can attach the .h264 (715 KB only).  If not with this I give it a shot in a new post.

[Petter_L_Intel]

Hi,

there is a known issue with the current revision of the Media SDK tutorial for small compressed input files. From your description it seems you have encountered this issues. We plan to resolve this in a new release of the tutorial, due shortly.

In the meantime please insert the following code snippet:

            if(MFX_ERR_MORE_DATA == sts)
            {
                // MFX_ERR_MORE_DATA indicates encoder need more input, request more surfaces from previous operation
                sts = MFX_ERR_NONE;
                continue;
            }

directly after the "for(;;) {....}" loop statement which encapsulates the EncodeFrameAsync call, for both the stage 1 and stage 2 parts of the code.

Regards,
Petter

[ME]

Yes, thanks, that did the trick (and 695 samples it is, not the 691 samples that made it through the first version).

C:\tmp>simple_transcode
Frame number: 695
Execution time: 2.38s (291.57fps)

Ready for hopefully another simple one?  Same t.264 file in the t_0.zip, this time with the sample decoder (regular sample, not the tutorial simple sample).

When playing the t.264 (create by the IM SDK encoder) file using the SDK sample decoder, for eeach of the frames it puts the following (the presenter line). Also, it stops at 691 frames, not 695 (I haven't counted to know for sure which it is but they can't both be right.)

 Using  h264 -hw -i t.264 -r

Intel(R) Media SDK Decoding Sample Version 4.0.760.60203

Input video    AVC
Output format    YUV420
Resolution    640x368
Crop X,Y,W,H    0,0,0,0
Frame rate    30.00
Memory type        d3d
MediaSDK impl        hw_d3d11
MediaSDK version    1.7

Decoding started
DwmSetPresentParameters failed with error 0x80004001.
Frame number: 1
DwmSetPresentParameters failed with error 0x80004001.
Frame number: 2
   :
DwmSetPresentParameters failed with error 0x80004001.
Frame number: 690
DwmSetPresentParameters failed with error 0x80004001.
Frame number: 691
Decoding finished

[Petter_L_Intel]

Hi,

You will encounter the "DwmSetPresentParameters" log statement if you try to render the decoded content using Windows 8.1. Parts of the Microsoft DWM interface was deprecated in Windows 8.1.   This is not an issue, it just means the the rendering speed will be limited to lower frame rate.

Regards,
Petter

[ME]

Thanks.  Win8 messes with perfectly fine pre-8 code and (tl;dw).

There is still the frames count mismatch.  The sample from the SDK shows 691 frames.  The corrected simple sample from the tutorial shows 695.  I can take a look to see if it is the same problem (the SDK samples are very hairy compared to the simple tutorial samples).

SDK code samples are monkey-see, monkey-do things - give us a wrongly done sample code and most using-code will be no better.