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
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

How to make efficient use of async decoding?


I'm trying to understand if there's a more efficient of doing things than what I'm doing now. Basing myself on the decode samples, I have a single-threaded model like this:

  • Add data to the bitstream as needed
  • Call DecodeFrameAsync until it returns MFX_ERR_NONE
  • Call SyncOperation on the syncPoint returned by DecodeFrameAsync
  • Enqueue the frame for later use (same thread can used to take the frame and render)

It seems counter-productive to start an asynchronous operation only to wait for its completion immediately after.

So let's imagine a threaded model then:

Thread A (producer):

  • Add data to the bistream as needed
  • Call DecodeFrameAsync until it returns MFX_ERR_NONE
  • Enqueue the frame and its syncPoint
  • Continue while there are available surfaces

Thread B (consumer):

  • Dequeue the next frame and syncPoint
  • Call SyncOperation to obtain the data
  • Wait for more frames to enter the queue

Is this any more performant really? We're still calling SyncOperation the exact same number of times, so we're paying the same synchronisation costs. The only thing I can potentially see is if the queue is usually full and it is large enough, then there is a better chance that the decode will have finished by the time we call SyncOperation. But is this worth the extra complexity and inevitable contention on a queue? Nevermind some kind of polling mechanism for Thread B to detect when frames enter the queue, which isn't free either.

0 Kudos
2 Replies

You've probably seen this already, but the Media SDK Tutorial has a section on efficient decode.  These don't include rendering.  I'm not aware of any data that has been collected on the efficiency of  rendering from the same thread or different threads, but based on other work with Media SDK the decision for how to implement could be informed by Occam's Razor -- the simplest application code often has the best performance.

I agree with your concerns about adding extra complexity.  It seems like multiple threads would add a lot of corner cases, development time, and maintenance costs with relatively minor theoretical benefit. The more complex code may be slower.

Regards, Jeff


Hi dr_asik,

Aysnchronous pipeline, even if designed to work in one thread (e.g. like in sample_encode), does give significant performance benefit. So if your app doesn't require each frame immediately after it's been decoded, then asynchronous pipeline is recommended.