On 3/26/2026 9:25 PM, Caden Chien wrote:
PoC PR "avcodec/decode: new API for batch decoding #22618"
was opened as the implementation of this RFC.
Sorry, I didn't subscribe to the mailing list before sending, so this
RFC email didn't arrive at the same time as the PR was opened. I
subscribed and resent this mail. Please remove previous one in the
moderation queue. Thanks!
This RFC is made up of 5 parts:
* why we need this?
* how we achieve this?
* what would it impact?
* any other existed way to achieve this?
* how can we go even further?
[why we need this?]
For modern hardware, if there are no workloads on the entire SoC, it can
enter sleep mode to save power. When a video is decoded with dedicated
hardware like VCN on GPU, for each frame, it will have a process as:
CPU generates commands for a job -> submit the job -> hardware decodes a
frame and interrupt CPU. To have entire SoC sleeping deep and long,
rather than being waken up frequetly to decode, We would like to batch
several of these processes together.
[...]
However doing it a driver level might not be a good idea, since it's out
of the scope of a driver and introducing surprising behaviors, eventually
causing deadlock when applications trying to synchronize a dmabuf. So
it's more natual to do command batching in Vulkan, fitting the original
purpose of Vulkan that extracting surprising driver specific behaviors
back to developer's hands. While we are investigating further, any comments
on this are welcome.
As Lynne pointed out in the PR, I looked into commit a3823ce "player:
add optional separate video decoding thread" from MPV. The approach to
have an additional queue for decoder to decode into continuously is
indeed similar to our approach. However, we would like to have this
generally available for applications for power optimization.
The same concerns this PoC PR shared with the commit in MPV are slow
seeking and using more memory. My opinion is that it's still up to
developers to decide the size of a batch that won't affect user
experience. And we definitely can help testing if applications
developers need it. For architectural concerns, the newly added
batching is optional and the new execution path is only executed when
batching is enabled. Otherwise the decoding execution path is the same.
Or do we need stronger guarantee like totally separating implementation
of batching into another object file by using new source file?
Thanks,
Caden
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
