Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[media] Move StarboardRenderer to MojoRenderer #5113

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

borongc
Copy link
Contributor

@borongc borongc commented Mar 19, 2025

Move StarboardRenderer to Gpu thread, and each of StarboardRenderer is ran on PooledSingleThreadTaskRunner. This allows Starboard to access Chrome_InProcGpuThread for graphical tasks.

This PR adds a CreateStarboardRenderer() to the InterfaceFactory mojom with the purpose of running StarboardRenderer on Gpu thread; this forced an implementation in a number of places, namely MediaInterfaceFactory, MediaInterfaceProxy and FramelessMediaInterfaceProxy.

b/394368542
b/378740140
b/405401569

@borongc borongc requested a review from yell0wd0g March 19, 2025 16:51
@borongc borongc force-pushed the sbplayer_in_gpu branch 10 times, most recently from 10d7c58 to 3acdba0 Compare March 21, 2025 19:38
@borongc borongc marked this pull request as ready for review March 21, 2025 19:39
@borongc borongc requested review from a team as code owners March 21, 2025 19:39
@borongc borongc force-pushed the sbplayer_in_gpu branch 6 times, most recently from aa08231 to 0db7fab Compare March 23, 2025 17:21
Copy link
Contributor

@yell0wd0g yell0wd0g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments, ran out of time. In general looks good. Is the new code covered by existing unit tests?

@@ -37,8 +37,10 @@ std::unique_ptr<AudioEncoder> CreatePlatformAudioEncoder(
return nullptr;
}

#if !BUILDFLAG(USE_STARBOARD_MEDIA)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm this is surprising. Does it collide with some similarly named Starboard class?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chromium linux build doesn't use MojoCdm, so it defines an empty class here.

For us, we need to check if MojoCdm works on linux build, and I'll put this as a TODO (as this requires Infra team to setup keyboxes to have an internal Chrobalt linux build).

As this PR overwrote CreateCdmFactory in GpuMojoMediaClient for both android and linux, I think MojoCdm would work for us.

Copy link
Contributor Author

@borongc borongc Mar 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put this TODO as b/406263478 in media/starboard/starboard_cdm.h.

@@ -180,6 +185,18 @@ class MEDIA_MOJO_EXPORT GpuMojoMediaClient final : public MojoMediaClient {
const gfx::ColorSpace& target_color_space,
mojo::PendingRemote<stable::mojom::StableVideoDecoder> oop_video_decoder)
final;
#if BUILDFLAG(USE_STARBOARD_MEDIA)
std::unique_ptr<Renderer> CreateStarboardRenderer(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we create a media/mojo/services/gpu_mojo_media_client_starboard.(cc|h) to implement this functionality, like other platforms do? We'd need to go the CreateGpuMediaService() way.

It'd change things quite a bit for this CL though, by extending CreateAudio/VideoDecoder to have starboard-specific implementations, instead of adding a new method all around. Did you consider that route? Ah but I see the current factory methods would not allow for the plane id, durations, extensions etc, right? Maybe leave a note in the CL description about why adding all CreateStarboardRenderer() methods is a must.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created media/mojo/services/gpu_mojo_media_client_starboard.cc for Cobalt.

We need CreateStarboardRenderer to create Renderer on Gpu thread. For other chromium platforms, they only use Gpu thread for video/audio decoding/encoding, and cdm tasks, but for us, all of them are inside SbPlayer.

Typically, their Renderer is on utility thread (if MediaFoundation), or other platform-specified thread.

We can migrate to use CreateAudio/VideoDecoder after we break SbPlayer to two parts (media pipeline / hw decoding). But, for now, we will need this specific CreateStarboardRenderer.

renderer_extension_receiver,
mojo::PendingRemote<mojom::StarboardRendererClientExtension>
client_extension_remote) {
return std::make_unique<StarboardRendererWrapper>(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new code would be covered by media/mojo/services/media_service_unittest.cc tests?

If not then at the very least add a new test case to call this function. Creation-destruction is already enough for downstream tools like ASAN/TSAN etc and/or fuzzer to build upon, so a tiny bit of extra testing goes a long way.

Move StarboardRenderer to Gpu thread, and each of StarboardRenderer is ran on PooledSingleThreadTaskRunner. This allows Starboard to access Chrome_InProcGpuThread for graphical tasks.

b/394368542
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants