Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups

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

[emircan, 2017-03-31 20:59:51]

Description was changed from

==========
Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups

BUG=707309
==========

to

==========
Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups

BUG=707309
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
==========

[emircan, 2017-03-31 21:00:39]

The CQ bit was checked by emircan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-31 21:01:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[emircan, 2017-03-31 21:07:23]

Description was changed from

==========
Enforce MaxFrameDelayCount in VTVideoEncodeAccelerator and cleanups

BUG=707309
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
==========

to

==========
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
==========

[emircan, 2017-03-31 21:07:23]

emircan@chromium.org changed reviewers:
+ sandersd@chromium.org

[emircan, 2017-03-31 21:09:06]

PTAL.

[sandersd (OOO until July 31), 2017-03-31 21:10:50]

lgtm

[emircan, 2017-03-31 22:04:06]

The CQ bit was unchecked by emircan@chromium.org

[emircan, 2017-03-31 22:04:07]

The CQ bit was checked by emircan@chromium.org

[commit-bot: I haz the power, 2017-03-31 22:04:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-31 22:10:48]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1490997847006080, "parent_rev":
"cc16b8ab7df17b1462d98640d6dd8cb1ccd2dbce", "commit_rev":
"7cfd3f9eb9dd016c64853f1ae8af84980f9d6f64"}

[commit-bot: I haz the power, 2017-03-31 22:11:43]

Description was changed from

==========
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
==========

to

==========
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/+/7cfd3f9eb9dd016c64853f1ae8af...
==========

[commit-bot: I haz the power, 2017-03-31 22:11:44]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/7cfd3f9eb9dd016c64853f1ae8af...

[Guido Urdaneta, 2017-04-05 12:39:49]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/2802673002/ by guidou@chromium.org.

The reason for reverting is: Speculative revert.
Possibly breaks WebRTC Mac FYI bots.
Will reland if the revert does not fix the bots..

[Guido Urdaneta, 2017-04-05 15:52:32]

The revert did fix the bots.

[Guido Urdaneta, 2017-04-05 15:53:28]

On 2017/04/05 15:52:32, Guido Urdaneta wrote:
> The revert did fix the bots.

Sample failed run:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/66661

[emircan, 2017-04-05 18:46:03]

I just reproed locally and went through this problem. With this change, we are
limited to having only one HW encode session in macbooks(and I guess macmini
where these bots run), as only one HW encoder is allowed to set
kVTCompressionPropertyKey_MaxFrameDelayCount property. This is the intended
behavior. These tests fail because MediaRecorder cannot handle not opening a Hw
encode session. So, my next steps would be:
- Reland this CL.
- Write a SW fallback mechanism for VideoTrackRecorder::VEAEncoder as we don't
handle Initialize() failure there.

[emircan, 2017-04-05 19:37:07]

Patchset #2 (id:20001) has been deleted