[Linux] Use zero-copy video playback with fallback to surface copy
Categories
(Core :: Audio/Video: Playback, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox111 | --- | fixed |
People
(Reporter: stransky, Assigned: stransky)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
(deleted),
text/x-phabricator-request
|
Details |
Bug 1809162 switches to video frames copy. Implement zero-copy video playback according to available surfaces.
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 1•2 years ago
|
||
Implement dynamic frame copy / zero copy during VA-API playback.
Run with zero copy and switch to frame copy when rendering pipeline is slow and vice versa.
|
||
Comment 2•2 years ago
|
||
Sounds nice.
Could you share performance numbers without and with the patch?
|
|
Assignee | |
Comment 3•2 years ago
|
||
(In reply to Paul Menzel from comment #2)
Sounds nice.
Could you share performance numbers without and with the patch?
I don't think it has visible performance benefits. If we copy surfaces we do that on GPU and copied data size may not be significant.
But this is more a stability fix - we do zero copy by default since first VA-API implementation but if there's any problem in rendering queue and we're running out of free ffmpeg frames, we start to copy them ale return to ffmpeg ASAP (instead of HW decode failure). It means the VA-API playback is more robust and avoids switch to SW decode in such case.
|
|
Assignee | |
Comment 4•2 years ago
|
||
The bug title is a bit misleading - will update it.
|
|
Assignee | |
Updated•2 years ago
|
|
|
||
Comment 6•2 years ago
|
||
Thank you so much for the clarification. (Maybe the commit message summary/title could also be updated.) Thank you again for your amazing work.
|
||
Comment 7•2 years ago
|
||
| bugherder | ||
Description
•