chromium 视频流请求与传递过程分析

背景

chromium 浏览器在处理类似 chrome.desktopCapture 这样的视频流请求的时候,大致流程是什么样的呢?初步梳理了一下整个流程,流程还是比较长的,这里给出大概的类图,但只说明其中部分的关键点。

浏览器的 renderer 进程在接收到执行 getUserMedia() 的请求后,首先是由 blink 接受请求,然后转交给 content 中的 renderer 处理,UserMediaProcessor 类处理传入的请求,并通过 mojo 通信请求 browser 进程创建所需要的视频流,browser进程创建对应的视频流后通过调用 UserMediaProcessorOnStreamGenerated() 回调函数来反馈通知。UserMediaProcessor 通过 StartTracks() 来开启对应的视频流,在启动视频流的过程中,传入了回调函数,以便在收到视频帧时传递给需要视频帧的客户。

renderer 进程的处理流程

在 renderer 进程中,相关类图如下所示:
chromium 视频流请求与传递过程分析请求视频流的过程处理流程大致如下:

UserMediaProcessorMediaStreamVideoTrackMediaStreamVideoSourceMediaStreamVideoCapturerSourceLocalVideoCapturerSourceVideoCaptureImplManagerVideoCaptureImpl

视频流是按照请求的逆向传递的,首先是 VideoCaptureImpl 通过 mojo 接口从 browser 进程获取捕获的视频帧,然后从 VideoCaptureImpl 按照请求的逆向传递到 MediaStreamVideoTrack 后,开始分发给各个 sink。在多媒体领域中,source 、 track 和 sink是一套完整的概念,source 代表视频流的来源,track 代表视频流的轨道,类似水管的感觉,sink 代表接收视频的端点。由于我分析的是 chrome.desktopCapture 请求视频流的过程,所以这里的 sink 就是 MediaStreamVideoWebRtcSink ,当然还有其他类型的 sink。

browser 进程的处理流程

在 browser 进程中,与 renderer 进程的 VideoCaptureImpl 对接的是 VideoCaptureHostVideoCaptureImpl 通过 GetVideoCaptureHost() 获取一个 VideoCaptureHost 的指针,通过这个指针来控制 VideoCaptureHost 对视频流的处理。
chromium 视频流请求与传递过程分析其中 media_VideoCaptureDeviceClient代表media::VideoCaptureDeviceClient.
VideoCaptureHost 将视频流的控制指令传递给 VideoCaptureDeviceVideoCaptureDevice是一个抽象接口,其实是传递给对应平台下的视频捕获设备。

上一篇:16-Flink-Redis-Sink


下一篇:Codeforces - 1199C - MP3 - 尺取