Chromium Code Reviews Chromium Code Reviews
Issue
1128213005:
Passing Native Texture backed Video Frame from Renderer to GPU process (Closed)
DescriptionThis CL enables passing a Native Texture backed media::VideoFrame from Renderer process to Video Encode Accelerator in GPU process.
This is a part of Zero Copy Capture for CrOs plan: https://docs.google.com/document/d/1lobWf168_Kq05TLNLX81gRQwY5oe4k2t3oP-XTBEpIo
- VideoFrameWrapper points to the underlying media::VideoFrame via native_handle()
- WebRtcVideoCapturerAdapter uses VideoFrameWrapper to pass Native Texture backed VideoFrame
- RTCVideoEncoder accesses the media::VideoFrame via native_handle() and passes
- GpuVideoEncodeAcceleratorHost::Encode checks the VideoFrame::storage_type() and passes IPC calls: AcceleratedVideoEncoderMsg_EncodeSharedMemory or AcceleratedVideoEncoderMsg_EncodeNativeTexture
- AcceleratedVideoEncoderMsg_EncodeNativeTexture passes the underlying gpu::MailboxHolder
* Another alternative would be passing a gpu::Mailbox and rebuilding it, but I found this IPC call passing a gpu::MailboxHolder and thought it might be OK. https://code.google.com/p/chromium/codesearch#chromium/src/content/common/media/video_capture_messages.h&rcl=1431704469&l=40
- AcceleratedVideoEncoderMsg_EncodeNativeTexture is handled by GpuVideoEncodeAccelerator::OnEncodeNativeTexture in GPU process which rebuilds a VideoFrame by using the incoming gpu::MailboxHolder for media::VideoFrame::WrapNativeTexture()
In the follow-up CLs:
- Modify GLImage such that it can return the underlying data_ptr() and plane information
- Pass GpuCommandBufferStub to V4L2VideoEncodeAccelerator
- Use sync_point_manager() to wait for the sync_point on the incoming texture in VEA and use texture_manager() in V4L2EA/V4L2IP to access the underlying texture&image, such that the underlying data -described in the step above- can be used for encode
- Redesign RTCVideoEncoder to work with non-ShMem media::VideoFrames
- Tweak RTCVideoEncoder::Impl::CreateAndInitializeVEA() to initialize VEA with the correct formats rather than just expecting I420.
- Tweak V4L2 image processor to initialize VEA with the correct formats rather than just expecting I420->NV12
- Check the fallbacks and handling of VideoFrames inside WebRTC classes such as VieCapturer
BUG=485323, 440843
TEST= Run a successful AppRTC loopback using:
- FakeVideoCaptureDevice which outputs Native Texture backed Video Frame
- FakeVideoEncodeAccelerator which works with the incoming Native Texture
https://docs.google.com/a/google.com/document/d/1a-5LZ0UTftpiu07wqYswxm2Ci6rDLKAUUx5al4C0ZTg/edit?usp=sharing
- https://review.webrtc.org/50909005/ applied
Patch Set 1 : #
Total comments: 9
Patch Set 2 : posciak@ and magjed@ comments. #
Total comments: 20
Patch Set 3 : mcasas@ comments. #Patch Set 4 : Rebased #Patch Set 5 : Fixed msvc issues. #Patch Set 6 : Passing a Texture+SharedMemory video frame. #
Messages
Total messages: 32 (25 generated)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
