Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator |
||||||
Issue descriptionWe should set this variable to make sure that we do not start HW encode when the delay is going to be longer than ~90 ms. See below for a simulcast-like use case when this was a problem. https://bugs.chromium.org/p/webrtc/issues/detail?id=7304#c11
,
Apr 3 2017
,
Apr 3 2017
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2702ea80726ccc5647abb885927c4e23dd6ff118 commit 2702ea80726ccc5647abb885927c4e23dd6ff118 Author: emircan <emircan@chromium.org> Date: Mon Apr 03 18:01:13 2017 Merge 58: Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups This CL makes sure that we create a HW encoder session only when MaxFrameDelayCount can be set. In case of multiple video streams, Video Toolbox can set this variable up to 8, which results in a ~240 ms delay. We should just fall back to SW in those cases. Additional cleanups: - Remove the unused buffer pool attributes. - Since MaxFrameDelayCount can only be set when RequireHardwareAcceleratedVideoEncoder works, remove the other fallback logic. BUG= 707309 TEST=Demo trying resolutions scaling down https://jsfiddle.net/emircan/jhonduk5/. 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 Review-Url: https://codereview.chromium.org/2791733002 Cr-Commit-Position: refs/heads/master@{#461245} (cherry picked from commit 7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64) NOTRY=true NOPRESUBMIT=true TBR=sandersd@chromium.org Review-Url: https://codereview.chromium.org/2790063003 Cr-Commit-Position: refs/branch-heads/3029@{#551} Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471} [modify] https://crrev.com/2702ea80726ccc5647abb885927c4e23dd6ff118/media/gpu/vt_video_encode_accelerator_mac.cc [modify] https://crrev.com/2702ea80726ccc5647abb885927c4e23dd6ff118/media/gpu/vt_video_encode_accelerator_mac.h
,
Apr 3 2017
,
Apr 3 2017
Issue 682443 has been merged into this issue.
,
Apr 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7e6cf6cadac69de4d9c38b71dee1947792ab15d6 commit 7e6cf6cadac69de4d9c38b71dee1947792ab15d6 Author: guidou <guidou@chromium.org> Date: Wed Apr 05 13:39:39 2017 Revert of Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups (patchset #1 id:1 of https://codereview.chromium.org/2791733002/ ) Reason for revert: Speculative revert. Possibly breaks WebRTC Mac FYI bots. Will reland if the revert does not fix the bots. Original issue's description: > Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups > > This CL makes sure that we create a HW encoder session only when > MaxFrameDelayCount can be set. In case of multiple video streams, Video > Toolbox can set this variable up to 8, which results in a ~240 ms delay. We > should just fall back to SW in those cases. > Additional cleanups: > - Remove the unused buffer pool attributes. > - Since MaxFrameDelayCount can only be set when > RequireHardwareAcceleratedVideoEncoder works, remove the other fallback > logic. > > BUG= 707309 > TEST=Demo trying resolutions scaling down https://jsfiddle.net/emircan/jhonduk5/. > 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 > > Review-Url: https://codereview.chromium.org/2791733002 > Cr-Commit-Position: refs/heads/master@{#461245} > Committed: https://chromium.googlesource.com/chromium/src/+/7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64 TBR=sandersd@chromium.org,emircan@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 707309 Review-Url: https://codereview.chromium.org/2802673002 Cr-Commit-Position: refs/heads/master@{#462053} [modify] https://crrev.com/7e6cf6cadac69de4d9c38b71dee1947792ab15d6/media/gpu/vt_video_encode_accelerator_mac.cc [modify] https://crrev.com/7e6cf6cadac69de4d9c38b71dee1947792ab15d6/media/gpu/vt_video_encode_accelerator_mac.h
,
Apr 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/882f01ad7ceb6c3c82a8bfa8dcf4982abb7d63d4 commit 882f01ad7ceb6c3c82a8bfa8dcf4982abb7d63d4 Author: emircan <emircan@chromium.org> Date: Thu Apr 06 19:16:59 2017 Reland of Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups (patchset #1 id:1 of https://codereview.chromium.org/2802673002/ ) Reason for revert: Reland after the MediaRecorder problem is addressed on https://bugs.chromium.org/p/chromium/issues/detail?id=676424#c3. Original issue's description: > Revert of Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups (patchset #1 id:1 of https://codereview.chromium.org/2791733002/ ) > > Reason for revert: > Speculative revert. > Possibly breaks WebRTC Mac FYI bots. > Will reland if the revert does not fix the bots. > > Original issue's description: > > Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups > > > > This CL makes sure that we create a HW encoder session only when > > MaxFrameDelayCount can be set. In case of multiple video streams, Video > > Toolbox can set this variable up to 8, which results in a ~240 ms delay. We > > should just fall back to SW in those cases. > > Additional cleanups: > > - Remove the unused buffer pool attributes. > > - Since MaxFrameDelayCount can only be set when > > RequireHardwareAcceleratedVideoEncoder works, remove the other fallback > > logic. > > > > BUG= 707309 > > TEST=Demo trying resolutions scaling down https://jsfiddle.net/emircan/jhonduk5/. > > 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 > > > > Review-Url: https://codereview.chromium.org/2791733002 > > Cr-Commit-Position: refs/heads/master@{#461245} > > Committed: https://chromium.googlesource.com/chromium/src/+/7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64 > > TBR=sandersd@chromium.org,emircan@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG= 707309 > > Review-Url: https://codereview.chromium.org/2802673002 > Cr-Commit-Position: refs/heads/master@{#462053} > Committed: https://chromium.googlesource.com/chromium/src/+/7e6cf6cadac69de4d9c38b71dee1947792ab15d6 TBR=sandersd@chromium.org,guidou@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 707309 Review-Url: https://codereview.chromium.org/2803673004 Cr-Commit-Position: refs/heads/master@{#462576} [modify] https://crrev.com/882f01ad7ceb6c3c82a8bfa8dcf4982abb7d63d4/media/gpu/vt_video_encode_accelerator_mac.cc [modify] https://crrev.com/882f01ad7ceb6c3c82a8bfa8dcf4982abb7d63d4/media/gpu/vt_video_encode_accelerator_mac.h |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by bugdroid1@chromium.org
, Mar 31 2017