AppRTCDemo: Render each video in a separate SurfaceView

AppRTCDemo: Render each video in a separate SurfaceView

This CL introduces a new org.webrtc.VideoRenderer.Callbacks implementation called SurfaceViewRenderer that renders each video stream in its own SurfaceView. AppRTCDemo is updated to use this new rendering.

This CL also does the following changes:
* Make the VideoRenderer.Callbacks interface asynchronous and require that renderFrameDone() is called for every renderFrame(). In JNI, this is implemented with cricket::VideoFrame::Copy()/delete.
* Make public static helper functions: convertScalingTypeToVisibleFraction(), getDisplaySize(), and getTextureMatrix().
* Introduces new helper functions surfaceWidth()/surfaceHeight() in EGlBase that allows to query the surface size.
* Introduce PercentFrameLayout that implements the percentage layout that is used by AppRTCDemo.

BUG=webrtc:4742
Committed: https://crrev.com/05bfbe47ef6bcc9ca731c0fa0d5cd15a4f21e93f
Cr-Commit-Position: refs/heads/master@{#9699}

[magjed_webrtc, 2015-08-03 17:47:19]

magjed@webrtc.org changed reviewers:
+ glaznev@webrtc.org, wzh@webrtc.org

[magjed_webrtc, 2015-08-03 17:48:55]

Please take a look.

[AlexG, 2015-08-04 00:27:23]

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/EglBase.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/EglBase.java:131: final int widthArr[] =
new int[1];
nit: widthArr -> widthArray?

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/EglBase.java:137: final int heightArr[]
= new int[1];
dito: heightArr -> heightArray?

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:149:
renderThread.quitSafely();
use quit() here to reduce exit latency - we don't need to wait for pending frame
rendering complete.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:184:
synchronized (layoutLock) {
Do you think it's worth skip rendering of the frame until layout change is done?
I am worried about some corner cases when camera is running at low fps due to
high load or application is paused and the last frame is displayed when
application is in background - for these cases the last rendered may stick for
some time and may have incorrect layout.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
File talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java:105: private
I420Frame(I420Frame source) {
This implementation will do frame memory allocation / freeing for every rendered
frame - right? We may have 30 huge memory allocs/deallocs every second. I am not
sure, but I am afraid it may cause heap fragmentation. Why not to use one time
allocation and then VideoRenderer.copyFrom() instead of multiple allocations?
Plus it will keep I420Frame interface easier with less amount of constructors /
extra param.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java:126: public void
release() {
I would add a flag here to avoid accidental case if I420Frame comes from C++ (in
RenderFrame()), shallow copy is not created, but I420Frame.release() is called
to avoid accidental freeing of C++ memory from Java. Overall interface looks not
very clear for me though - for some I420 frames we should call release(), for
another - not.

https://codereview.webrtc.org/1257043004/diff/1/talk/examples/android/src/org...
File talk/examples/android/src/org/appspot/apprtc/CallActivity.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/examples/android/src/org...
talk/examples/android/src/org/appspot/apprtc/CallActivity.java:262:
localRender.postDelayed(new Runnable() {
nit: this was probably not the best way from the beginning, now it looks a
little strange why we are posting disconnect() request to local renderer - may
be use:
(new Handler()).postDelayed(...) here?

https://codereview.webrtc.org/1257043004/diff/1/talk/examples/android/src/org...
talk/examples/android/src/org/appspot/apprtc/CallActivity.java:345:
remoteRenderLayout.setPosition(REMOTE_X, REMOTE_Y, REMOTE_WIDTH, REMOTE_HEIGHT);
Could it cause race condition when say position is updated, but scaling type is
not and renderer thread will render frame with updated position, but not updated
scaling. May be merge all layout specific set function into one set function
with one parameter structure containing position, mirror and scaling type
fields?

[magjed_webrtc, 2015-08-04 17:05:05]

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/EglBase.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/EglBase.java:131: final int widthArr[] =
new int[1];
On 2015/08/04 00:27:23, AlexG wrote:
> nit: widthArr -> widthArray?

Done.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/EglBase.java:137: final int heightArr[]
= new int[1];
On 2015/08/04 00:27:23, AlexG wrote:
> dito: heightArr -> heightArray?

Done.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:149:
renderThread.quitSafely();
On 2015/08/04 00:27:23, AlexG wrote:
> use quit() here to reduce exit latency - we don't need to wait for pending
frame
> rendering complete.

I want to make sure that the EGL/GL cleanup posted above is executed. I'm
stopping renderFrame() from posting any more frames by setting
|renderThreadHandler| to null and then releasing |pendingFrame|. So in those
cases, renderFrameOnRenderThread() will return immediately and there won't be
any extra latency.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:184:
synchronized (layoutLock) {
On 2015/08/04 00:27:23, AlexG wrote:
> Do you think it's worth skip rendering of the frame until layout change is
done?
> I am worried about some corner cases when camera is running at low fps due to
> high load or application is paused and the last frame is displayed when
> application is in background - for these cases the last rendered may stick for
> some time and may have incorrect layout.

Do you mean dropping the frame or delay renderFrameOnRenderThread() until layout
change is done? One problem is that I don't know of any good way to get notified
when layout change is done. onSizeChanged() is not guaranteed to get called
after requestLayout(), so we could get stuck with a pending frame that will
never be rendered. onLayout() might get called several times during the layout
process, so I don't think it's a good place either. onDraw() is not called at
all for SurfaceViews.

Also, this requestLayout() is typically only triggered by an orientation change
so it's an uncommon corner case.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
File talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java:105: private
I420Frame(I420Frame source) {
On 2015/08/04 00:27:23, AlexG wrote:
> This implementation will do frame memory allocation / freeing for every
rendered
> frame - right? We may have 30 huge memory allocs/deallocs every second. I am
not
> sure, but I am afraid it may cause heap fragmentation. Why not to use one time
> allocation and then VideoRenderer.copyFrom() instead of multiple allocations?
> Plus it will keep I420Frame interface easier with less amount of constructors
/
> extra param.

It will not allocate or copy the pixel data, it will just allocate and assign
some pointers and header data, i.e. ~100 byte per frame including
cricket::WebRtcVideoFrame in C++. Anyway, I removed all this, see next comment.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java:126: public void
release() {
On 2015/08/04 00:27:23, AlexG wrote:
> I would add a flag here to avoid accidental case if I420Frame comes from C++
(in
> RenderFrame()), shallow copy is not created, but I420Frame.release() is called
> to avoid accidental freeing of C++ memory from Java. Overall interface looks
not
> very clear for me though - for some I420 frames we should call release(), for
> another - not.

Ok, how about this interface instead; for every call to renderFrame(), the
callee is responsible for calling static VideoRenderer.renderFrameDone(frame) to
signal that rendering is done. This return call is allowed to take place after
renderFrame() has returned, making async rendering possible. I have updated the
CL to this interface instead. What do you think?

https://codereview.webrtc.org/1257043004/diff/1/talk/examples/android/src/org...
File talk/examples/android/src/org/appspot/apprtc/CallActivity.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/examples/android/src/org...
talk/examples/android/src/org/appspot/apprtc/CallActivity.java:262:
localRender.postDelayed(new Runnable() {
On 2015/08/04 00:27:23, AlexG wrote:
> nit: this was probably not the best way from the beginning, now it looks a
> little strange why we are posting disconnect() request to local renderer - may
> be use:
> (new Handler()).postDelayed(...) here?

Done.

https://codereview.webrtc.org/1257043004/diff/1/talk/examples/android/src/org...
talk/examples/android/src/org/appspot/apprtc/CallActivity.java:345:
remoteRenderLayout.setPosition(REMOTE_X, REMOTE_Y, REMOTE_WIDTH, REMOTE_HEIGHT);
On 2015/08/04 00:27:23, AlexG wrote:
> Could it cause race condition when say position is updated, but scaling type
is
> not and renderer thread will render frame with updated position, but not
updated
> scaling. May be merge all layout specific set function into one set function
> with one parameter structure containing position, mirror and scaling type
> fields?

There is no race between setPosition() and setScalingType() because they are
just setters, and the actual layout change is triggered by requestLayout().
However, making a layout update that changes the display aspect ratio will
stretch the currently shown frame, and it will remain stretched until the next
frame arrives and is rendered. I don't know any way around this. I think
animations that preserve aspect ratio will look fine, and otherwise they will
look stretched. To avoid this, we could hide the SurfaceView during layout
transitions, show some generic animation instead, and then unhide the
SurfaceView once it has been rendered correctly in the new layout.

[AlexG, 2015-08-05 00:47:11]

Thanks for addressing comments Magnus.
A few more comments, but these are not critical - may be can be addressed in
follow up CL or not addressed if they make no much sense :)

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:184:
synchronized (layoutLock) {
On 2015/08/04 17:05:05, magjed_webrtc wrote:
> On 2015/08/04 00:27:23, AlexG wrote:
> > Do you think it's worth skip rendering of the frame until layout change is
> done?
> > I am worried about some corner cases when camera is running at low fps due
to
> > high load or application is paused and the last frame is displayed when
> > application is in background - for these cases the last rendered may stick
for
> > some time and may have incorrect layout.
> 
> Do you mean dropping the frame or delay renderFrameOnRenderThread() until
layout
> change is done? One problem is that I don't know of any good way to get
notified
> when layout change is done. onSizeChanged() is not guaranteed to get called
> after requestLayout(), so we could get stuck with a pending frame that will
> never be rendered. onLayout() might get called several times during the layout
> process, so I don't think it's a good place either. onDraw() is not called at
> all for SurfaceViews.
> 
> Also, this requestLayout() is typically only triggered by an orientation
change
> so it's an uncommon corner case.

I often seen the cases when for bad connection remote frame freezes for quite a
while. If user will either rotate the device or even swipe to get a system menu
the layout will be updated.
Will onSizeChanged() callback indicate that layout update is done? May be it is
possible to use this callback to block any frame from rendering until layout
update is fully completed. Yes, I think we should not redraw the view and block
rendering thread while pending layout update.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
File talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java:126: public void
release() {
On 2015/08/04 17:05:05, magjed_webrtc wrote:
> On 2015/08/04 00:27:23, AlexG wrote:
> > I would add a flag here to avoid accidental case if I420Frame comes from C++
> (in
> > RenderFrame()), shallow copy is not created, but I420Frame.release() is
called
> > to avoid accidental freeing of C++ memory from Java. Overall interface looks
> not
> > very clear for me though - for some I420 frames we should call release(),
for
> > another - not.
> 
> Ok, how about this interface instead; for every call to renderFrame(), the
> callee is responsible for calling static VideoRenderer.renderFrameDone(frame)
to
> signal that rendering is done. This return call is allowed to take place after
> renderFrame() has returned, making async rendering possible. I have updated
the
> CL to this interface instead. What do you think?

If you are making a copy of only pointers in VideoFrame, but not makig a copy of
actual yuv data then after VideoRendererInterface::RenderFrame() is called by
say camera  you return right away and just copy pointers and sending the request
to render thread to do the rendering. How do you ensure than that camera will
not modify yuv data of this frame if the frame is returned back to camera pool?

The reason why VideoRenderrGui.java made a copy of whole frame including yuv
data was because C++ VideoRendererInterface::RenderFrame() API assumes sync
rendering - i.e. after the call is done it is assumed that frame is rendered and
its yuv data may be updated with the next image.

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
File talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:232:
suggestedSize = VideoRendererGui.getDisplaySize(
Move this to helper class?

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:306:
VideoRendererGui.getTextureMatrix(
Move this to helper class?

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
File talk/app/webrtc/java/android/org/webrtc/VideoRendererGui.java (right):

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
talk/app/webrtc/java/android/org/webrtc/VideoRendererGui.java:108: public static
float convertScalingTypeToVisibleFraction(ScalingType scalingType) {
I think these helpers need to me moved to a separate class - VideoRendererGui
and SurfaceViewRenderer are two independent video renderers and VideoRendererGui
may be gone then. Now new renderer still uses helpers from old renderer.

[magjed_webrtc, 2015-08-07 15:55:33]

Patchset #3 (id:40001) has been deleted

[magjed_webrtc, 2015-08-07 16:05:57]

Patchset #3 (id:60001) has been deleted

[magjed_webrtc, 2015-08-07 16:18:29]

Patchset #3 (id:80001) has been deleted

[magjed_webrtc, 2015-08-07 17:14:50]

The last patch is rather big. I forgot about unpacked yuv frames which I have
added support for now. Also, it required a big change to avoid stretching
frames, but now it looks good on all my devices.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
File talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/android/...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:184:
synchronized (layoutLock) {
On 2015/08/05 00:47:11, AlexG wrote:
> On 2015/08/04 17:05:05, magjed_webrtc wrote:
> > On 2015/08/04 00:27:23, AlexG wrote:
> > > Do you think it's worth skip rendering of the frame until layout change is
> > done?
> > > I am worried about some corner cases when camera is running at low fps due
> to
> > > high load or application is paused and the last frame is displayed when
> > > application is in background - for these cases the last rendered may stick
> for
> > > some time and may have incorrect layout.
> > 
> > Do you mean dropping the frame or delay renderFrameOnRenderThread() until
> layout
> > change is done? One problem is that I don't know of any good way to get
> notified
> > when layout change is done. onSizeChanged() is not guaranteed to get called
> > after requestLayout(), so we could get stuck with a pending frame that will
> > never be rendered. onLayout() might get called several times during the
layout
> > process, so I don't think it's a good place either. onDraw() is not called
at
> > all for SurfaceViews.
> > 
> > Also, this requestLayout() is typically only triggered by an orientation
> change
> > so it's an uncommon corner case.
> 
> I often seen the cases when for bad connection remote frame freezes for quite
a
> while. If user will either rotate the device or even swipe to get a system
menu
> the layout will be updated.
> Will onSizeChanged() callback indicate that layout update is done? May be it
is
> possible to use this callback to block any frame from rendering until layout
> update is fully completed. Yes, I think we should not redraw the view and
block
> rendering thread while pending layout update.

Done. I block rendering while a layout update is pending. Layout size is
determined when a frame is about to be rendered, and onMeasure() will refuse to
stretch the current frame.

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
File talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/1/talk/app/webrtc/java/src/org/...
talk/app/webrtc/java/src/org/webrtc/VideoRenderer.java:126: public void
release() {
On 2015/08/05 00:47:11, AlexG wrote:
> On 2015/08/04 17:05:05, magjed_webrtc wrote:
> > On 2015/08/04 00:27:23, AlexG wrote:
> > > I would add a flag here to avoid accidental case if I420Frame comes from
C++
> > (in
> > > RenderFrame()), shallow copy is not created, but I420Frame.release() is
> called
> > > to avoid accidental freeing of C++ memory from Java. Overall interface
looks
> > not
> > > very clear for me though - for some I420 frames we should call release(),
> for
> > > another - not.
> > 
> > Ok, how about this interface instead; for every call to renderFrame(), the
> > callee is responsible for calling static
VideoRenderer.renderFrameDone(frame)
> to
> > signal that rendering is done. This return call is allowed to take place
after
> > renderFrame() has returned, making async rendering possible. I have updated
> the
> > CL to this interface instead. What do you think?
> 
> If you are making a copy of only pointers in VideoFrame, but not makig a copy
of
> actual yuv data then after VideoRendererInterface::RenderFrame() is called by
> say camera  you return right away and just copy pointers and sending the
request
> to render thread to do the rendering. How do you ensure than that camera will
> not modify yuv data of this frame if the frame is returned back to camera
pool?
> 
> The reason why VideoRenderrGui.java made a copy of whole frame including yuv
> data was because C++ VideoRendererInterface::RenderFrame() API assumes sync
> rendering - i.e. after the call is done it is assumed that frame is rendered
and
> its yuv data may be updated with the next image. 

It is possible to make async rendering with
VideoRendererInterface::RenderFrame(const cricket::VideoFrame* frame). You call
cricket::VideoFrame::Copy(). The documentation say:
// Make a shallow copy of the frame. The frame buffer itself is not copied.
// Both the current and new VideoFrame will share a single reference-counted
// frame buffer.
virtual VideoFrame *Copy() const = 0;
The frame won't be reused until the last reference is gone. In this particular
case, the cricket::VideoFrame implementation is cricket::WebRtcVideoFrame and
the Copy() function will create an extra reference to the
rtc::scoped_refptr<WrappedI420Buffer> that is created here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjin...
When the last reference is gone, the frame is returned back to the camera pool.

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
File talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java (right):

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:232:
suggestedSize = VideoRendererGui.getDisplaySize(
On 2015/08/05 00:47:11, AlexG wrote:
> Move this to helper class?

Done.

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
talk/app/webrtc/java/android/org/webrtc/SurfaceViewRenderer.java:306:
VideoRendererGui.getTextureMatrix(
On 2015/08/05 00:47:11, AlexG wrote:
> Move this to helper class?

Done.

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
File talk/app/webrtc/java/android/org/webrtc/VideoRendererGui.java (right):

https://codereview.webrtc.org/1257043004/diff/20001/talk/app/webrtc/java/andr...
talk/app/webrtc/java/android/org/webrtc/VideoRendererGui.java:108: public static
float convertScalingTypeToVisibleFraction(ScalingType scalingType) {
On 2015/08/05 00:47:11, AlexG wrote:
> I think these helpers need to me moved to a separate class - VideoRendererGui
> and SurfaceViewRenderer are two independent video renderers and
VideoRendererGui
> may be gone then. Now new renderer still uses helpers from old renderer.

Done.

[AlexG, 2015-08-11 00:09:36]

Thanks! Nice work!

lgtm

[magjed_webrtc, 2015-08-11 11:55:31]

The CQ bit was checked by magjed@webrtc.org

[commit-bot: I haz the power, 2015-08-11 11:55:36]

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

[commit-bot: I haz the power, 2015-08-11 11:57:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-08-11 11:57:18]

Try jobs failed on following builders:
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/338)

[magjed_webrtc, 2015-08-11 12:04:11]

The CQ bit was checked by magjed@webrtc.org

[magjed_webrtc, 2015-08-11 12:04:12]

The patchset sent to the CQ was uploaded after l-g-t-m from glaznev@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1257043004/#ps120001 (title:
"Change license header for PercentFrameLayout.java")

[commit-bot: I haz the power, 2015-08-11 12:04:14]

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

[commit-bot: I haz the power, 2015-08-11 13:50:23]

Committed patchset #4 (id:120001)

[commit-bot: I haz the power, 2015-08-11 13:50:38]

Patchset 4 (id:??) landed as
https://crrev.com/05bfbe47ef6bcc9ca731c0fa0d5cd15a4f21e93f
Cr-Commit-Position: refs/heads/master@{#9699}

[magjed_webrtc, 2015-08-12 06:53:51]

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

The reason for reverting is: AppRTCDemo often crashes in loopback mode and
incorrect layout when connection is established.

[magjed_webrtc, 2015-08-17 13:52:56]

I will split this CL up and land it in parts.