I need details about MFXVideoENCODE_EncodeFrameAsync's MFX_ERR_NOT_ENOUGH_BUFFER return code. Does it mean "nothing was put to output buffer, need to provide more output space and call MFXVideoENCODE_EncodeFrameAsync again with the same input"?
There are threee documented codes of MFXVideoCORE_SyncOperation: MFX_ERR_NONE, MFX_WRN_IN_EXECUTION and MFX_ERR_ABORTED. But I saw MFX_ERR_UNKNOWN. What actions need to be taken in a such case? How to revert encoder to continue working?
MFXVideoCORE_SyncOperation's MFX_ERR_ABORTED: does it mean "mfxSyncPoint and linked mfxBitstream is no longer used by encoder and mfxBitstream can be reused by application for a subsequent tasks"?
Can MFXJoinSession return codes other than MFX_ERR_NONE/MFX_WRN_IN_EXECUTION/MFX_ERR_UNSUPPORTED (in current and future implementations)? If so, does other MFX_WRN_* mean joined or not?
Can MFXClose return error/warning code if child sessions are absent? Can application safely release resources (passed earlier to MFXVideoENCODE_EncodeFrameAsync/MFXVideoDECODE_DecodeFrameAsync) after MFXClose call?
MFX_ERR_NOT_ENOUGH_BUFFER means nothing was put in output bitstream buffer since there was not enough space to store the encoded frame. Please allocate more space and call MFXVideoENCODE_EncodeFrameAsync with same input again.
If you see MFX_ERR_UNKNOWN you are likely encountering issues with your surface management or the graphics driver you are using is old or inconsistent (there were some graphics driver installer issues in release 3165 causing odd behavior). Please make sure you are using the latest driver available foir your system. Unfortunately MFX_ERR_UNKNOWN is very vague and could indicate both low level driver issues and surface management issues.
MFX_ERR_ABORTED is described in the reference manual chapter named "Pipeline Error Reporting". Syncpoints cannot be reused, they are just handles referring to the requested operation(s).
I'm not aware of any valid return codes from MFXJoinSession. If you encounter any, please let us know.
MFXClose does not have explicit warning mechanisms to report is child sessions are active or not. This is something we may explore in future Media SDK revisions. Is this an important feature to you?
Thank you for first three clarifying answers.
MFXClose/MFXVideoENCODE_Close implementation style is really important to me. If it can (in principle) return an error (except child session presence cause), it complicates the architecture of my modular applications that use imsdk. Consider some COM-object that wraps encoder functionality. Is it enough to make a IUnknown::Release() call to close it, or some Shutdown() method prior call is required, which may result in an error moreover? MFXClose/MFXVideoENCODE_Close error means that I have no rights to free resources which are still somewhere inside encoder (between MFXVideoENCODE_EncodeFrameAsync and MFXVideoCORE_SyncOperation)...
MFXJoinSession behaviour is also important for modular applications. It affects the implementation of certain session_manager_singleton (the idea of the session manager arises from the fact that unmerged sessions significantly degrade performance).
BTW, when I can free resources passed to MFXVideoENCODE_EncodeFrameAsync? After MFXVideoENCODE_Close or MFXVideoENCODE_Close+MFXClose?
Is MFXVideoENCODE_Close call required before MFXClose?
Can session be reused? For example, we create a session, then create decoder and encoder inside it, then transcode some material, then flush, then call MFXVideoDECODE_Close and MFXVideoENCODE_Close (BTW, in what order to close them?). Can we then use that session for other future tasks?
Can mfxFrameSurface1::Info/Data members, except mfxFrameSurface1::Data::Locked, be changed by encoder (somewhere inside MFXVideoENCODE_EncodeFrameAsync...MFXVideoCORE_SyncOperation)?
In other words:
1. Do I need to re-set the descriptive/pointer mfxFrameSurface1 fields before passing it again to subsequent MFXVideoENCODE_EncodeFrameAsync calls (of the same encoder)?
2. Can I use for reading frame pixels that are in the encoding now? E.g., for parallel encoding in multiple formats/bitrates or some other non-imsdk purposes.
The recommended release process is (1) Close Media SDK component (VPP, Encode, Decode), (2) release surface resources (incl. surface headers and tasks), (3) Close session. Note that (1) will be called automatically when MFXVideoSession object is destructed. However, this is not the recommended approach since it does not allow for explicit release of surface resources.
You are not required to close session(3) after performing (1) and (2). It can be reused to setup a new pipeline.
For the encode scenario the mfxFrameSurface1 data object can be safely reused.
Can you expand a bit more on what you mean by "2. Can I use for reading frame pixels that are in the encoding now? E.g., for parallel encoding in multiple formats/bitrates or some other non-imsdk purposes."? If the surface is a sysmem surface there should be no issues accessing it during encode, but it it is a D3D surface you have to heed the normal DirectX surface access mechanisms.
Petter, thank you for your exhaustive explanations.
One question was left alone. Can MFXVideoENCODE_Close/MFXClose potentially results with error? Where should I ask it?
Can you pay attention to another issue? It is here: http://software.intel.com/en-us/forums/topic/475621
Typically both session’s and components’ Close() does not return anything else than OK. But, when session’s are closed the status of join (child’s sessions must be clsoed before parent) is checked. If a session is closed that still have children, close will fail.
Also, invalid memory access issues during close may cause exceptions and in that case will lead to MFX_ERR_UNKNOWN in component/session Close().