The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68b3fab8a62e3e060690a7a0ea89fa6564b2f49f

commit 68b3fab8a62e3e060690a7a0ea89fa6564b2f49f
Author: xhwang <xhwang@chromium.org>
Date: Wed May 17 21:31:46 2017

media: Add Media.UnderflowDuration.EME UMA

Encrypted media playback involves decoding in a different process and
the underflow duration could be much longer than clear media playback.
Adding this UMA to track EME-specific metrics around underflow to help
us understand the current state, and work on improvements.

BUG= 721863 

Review-Url: https://codereview.chromium.org/2885303002
Cr-Commit-Position: refs/heads/master@{#472575}

[modify] https://crrev.com/68b3fab8a62e3e060690a7a0ea89fa6564b2f49f/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/68b3fab8a62e3e060690a7a0ea89fa6564b2f49f/tools/metrics/histograms/histograms.xml

I just measured the IPC overhead of decrypt-and-decode-video calls. On my Macbook Pro, the IPC latency is about 10% of overall decoding time. So if we implement parallel decoding, we can get about 10% improvement in start-to-play time. When the main thread is busier, the IPC overhead will increase and parallel decoding becomes more important, but if we switch to mojo CDM and remove the main thread contention, this won't be a problem. So overall, this is still something to do, but we should really switch to mojo CDM first.

Also, with our no-key-then-retry logic, supporting parallel decoding becomes tricky. For example, after the CDM returns kNoKey, and received another decode-and-decrypt call, it doesn't know whether this is a retry, or the next decode-and-decrypt call. If the latter, the CDM adapter should not call the CDM, otherwise, if the CDM actually has the key for that buffer, we'll skip a buffer (where we trigger no-key), and could cause decoder error. To fix this, we should probably move the no-key-then-retry logic to CdmAdapter, instead of handling it in DecryptingVideoDecoder. This will also be easier after we switch to mojo CDM, where we only have one CdmAdapter to work with.

Deleted: trace_encrypted_playback_seek_performance.json.gz 735 KB

trace_encrypted_playback_seek_performance.json.gz 735 KB Download

This is lower priority and probably not worth the effort. Close this now. We can reopen if it proves to be higher priority.

FWIW, for decrypt-only, since decryption is typically faster, the IPC delay would be more of a problem in the overall throughput, so it might make sense to do parallel decryption for that case.