Support parallel decryption in DecryptingDemuxerStream |
|
Issue descriptionSee more context in issue 721863 , where we were thinking about doing parallel decoding in DecryptingVideoDecoder, but we ended up not doing it for the complexity and less benefit. But for DecryptingDemuxerStream, it actually makes sense to do it: 1. Decryption is simpler, there's no out-of-order or delayed decryption for example. It's always 1:1 mapping. 2. Decryption is faster, so the IPC overhead is worse. By doing parallel decryption, we should see much more improved throughput. To do so, we can accumulate at most a fixed number (e.g. 4) of DeocderBuffers in DecryptingDemuxerStream(), and decrypt them all in one IPC call.
,
Oct 19
I am not following exactly, could you please elaborate? Thanks!
,
Oct 19
If you wait for N buffers before issuing the decrypt call for those N buffers, your delay for decode will always be dependent on how long it takes to to get N buffers. I.e., if, N-k for 0<k<N, of those buffers are cached in the demuxer and k are not, then the decode of all N bufers is blocked on how long it takes to receive the last k buffers.
,
Oct 22
I see. I was thinking about a model where we'll "try to" fetch N buffers in a best effort manner, then once Decrypt() is called, DDS will start issue decryption of the buffers it currently has immediately, which can be <=N. The details still need to be figured out, but overall I felt this is something that's worth doing. |
|
►
Sign in to add a comment |
|
Comment 1 by dalecur...@chromium.org
, Oct 19