How does Media SDK Tracer record encoder activities?

[jigong]

When Media SDK Tracer records MSDK sample_encode.exe, it is clear to see that three activities: VPP.RunFrameVPPAsync, encode.EncodeFrameAsync andencode.SyncOperation are recorded in sequential order.

But once using 2 threading in Sample_encode , one thread hold VPP and EncodeFrameAsync, and another one have SyncOperation (AndCEncTaskPool was used to hold encoded frames, andEncodeFrameAsync andSyncOperation have to wait untilmfxSyncPoint not being NULL). In this case, the 3 activities are NOT recorded one by one in Tracer's log. This is normal. But the problem is the valid activites of VPP and EncodeFrameAsync are more than that of SyncOperation. Is it possible for Tracer missing some activities of SyncOperation?

Thank for any advice

Jiuxiang

[Petter_L_Intel]

Hi Jiuxiang,

Let make sure I understand the issue. You are saying SyncOperation is executed in your code but the call does not show up in the Media SDK tracer log?

We are not aware of such issue with the Media SDK tracer.

Could you make sure the sync part of the code is actually executed by adding manual trace in application?

Regards,

Petter

[jigong]

Hi Petter,

Thank you for your reply. Yes, I counted the number of VPP, EncodeFrameAsync and SyncOperation in Tracer log file. Normally, 12 VPP+EncodeFrameAsync appear first, then 12 SyncOperation follow (since 12 task buffers are used). But sometimes 15 VPP+EncodeFrameAsyn continue to show up, but only 3 SyncOperations follow. On another hand, EncodeFrameAsync has to wait for SyncOperation to free mfxSynPoint in our application.

Another problem is that SyncOperation took 70 ms to be done occasionally, (23 ms in normal).

Could you give me some instructions how to add manual trace in application?

Thanks.

Jiuxiang

[Petter_L_Intel]

Hi Jiuxiang,

Less SyncOperation calls in the beginning of encoder operation may be perfectly normal. For instance if the encoder buffers frames (MFX_ERR_MORE_DATA) there is no point in calling SyncOperation. Also, as in the case of sample_encode, SyncOperation will not be called until all surface buffers have been used.

That said, it hard to say what may be going on without knowing the full sequence of events. If possible could you please supply a Media SDK trace log (with per frame logging enabled).

Sorry for not being clear, what I meant my manual tracing was just simply to add "printf" next to SyncOperation in the application. This to make sure that Media SDK tracer does not miss any calls (it should not...)

Regards,

Petter

[jigong]

Hi Petter,

I got it.Thanks.

Please see the following code for me to measure the execution time of SyncOperation.

unsigned int starttick = GetTickCount();

sts = m_mfxSession.SyncOperation(pCurrentTask->EncSyncP, MSDK_WAIT_INTERVAL);

unsigned int stoptick = GetTickCount();

syncTime = stoptick - starttick;

In Sample_encode, the time is 0 ms. But in my application, it cost average 20ms, max can be 180ms. Media SDK reference explains that SyncOperation initiates execution of an asynchronous function not already started. My questions are: what SyncOperation does? Does it start to transport mfxbitstream from video memory to system memory once hardware acceleration is used?

Thanks.

Jiuxiang

[Petter_L_Intel]

Hi Jiuxiang,

SyncOperation just waits for the operation associated with the syncpoint to complete. If the operation is far down the MSDK scheduler queue due to many submitted asynchronous operations there may be a longer delay before SyncOperation returns. This may be the reason you're encountering longer delays.

SyncOperation does not actively retrieve the encoded bitstream or surface, it just waits for the asynchronous operation to complete, meaning that the data is then available in the target buffer (sysmem or D3D).

Also keep in mind that GetTickCount is quite inaccurate when used to measure sub ~30ms intervals. You may instead try to use QueryPerformanceCounter for greater accuracy.

Regards,

Petter

[jigong]

Hi Petter,

Thank you very much for your valuable suggestion.

Jiuxiang