1) "GopPicSize" is used to set distance between I frames.
"GopRefDist" is used to set I and P frames. For instance it it is set to 1 there will be no B frame encoded.
"IdrInterval" is used to specify the frequency of IDR (such as erery I frame, every other I frame etc...)
The Media SDK manual also specifies this behavior in details. If it is still unclear I suggest you experiment with different options to get a better understanding of how this works.
Media SDK also supports manual control of frame type via mfxEncodeCtrl. Please find more info on this topic in the manual.
2) Can you explain a bit more on what you mean? Are you referring to a generated stream or something specified in the SDK documentation?
3) Media SDK handles timestamps transparently. Whatever timestamp is specified as input to encoder (or decoder) is also delivered as the output for that frame. Please make sure you have specified the input time stamp.
2) RegardingMFX_FRAMETYPE_REF, i have observed this in the output bit stream when we encode the raw image into a h264 compressed image (in mfxBitstream ->FrameType) and also I have observed this in the SDK reference manual (version 1.3) example 11,page no 108.
3) Regarding the time stamp, I have set the time stamp in the input stream (mfxFrameSurface1->mfxFrameData->TimeStamp)while encoding the image but I received the output time stamp as zero(in the output mfxBitstream).
Can you please guide me which parameter I should set for the methodEncodeFrameAsync to get a valid timestamp.
2) The frame type selection algorithm in the manual is a simplification. All frames do not have to be a reference frame. For instance, if you specify GopOptFlag to CLOSED and STRICT, a frame at the end of the GOP will not become a reference.
3) You need to call SyncOperation to be able to access the complete compressed data for the frame in the bit stream object. Please refer to the Media SDK encoder sample for an example.
That is certainly odd, this feature does work. What version of Media SDK are you using and are you using HW or SW encode?
I suggest referring back to the Media SDK encode sample code and add setting timestamp on the surface before encode and then verifying that the same timestamp is received in output bit stream after SyncOperation (for the specific task). After you've established that baseline, you can try to replicate similar behavior in your code.
Unfortunately I'm not sure how to resolve your issue.As a sanity check I did verify the timestamp behavior on my side using the Media SDK 2012 release and I do not see any issues. The timestamp is transferred as expected.
Could you please provide the exact set of parameters you used as an input to sample_encode?