VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519
Committed: https://crrev.com/9cbebee523dbd280a4f67ad414a432ed730f241f
Cr-Commit-Position: refs/heads/master@{#11939}

[magjed_webrtc, 2016-03-04 10:00:36]

Patchset #2 (id:20001) has been deleted

[magjed_webrtc, 2016-03-04 10:00:47]

Patchset #1 (id:1) has been deleted

[magjed_webrtc, 2016-03-04 10:51:47]

Description was changed from

==========
VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519
==========

to

==========
VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519
==========

[magjed_webrtc, 2016-03-04 10:51:47]

magjed@webrtc.org changed reviewers:
+ perkj@webrtc.org

[magjed_webrtc, 2016-03-04 10:51:58]

perkj - Please take a look.

[perkj_webrtc, 2016-03-08 15:17:30]

lgtm

[magjed_webrtc, 2016-03-10 08:57:42]

The CQ bit was checked by magjed@webrtc.org

[magjed_webrtc, 2016-03-10 08:57:43]

The patchset sent to the CQ was uploaded after l-g-t-m from perkj@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1763673002/#ps60001 (title:
"Rebase")

[commit-bot: I haz the power, 2016-03-10 08:57:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1763673002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1763673002/60001

[commit-bot: I haz the power, 2016-03-10 10:16:36]

Description was changed from

==========
VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519
==========

to

==========
VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519
==========

[commit-bot: I haz the power, 2016-03-10 10:16:37]

Committed patchset #2 (id:60001)

[commit-bot: I haz the power, 2016-03-10 10:16:43]

Description was changed from

==========
VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519
==========

to

==========
VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session

Currently, VideoCapturerAndroid sets the thread and handler in the ctor
and clears them in dispose(). This CL sets the handler in startCapture()
instead and clears it in stopCapture(). The purpose is to prepare for
sending in the SurfaceTextureHelper in startCapture() instead of letting
VideoCapturerAndroid create it in the ctor.

All access to the handler is now synchronized by a lock, and all
Runnables are posted with a token so that they can be removed all at
once in stopCapture() to guarantee that no pending operation will be
executed after stopCapture().

BUG=webrtc:5519

Committed: https://crrev.com/9cbebee523dbd280a4f67ad414a432ed730f241f
Cr-Commit-Position: refs/heads/master@{#11939}
==========

[commit-bot: I haz the power, 2016-03-10 10:16:44]

Patchset 2 (id:??) landed as
https://crrev.com/9cbebee523dbd280a4f67ad414a432ed730f241f
Cr-Commit-Position: refs/heads/master@{#11939}

[magjed_webrtc, 2016-03-10 12:30:15]

A revert of this CL (patchset #2 id:60001) has been created in
https://codereview.webrtc.org/1777253002/ by magjed@webrtc.org.

The reason for reverting is: Frame rate and freeze detection not working
properly after switchCamera(). This is because the previous cameraObserver is
not removed before posting a new one..