Removing Internals>Media>Capture since it shouldn't exist according to  issue 685345 

Hello.

I'm the author of the original post of Intent to implement Syphon.

The work is being done at https://github.com/vade/chromium in the Syphon branch.

Current status is a working, but non optimized implementation of Syphon that follows the Decklink / AVFoundation model for the VideoCaptureAPI. Specially, we enumerate and handle callbacks for frame arrival in a manner similar to the existing OS X video capture devices that are implemented.

Ive been able to send streams of applications from Syphon out via WebRTC / getUserMedia and have been able to distribute a test binary successfully to users. 

In short, this appears to work exactly as advertised.

See https://github.com/vade/chromium/blob/Syphon/media/capture/video/mac/video_capture_device_syphon_mac.mm for details. Note, this is a work in progress :)

Some details I should mention:

• Video frames from Syphon arrive on the GPU, in the form of IOSurfaces vended via OpenGL from other applications (Say, Adobe Character Animator) Syphon output.

• The current Chromium implementation leverages OpenGL to read back from the GPU the surface. We do this to avoid an expensive IOSurface Lock which effectively stalls the sending application (Say, Adobe Character Animator) for the duration of the lock (since it cannot write to the shared IOSurface). 

• Since we use OpenGL in our VideoCaptureDevice, and since Chromium / Chrome specifically disables OpenGL platform libraries, we do initialize a Mac Desktop OpenGL library by way of a call to :

         gl::init::InitializeStaticGLBindings(gl::kGLImplementationAppleGL);

I am unsure if this is the correct way to handle this, if this would pass code review, etc. Id love some advice / direction on this.

• The current git repository correctly sets up folders in third party with license, deps, and has made changes to link the Syphon Framework to build Chrome. I have not yet handled the following:
    • copying the Syphon.framework to the appropriate target
    • running install_name_tool to ensure @loader_path / @rpath loading mechanism is handled.
    • modified build.gn files / entries for other targets like tests.

I would love guidance on the above 'to do's, and code style / guidance to pass any review, but more importantly, I am curious if it is realistically feasible to pursue implementing Syphon considering Chrome / Chromiums security "stance". 

Thank you very much for your time and consideration.

- Anton Marini.

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

commit c58f0323797ee837ccc917c8e31886a0fcbf712e
Author: timav <timav@chromium.org>
Date: Thu Feb 02 01:51:50 2017

[WebView shell] Discard very long WebView states

WebView serializes its state into Android's Bundle so it can restore
it through activity recycle. Since N Android has inforced the limit
for the size of the bundle, at the same time the length of the serialized
state has grew beyond this limit.

This CL puts a temorary fix to this problem into SystemWebViewShell only.
The states longer than 300k are now dropped by the shell.

BUG=686607

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

[modify] https://crrev.com/c58f0323797ee837ccc917c8e31886a0fcbf712e/android_webview/tools/system_webview_shell/apk/src/org/chromium/webview_shell/WebViewBrowserActivity.java

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

commit c58f0323797ee837ccc917c8e31886a0fcbf712e
Author: timav <timav@chromium.org>
Date: Thu Feb 02 01:51:50 2017

[WebView shell] Discard very long WebView states

WebView serializes its state into Android's Bundle so it can restore
it through activity recycle. Since N Android has inforced the limit
for the size of the bundle, at the same time the length of the serialized
state has grew beyond this limit.

This CL puts a temorary fix to this problem into SystemWebViewShell only.
The states longer than 300k are now dropped by the shell.

BUG=686607

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

[modify] https://crrev.com/c58f0323797ee837ccc917c8e31886a0fcbf712e/android_webview/tools/system_webview_shell/apk/src/org/chromium/webview_shell/WebViewBrowserActivity.java

Please disregard Comment 6, it went here by mistake because I set the wrong bug number to the CL. The CL belongs to Issue 680732.

vade@: perhaps you should post your questions in the "Intent to implement" thread on blink-dev. You are more likely to get help there.

Assigning to chfremer@ to guide vade@vade.info with the changes on #3.

Is there any interest in implementing this still?