Media (Intel® oneAPI 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

EncodeFrameAsync takes too long (?)


Hello Support team,

I wrote a small test program that use the Media Sever Studio SDK to encode 'video stream' 1024 x 768 pixels into H264.
The program actually renders a rotating line every 30mS into the frame buffer, reading it back
into system memory and send it to the SDK to encode it.
The encoding process is done in a different task that the rendering task.
Until I get the platform with Intel GPU, I run the SDK in SW implementation.
I took the 'sample_encode' program distributed with the SDK and made few
adaptations in the program to accept frames injected by the user and not read from a file.
I synchronize the encoder when a frame is valid.
The h264 encoded file is perfect, but the disturbing phenomena is that the rotating
line is not smooth. It gets stucked rondomaly from time to time (every few seconds).
After invistigating the root cause, the 'blame' fell on the MFXVideoENCODE::EncodeFrameAsync function.
Most of the time it takes around 7 to 10mS ro run, but sometimes it takes few hundred miliseconds (sometimes up
to 1 second!). I Measure the time by inserting 'SyncOperation' call, to make the encoding complete.
More strange is the fact that, running the encoder with no connection to the rendering task (encoding same frame over
and over) cause the rendering to get stucked as if the encoder use resources of the rendering task.
I tried different settings of the command line parameters with no success.
It looks like the encoding process works very hard on some frames...
My question is:
Is it a normal behavior in the compresion process? Is it only in the SW implementation?
Should I spend more effort on the issue, or leave it until I get the HW and run it with HW

Many thanks,




0 Kudos
1 Reply

Hi Joseph,

As far as I know, the Media SDK software implementation doesn't focus on predictable latency.  It is a very different implementation internally than the hardware h264 version.  If your goal is hardware accelerated h264 it is probably best to wait on your analysis until you can test the hardware implementation.

0 Kudos