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.

How to make efficient use of async decoding?

dr_asik
Beginner
467 Views

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
Jeffrey_M_Intel1
Employee
467 Views

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

0 Kudos
Nina_K_Intel
Employee
467 Views

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.

Regards,

Nina

0 Kudos
Reply