Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
Announcements
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.
3056 Discussions

How does Media SDK Tracer record encoder activities?

jigong
Beginner
479 Views
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
0 Kudos
6 Replies
Petter_L_Intel
Employee
479 Views
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
0 Kudos
jigong
Beginner
479 Views
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
0 Kudos
Petter_L_Intel
Employee
479 Views
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
0 Kudos
jigong
Beginner
479 Views
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
0 Kudos
Petter_L_Intel
Employee
479 Views
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
0 Kudos
jigong
Beginner
479 Views
Hi Petter,
Thank you very much for your valuable suggestion.
Jiuxiang
0 Kudos
Reply