tree d846203992c69b891b971bbdfc5e61eec628b819
parent 4262f1f892ea4fed87cc3eb940954039a2aa261d
author tommi <tommi@webrtc.org> 1489490180 -0700
committer Commit bot <commit-bot@chromium.org> 1489490180 +0000

Updates to VCMDecodedFrameCallback, VideoReceiver and a few related classes/tests.

* The _receiveCallback member of VCMDecodedFrameCallback does actually not require locking now that the threading model is slightly clearer. Documentation and checks have been added.
* UserReceiveCallback() never returns null and must always be called on the decoder thread. Checks have been added and the two test suites that were failing to set this callback, have been fixed and a new mock class added.  (looks like sakal@ may have hit some issues with flaky tests there).
* Changed VcmPayloadSink to use move semantics which I suspect was the intention at the time the code was written (when we didn't have move semantics).
* Added thread checker to a couple of classes and started adding thread checks for known behavior.  There's more to be  done there.
* Remove the |_decoder| member variable in VideoReceiver. It is not needed and as it could be used, left us open to a race.
* TODOs added for places where we can reduce locking. I suspect that we can get away with not needing a lock around _codecDataBase in VideoReceiver once we've got a clear picture of the threading model and ensured that all adhere to it.

BUG=webrtc:7328

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