New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 707309 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator

Project Member Reported by emir...@chromium.org, Mar 31 2017

Issue description

We 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
 
Project Member

Comment 1 by bugdroid1@chromium.org, Mar 31 2017

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

commit 7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64
Author: emircan <emircan@chromium.org>
Date: Fri Mar 31 22:10:44 2017

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}

[modify] https://crrev.com/7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64/media/gpu/vt_video_encode_accelerator_mac.cc
[modify] https://crrev.com/7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64/media/gpu/vt_video_encode_accelerator_mac.h

Labels: Merge-Request-58 M-58
Project Member

Comment 3 by sheriffbot@chromium.org, Apr 3 2017

Labels: -Merge-Request-58 Hotlist-Merge-Approved Merge-Approved-58
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
Project Member

Comment 4 by bugdroid1@chromium.org, Apr 3 2017

Labels: -merge-approved-58 merge-merged-3029
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

Status: Fixed (was: Started)
Cc: ranjitkan@chromium.org nisse@chromium.org davidben@chromium.org emir...@chromium.org isheriff@chromium.org pbos@chromium.org sande...@chromium.org sergeyu@chromium.org
 Issue 682443  has been merged into this issue.
Project Member

Comment 7 by bugdroid1@chromium.org, 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

Project Member

Comment 8 by bugdroid1@chromium.org, 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