As adding to one of my old posts about framerate parameter during initialization ofEncoder in general, that it has limit of 172 fps, experimenting with different cameras I found that software accelerated Encoder has unstable behavior when it runs at higher frameratethan 216.6fps.
MFXVideoENCODE_EncodeFrameAsync returns status as MFX_ERR_NONE, but MFXVideoCORE_SyncOperation returns MFX_ERR_UNKNOWNfor first 50-100 frames and than MFX_ERR_MEMORY_ALLOC. Sometimes also MFX_ERR_ABORTED, but it happens only once or twice.
It seems that the software accelerated encoder internally cannot handle it in most cases and as a consequence itruns out of memory. But sometimes it can.
This does sound like a memory issue, but if it is working when framerate is <216.6 fps it may indicate a limitation in our code.
Iam curious, do you see a problem when encoding with either CBR or VBR rate control methods (instead of CQP)?
Based on some variables I recall from your previous question (about 172fps limit), I can imagine one CQP algorithm 'might' have a limit, though I need to look at this further.
To help me correctly replicate this, can you verify the following?
- Is this seen wen using command-line sample application? or are you using a media framework (like DirectShow?)
- What OS (Win7 64-bit or 32-bit)?
- If 64-bit OS, is application 64-bit or 32-bit?
(We've seen more memory issues with 32-bit applications)
- Is the behavior different when HW Encode is used (if you have a platform that contains Intel Quick Sync Video capability)?
- Can you provide your init parameters ?
I'm not using DirectShow, and not using sample applications, I'm just using standard API fromIntel Media SDKimplemented in my application.
Encoder works also not stable when CBR or VBR used.
- Windows 7 32 bit
- As I told: the behaviour of the encoder when HW Encoder used is stable.
The parameters are as follows:
mfx.CodecLevel = 0
mfx.CodecProfile = MFX_PROFILE_AVC_BASELINE or any other
mfx.CodecId = MFX_CODEC_AVC
mfx.GopPicSize = it depends onconfiguration
mfx.GopRefDist = 1
mfx.GopOptFlag = MFX_GOP_STRICT
mfx.IdrInterval = 0
mfx.TargetUsage = (fps>50.0)? MFX_TARGETUSAGE_BEST_SPEED : MFX_TARGETUSAGE_BALANCED
mfx.EncodedOrder = 1
mfx.RateControlMethod = MFX_RATECONTROL_CQP
mfx.QPI = 25
mfx.QPP = 26
mfx.QPB = 31
mfx.FrameInfo.FourCC = MFX_FOURCC_NV12
mfx.FrameInfo.Width = depends on camera
mfx.FrameInfo.Height = depends on camera
mfx.FrameInfo.FrameRateExtN = depends onconfiguration
mfx.FrameInfo.FrameRateExtD = 1
mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_PROGRESSIVE
mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420
IOPattern = MFX_IOPATTERN_IN_SYSTEM_MEMORY
It appears that this simply limitation on fps of our algorithm. I've suggested adding support for higher frame rates, however this is not currently a committed feature.
If I happen to discover any easy workarounds to support this usage model, I will update this thread.
It could be. I also thought that the bug fix has eliminate this issue.
Concerning 172 fps limitation during initialization, as you said the framerate used by encoder for bitrate control, so actuallyI dont have to worry about this issueI suppose.