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

feat(web): chromecast support for shared content #14497

Closed
wants to merge 2 commits into from

Conversation

omricarmel
Copy link

@omricarmel omricarmel commented Dec 5, 2024

  • supporting chromecast casting through chrome browser
  • only on publicly shared assets without password
  • directing the casting receiver to download asset endpoint
  • using default receiver
    somewhat resolves [Feature] streaming to chromecast #7030
image

@omricarmel omricarmel changed the title feat(web): chromecast support for shared content (#7030) feat(web): chromecast support for shared content Dec 5, 2024
@bo0tzz
Copy link
Member

bo0tzz commented Dec 5, 2024

How does this relate to #13966?

@etnoy
Copy link
Contributor

etnoy commented Dec 5, 2024

I might be biased, but I suggest we combine our efforts in #13966. That PR has come much further along, including private assets and video controls

@omricarmel
Copy link
Author

@bo0tzz this pr is simpler and less comprehensive.

On the other hand i do not hold a state and offload playback controls to chrome's cast popup interface.

as @etnoy mentioned i only allow casting publicly accessible assets ( so that chromecast will be able to reach them on its own ).

@omricarmel
Copy link
Author

I might be biased, but I suggest we combine our efforts in #13966. That PR has come much further along, including private assets and video controls

@etnoy Definitely. I didn't know about the other pr when working on this one.

Even though this one would be easier to finish at its scope of operation and complexity.

@omricarmel
Copy link
Author

Seeing the diff between the PRs, This style implementation has merit. offloading the session playback handling to chrome and not allocating privilege to the cast device. The PRs are complementary, this one directs the cast device to an asset upon request (hence only public assets) and the other puts the web viewer into casting mode hooking all asset views.

Eventually they should be unified but this pr can be completed before the more comprehensive one.

@etnoy etnoy requested a review from zackpollard December 8, 2024 22:15
@zackpollard
Copy link
Contributor

Hey, we are going to push ahead with the existing PR, but we will pull some inspiration from this PR wrt the loading code. We have already had discussions around authentication and ability to totally disable the option to cast that this doesn't implement. Also, I understand you don't want to initiate a cast session and just want to cast a single picture, however this isn't the direction we want to pursue. Thanks for your PR and we hope to have chromecast support implemented soon!

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

Successfully merging this pull request may close these issues.

5 participants