par.mfx.BufferSizeInKB is 9375 (KB)

[ME]

BufferSizeInKB
BufferSizeInKB represents the maximum possible size of any compressed frames

So, a 1280 x 720 encode comes back from .Init set to more than 9 MB.  Is this even the right ballpark?

So, a 640 x 368 encode comes back from .Init set to exactly the same size, more than 9 MB.

What's up here?  I expect this to be more like maybe 100 KB or so.  Why 9375 KB, and why the same for even the div/2 frames?  This is supposedly the h264 ES frame, not a monster YUV.

This is from intel_media_sdk_tutorial_041813\simple_5_transcode\src\simple_transcode.cpp, around line 167, the value of par.mfx.BufferSizeInKB (not x 1000, but the var itself), and from my own stab at this, with VPP in there doing div/2 on the size (yet still the same 9375 KB).

My target bitrate is 500 kbps.  A typical i-frame from the simple_transcode.cpp run is about 4 KB (as in 4000 bytes, not 9 million).  I may have multiple transcodes running so 9 MB a pop could add up (well, I realize a paper cut but still, it won't look good in task mgr with a virtual size popping up 10-20 MB per).

[OTorg]

Did you do the whole mfxVideoParam structure zeroing before setting its members for Init call?
If not, you could have a garbage at BufferSizeInKB/BRCParamMultiplier in-params, which could lead to your issue.
See somewhat related topic http://software.intel.com/en-us/forums/topic/475633

[Petter_L_Intel]

Hi,

You will not get the selected BufferSizeInKB (assuming the value is set to 0 at Init) unless you call GetVideoParam as illustrated in the Media SDK samples. The selected BufferSizeInKB value depends on the configured bitrate, not resolution.

Please also make sure your configuration parameters are "zeroed" as suggested by dj_alek.

Regards,
Petter 

[ME]

The only thing I may (probably) not have set was the frame rate (as in, it may have been 0).  Anyway, through something that I did it went down to 2100.  This was 480 x 368.  Target was 500 kbps.  Frame rate 30.

I don't follow how this depends on the bitrate (500 kbps), though.  -- OK, I suppose I can since it is encoded data... Right.  But still, 2100 kB (as in more than 2 million bytes) for 500 kbps target?  Is that reasonable?  How is that or do I need to look at this (as in, messed up some setting)?  What buffer size values should I expect to see here, say at 500 kbps, 1 Mbps, and 2 Mbps?  This buffer is used to store only the encoded frame?

[Petter_L_Intel]

Hi,

BufferSizeInKB represents the maximum possible size for an encoded frame. That size is very much dependent on the selected bit rate. If you are using a bitrate of ~500kbps and using VBR you should  be getting a BufferSizeInKB at about 100-200 KB.   

What rate control method are you using?

Keep in mind that MaxBitrate parameter also impacts the result if you are using VBR.

Regards,
Petter
 

[ME]

VBR to answer the question.  I added two png images of a watch window on mfx, one png for before

                  rc = (int)m_mfxEncPtr->GetVideoParam(&m_mfxEncParms);

(bottom call below) and one right after.  I was leaving max kbps and intial delay kb at 0, then changed max to match the target (500) but no change.  I don't 2100 anymore; back to 9375 KB.  This is the software code; the 1.7 package.  The watchi has the uninteresting unions mixed in but you can make it out okay.  It's weird the the initial delay kb matches the buffer.

            rc = (int)m_mfxEncPtr->Init(&m_mfxEncParms);
            if (rc >= 0) {
                  mfxExtBuffer *encExtParmsPtr[1];   //  --- I'm leaving these lines in in case it matters ---
                  mfxExtCodingOptionSPSPPS encExtCodingOptionSPSPPS = {0};
                  encExtCodingOptionSPSPPS.Header.BufferId = MFX_EXTBUFF_CODING_OPTION_SPSPPS;
                  encExtCodingOptionSPSPPS.Header.BufferSz = sizeof(mfxExtCodingOptionSPSPPS);
                  // ...
                  encExtCodingOptionSPSPPS.SPSBuffer = &m_mfxEncSps[0];
                  encExtCodingOptionSPSPPS.PPSBuffer = &m_mfxEncPps[0];
                  encExtCodingOptionSPSPPS.SPSBufSize = sizeof(m_mfxEncSps);  // 160
                  encExtCodingOptionSPSPPS.PPSBufSize = sizeof(m_mfxEncPps);  // 16
                  encExtParmsPtr[0] = (mfxExtBuffer*)&encExtCodingOptionSPSPPS;
                  m_mfxEncParms.ExtParam = &encExtParmsPtr[0];
                  m_mfxEncParms.NumExtParam = 1;
                  // --
                  rc = (int)m_mfxEncPtr->GetVideoParam(&m_mfxEncParms);

And the two pngs attached.  Should be.  It does not look like the uploads made it.  Or I doubled them.  The pics tell the story.

[ME]

Here are the pics on imageshack.

Before:

http://imageshack.com/a/img32/2565/ibqr.png

After:

http://imageshack.com/a/img440/8811/ux9v.png

[ME]

One more thing.  I mentioned that originally I was leaving MaxKbps 0 (along with InitialDelayKB) which I believe is fine from the docs, but then set it to the same as TargetKbps (500) thinking it might help the 9.3 MB returned buffer size.  I still got the 9.3 MB buffer size with MaxKbps same as the target, but what I get (as before; forget to mention this), is  60000 kB  for MaxKbps after the encoder Init() / GetVideoParam().

Before:        
        MaxKbps    0x0000    unsigned short
             

After:                     
      MaxKbps  0xea60   unsigned short

Everything else the same.  The only change is setting MaxKbps to 0 (leaving it at 0) before doing the encoder init.  When MaxKbps was set to 500, it stayed 500.  When 0, it returned from GetVideoParam() as 60000.

[Petter_L_Intel]

Hi,

I looked at this again and I now realize that you are using the SW encoder. Right?   I do not see this behavior using HW encoder with the exact same configuration, but I do see it using SW encoder. At first glance this seems to be a corner case or possibly a bug, since if I change the TargetUsage setting to any value less than 7 (speed), the BufferSizeInKB value comes out as reasonable, ~300KB.

I'm awaiting some specific feedback on this topic from H.264 encoder expert. I'll update the post again shortly.

Regards,
Petter

[Petter_L_Intel]

Hi again,

I got confirmation that for this specific case, the "large" buffer size value is the expected behavior. You can either change the encoder configuration to an alternate config resulting in a smaller buffer, or.. manually set the BufferSizeInKB to a smaller value before calling Init() . That approach will likely work for most scenarios. If you do happen to encounter a case where the buffer is too small during encoding process, you will get MFX_ERR_NOT_ENOUGH_BUFFER​, and can then allocate a greater buffer size if needed.

Regards,
Petter

[Hiroshi_O_]

Petter,

I am observing the same issue (with MSDK 2014 for Client) and I have follow-up questions to your last reply.

1. I still don't understand why it is "expected" that this value is quite different between software library and hardware acceleration case. Does this mean that the software implementation may generate the output data differently from acceleration case and it may actually exceed the specified maximum bitrate? Or, do you mean that the software implementation uses output buffer for internal operation purpose and that causes more memory consumption than actual output data size?

2. By any chance, could you share with us the formula to calculate this value internally? I do not mean to keep it forever, but I just want to make rough estimation for my code around Media SDK library.

[Petter_L_Intel]

Hi Hiroshi,

the same behavior is expected for the 2014 SDK, no changes in this context were made to the SW encoder.

Yes, the SW and HW encoder have completely separate implementations and the resulting encoded stream will not be equivalent. The SW implementation uses, for this specific configuration, a large default HRD buffer to avoid specific HRD underflow cases. At this time we do not have any plans to modify the SW encoder to change this behavior. Instead please follow the suggestion in my previous post.

I'll investigate if the formula can be shared external. No guarantees. If so, I will share it on this thread.

Regards,
Petter

[Petter_L_Intel]

Hi again,

We cannot share the exact details of the formula, but the following is the overall approach. Media SDK chooses H.264 level based on parameters provided by application (or default value based on resolution etc. of level=0). Then unspecified level-sensitive parameters are set to maximum values for the chosen level by Table A-1 from AVC standard.

As stated earlier, there are some exceptions to this rule, such as the SW codec case discussed earlier in this thread.

Regards,
Petter