背景
chromium 浏览器在处理类似 chrome.desktopCapture 这样的视频流请求的时候，大致流程是什么样的呢？初步梳理了一下整个流程，流程还是比较长的，这里给出大概的类图，但只说明其中部分的关键点。
浏览器的 renderer 进程在接收到执行 getUserMedia() 的请求后，首先是由 blink 接受请求，然后转交给 content 中的 renderer 处理，UserMediaProcessor 类处理传入的请求，并通过 mojo 通信请求 browser 进程创建所需要的视频流，browser进程创建对应的视频流后通过调用 UserMediaProcessor 的 OnStreamGenerated() 回调函数来反馈通知。UserMediaProcessor 通过 StartTracks() 来开启对应的视频流，在启动视频流的过程中，传入了回调函数，以便在收到视频帧时传递给需要视频帧的客户。
renderer 进程的处理流程
在 renderer 进程中，相关类图如下所示：
请求视频流的过程处理流程大致如下：
视频流是按照请求的逆向传递的，首先是 VideoCaptureImpl 通过 mojo 接口从 browser 进程获取捕获的视频帧，然后从 VideoCaptureImpl 按照请求的逆向传递到 MediaStreamVideoTrack 后，开始分发给各个 sink。在多媒体领域中，source 、 track 和 sink是一套完整的概念，source 代表视频流的来源，track 代表视频流的轨道，类似水管的感觉，sink 代表接收视频的端点。由于我分析的是 chrome.desktopCapture 请求视频流的过程，所以这里的 sink 就是 MediaStreamVideoWebRtcSink ，当然还有其他类型的 sink。
browser 进程的处理流程
在 browser 进程中，与 renderer 进程的 VideoCaptureImpl 对接的是 VideoCaptureHost ，VideoCaptureImpl 通过 GetVideoCaptureHost() 获取一个 VideoCaptureHost 的指针，通过这个指针来控制 VideoCaptureHost 对视频流的处理。
其中 media_VideoCaptureDeviceClient代表media::VideoCaptureDeviceClient.
VideoCaptureHost 将视频流的控制指令传递给 VideoCaptureDevice，VideoCaptureDevice是一个抽象接口，其实是传递给对应平台下的视频捕获设备。