Add mailbox-based Mojo VideoFrame variant.
This CL creates a foundation for plumbing mailbox-based Mojo VideoFrames, but
does not fully implement all of the callbacks. The expected implementation (in
MojoVideoDecoderService) is:
- Once a decoder running in the GPU process has decoded a frame,
MojoVideoDecoderService can attach a |release_token| to the
OnVideoFrameDecoded() IPC along with the frame. In practice, the impl will
generate one whenever the video frame is texture-backed, and it will store refs
to all such outstanding video frames (keyed by this generated |release_token|).
- The renderer handles the video frame as usual, flowing through the regular
pipeline and compositing steps. Once compositing is done, the compositor sets
the |release_sync_token| based on its own command buffer. The frame is then
destructed (as usual).
- MojoVideoDecoder receives the destruction callback. At this point the
|release_sync_token| has been verified as part of hopping to the media thread
and command buffer. It now forwards the sync point to the GPU process via the
OnReleaseMailbox() Mojo IPC.
- MojoVideoDecoderService (on the GPU side) will check that the sync point is
valid, terminating the Mojo connection if it is not. It then looks up, updates,
and removes the video frame from its map. If there is an attached destruction
observer, it will receive the |release_sync_point|, and the decoder will know
that the textures can be re-used after waiting for that.
Note that if the media command buffer and compositor command buffer are ever
merged (again), the validation step won't happen as part of the hopping anymore,
and validation on the GPU side could fail (timing dependent). We would need to
switch to sending the OnReleaseMailbox() IPC via the GPU channel instead of
Mojo in that case (or take the performance hit of validating the sync point from
the Renderer explicitly).
BUG=522298
Review-Url: https://codereview.chromium.org/2640153004
Cr-Commit-Position: refs/heads/master@{#454427}
11 files changed
