标签：sink 请求 视频流 renderer 进程 chromium browser

背景

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是一个抽象接口，其实是传递给对应平台下的视频捕获设备。

标签：sink,请求,视频流,renderer,进程,chromium,browser
来源： https://blog.csdn.net/zhuiyuanqingya/article/details/89004787

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。