`VideoFrame::CopyTo` can do copy in thread pool
Categories
(Core :: Audio/Video: Web Codecs, enhancement)
Tracking
()
People
(Reporter: chunmin, Unassigned)
References
(Blocks 1 open bug)
Details
The performance of the VideoFrame::CopyTo implemented in bug 1774300 can be speeded up by doing the copy in thread pool. As a result, the copy work on different plane can be done in parallel, and the thread where VideoFrame::CopyTo is called won't be blocked.
| Reporter | ||
Comment 1•3 years ago
|
||
From the ownership perspective, it's not perfect to share the destination buffer (the space the copied data is going to be stored) among different threads. But in practice it should be ok since the Compute Layout and Allocation Size makes sure the spaces for different planes are not overlapped.
The safest way is to move all the copy works on for different planes to the same thread so there is no ownership issue and it can unblock the thread where VideoFrame::CopyTo is on. This might be good enough if there is no need to optimize VideoFrame::CopyTo's performance.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 2•1 year ago
|
||
I tried to dispatch the copy tasks in a background task queue today, but it didn't work. Calling ProcessTypedArraysFixed results in a crash by the assertion in ApplyToTypedArrays. Putting tasks in ProcessTypedArraysFixed results another crash (I forget the crash reason). I am not sure if it's possible to dispatch tasks that run ProcessTypedArraysFixed or dispatch tasks within ProcessTypedArraysFixed. I'll ask some JS experts to get a direction on how to do this.
Description
•