Move GpuMemoryBuffer upload stage earlier in pipeline.
This introduces GpuMemoryBufferDecoderWrapper which is used to wrap software VideoDecoder implementations. The wrapper copies frames as they are returned from the decoder, but before they are delivered to the renderer. This is an improvement over the current copy done by VideoRendererImpl because the VideoFrameStream (which sits between the renderer and the decoder) may hold undelivered frames until a subsequent Read(). At which point the frame still needs to be copied. Total reduction in read times is ~12.6% (VP9) to ~30.1% (H264) after 4000 frames when tested using local caches of: https://www.youtube.com/watch?v=1La4QzGeaaQ (4K60 VP9) https://www.youtube.com/watch?v=dEaSepKi9SQ (4K60 H264) The real benefit of this approach will come later when we allow parallel decodes for offloaded decoders; since these decoders may accumulate more frames in the decoder stream without this approach. This also allows us to remove a bit of code and specialized tests from the VideoRendererImpl in favor of more compartmentalized tests just for the wrapper. The downside to this approach is each decoder has it's own pool, but this only amounts to ~240 bytes of memory when no frames have been created. Perf bots may detect a memory increase from this change, but only as an artifact of improved throughput and timing changes. BUG=801245 TEST=new unittests, manual tests. Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: Iac5655c9da3e850818f9de83cb2993358fcbd716 Reviewed-on: https://chromium-review.googlesource.com/947383 Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Reviewed-by:Daniele Castagna <dcastagna@chromium.org> Cr-Commit-Position: refs/heads/master@{#541284}
Showing
This diff is collapsed.
Please register or sign in to comment