Optimistically aiming for M53

Less optimistically aiming for M54. :)

Are you still optimistic for M54 or certain? ;)

...

It didn't make it into M55 so moving to M56.

https://codereview.chromium.org/2440113002/ has landed, awaiting webrtc roll into chrome.

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

commit ae101afbcb955c6efbbf27bebf81334b95659c11
Author: sprang <sprang@chromium.org>
Date: Wed Oct 26 14:39:08 2016

Roll OpenH264 from v1.4.1 to v1.6.0

BUG= chromium:614970 

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

[modify] https://crrev.com/ae101afbcb955c6efbbf27bebf81334b95659c11/DEPS
[modify] https://crrev.com/ae101afbcb955c6efbbf27bebf81334b95659c11/content/renderer/media/video_track_recorder.cc
[modify] https://crrev.com/ae101afbcb955c6efbbf27bebf81334b95659c11/third_party/openh264/BUILD.gn
[modify] https://crrev.com/ae101afbcb955c6efbbf27bebf81334b95659c11/third_party/openh264/README.chromium

@sprang i think i saw this got reverted due to some performance reasons?  can you share anything about the results?  i'd be interested to hear what was found.

@sprang did a bit more testing today and saw some issues that may match what you saw in the tests, not sure why i didn't see it before.

looks like setting SM_FIXEDSLCNUM_SLICE alone without explicitly setting uiSliceNum (to something other than 0) might causing problems.  openh264 will set the slice number based on the number of cores (which it detects on its own) but webrtc is hard-coding the number of threads (typically based on num cores) to 1.  i saw better results by using either SM_SINGLE_SLICE here or using SM_FIXEDSLCNUM_SLICE and explicitly setting uiSliceNum to 1 in webrtc.

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

commit 81bedff4d32896e3aa6b18f187d75ac16f19bc00
Author: sprang <sprang@chromium.org>
Date: Mon Oct 31 09:03:12 2016

Revert of Roll OpenH264 from v1.4.1 to v1.6.0 (patchset #5 id:80001 of https://codereview.chromium.org/2440143002/ )

Reason for revert:
Causing perf regression in webrtc.

Original issue's description:
> Roll OpenH264 from v1.4.1 to v1.6.0
>
> BUG= chromium:614970 
>
> Committed: https://crrev.com/ae101afbcb955c6efbbf27bebf81334b95659c11
> Cr-Commit-Position: refs/heads/master@{#427688}

TBR=mcasas@chromium.org,hbos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= chromium:614970 

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

[modify] https://crrev.com/81bedff4d32896e3aa6b18f187d75ac16f19bc00/DEPS
[modify] https://crrev.com/81bedff4d32896e3aa6b18f187d75ac16f19bc00/content/renderer/media/video_track_recorder.cc
[modify] https://crrev.com/81bedff4d32896e3aa6b18f187d75ac16f19bc00/third_party/openh264/BUILD.gn
[modify] https://crrev.com/81bedff4d32896e3aa6b18f187d75ac16f19bc00/third_party/openh264/README.chromium

Reopened.

brian@, yes the rate controller seems have problems with uiSliceNum > 1. I though at first it was just the fact that uiSliceNum was larger than iMultipleThreadIdc (which we have hard-coded to 1 because of other issues), but it seems that even with both of them set to 4 for instance, I get the same issues. 
Looks like there is some race when updating incoming framerate. I've seen debug messages warning that incoming frame rate is 120000fps, so the assigned bits/frame got kinda low...
Should file a bug for this with OpenH264.

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

commit 3c3e253cdc8ee3cde7b76c80e205eb3f86eae833
Author: sprang <sprang@chromium.org>
Date: Mon Nov 07 17:03:13 2016

Roll OpenH264 from v1.4.1 to v1.6.0

Second take.
Previous attempt (https://codereview.chromium.org/2440143002) caused
quality regressions. sSpatialLayers[0].sSliceArgument.uiSliceNum = 1 is
the workaround for now.

BUG= chromium:614970 

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

[modify] https://crrev.com/3c3e253cdc8ee3cde7b76c80e205eb3f86eae833/DEPS
[modify] https://crrev.com/3c3e253cdc8ee3cde7b76c80e205eb3f86eae833/content/renderer/media/video_track_recorder.cc
[modify] https://crrev.com/3c3e253cdc8ee3cde7b76c80e205eb3f86eae833/third_party/openh264/BUILD.gn
[modify] https://crrev.com/3c3e253cdc8ee3cde7b76c80e205eb3f86eae833/third_party/openh264/README.chromium

Is this finished? Will it make it into M56 (branch point on NOv16)?

This seems to be sticking this time, so I'll mark it as fixed.

Marking as Verified - H264 loopback and p2p calls looks good!

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/10418acb9790a82aa8f8368c8d6ba2459747149b

commit 10418acb9790a82aa8f8368c8d6ba2459747149b
Author: sprang <sprang@webrtc.org>
Date: Wed Jan 11 13:51:56 2017

Remove backwards compatibilty path for OpenH264 v1.4

Deps have rolled to 1.6, and since no one noticed that the old code path
was broken and wouldn't even compile, I assume no one is using it.
I therefore deem it time to clean away all these nasty ifdefs.

("const kNalHeaderSizeAllocation = 50;" doesn't declare a type)

BUG= chromium:614970 

Review-Url: https://codereview.webrtc.org/2622233002
Cr-Commit-Position: refs/heads/master@{#16008}

[modify] https://crrev.com/10418acb9790a82aa8f8368c8d6ba2459747149b/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc