Chromecast support

[lacolos]

First off I wanted to say good work on New pipe, it is now my go to YouTube player! The only functionality I miss is the ability to chromecast. I'm not sure if this is in the works or even possible? Thanks

[coffeemakr]

Support was already requested (see #351), then closed but not reopened after the discovery of an open-source library to stream to Google Cast.

[theScrabi]

I wonder how far they came with this project.

[imShara]

Not chromecast, but reversed youtube remote API https://github.com/mutantmonkey/youtube-remote

[KeizerDev]

@imShara That's cool, we can implement it but the thing is. The Chromecast audio won't work with it and it would be awesome to get that working with NewPipe. If we can make that work it would be another plus to use this app rather then the original Youtube app as they don't support the Chromecast audio. I want to dig into implementing it from scratch but I don't have much time. I've found a good project who have implemented it, without the Google lib.

[KeizerDev]

If we can implement this https://github.com/vitalidze/chromecast-java-api-v2 with the following snippet:

chromecast.load("http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4");

We can force the Chromecast using a certain quality. This is not supported by the original Youtube app. (Good if you only want to see high quality or if you want to save data you can force one with lower quality)

[theScrabi]

That lib actually looks pretty sophisticated. I like it :)

[KeizerDev]

Yup, and we have direct links, right? It wouldn't be much of a pain to implement it

[theScrabi]

I guess not.

[ghost]

@theScrabi: All we'll have to care about are the supported formats of Chromecast. I think I'll mess around with adding this, since I like doing this kind of stuff more than messing around with Android's layout stuff. IMHO we should also support some open standard instead of just the proprietary Chromecast. So maybe we should make a PipeCast library (@TheAssassin: Can we modify and relicense that Apache v2 library as GPL v3?).

[theScrabi]

Android's layout stuff

Totally understandable xD

So maybe we should make a PipeCast library

Yea why not :) I agree that we should prefer open standards.

[ghost]

@theScrabi: Yeah, but someone will need to do that layout stuff. Btw could you create a PipeCast repo in TeamNewPipe and give me write access to it?

[theScrabi]

I created PipeCast, and you got write access.
Please make sure the license is gpl3.

[ghost]

@theScrabi: Thanks! Ofcourse I will, that's why I asked if Apache v2 can become GPL v3 in a derivative work, which I looked up and it looks like it's possible. I'll try starting to implement it tomorrow.

[theScrabi]

Well I'm not that as good as @TheAssassin with legal things, but I think since apche2 is a mandatory license you can change the license when ever you like. You should just keep the copyright.

[TheAssassin]

@theScrabi whatever you're trying to say here: It's most likely wrong. You cannot "relicense" (quote from @wb9688) others' code, or use it however you want as long as you preserve the copyright notice.

Licenses are valid legal contracts. You have to adhere to them, i.e., you need to preserve the original license (probably even have to ship a copy), state that it's not your code, etc.

Regarding compatibility: The ASF published a document about that: https://www.apache.org/licenses/GPL-compatibility.html

Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

TL;DR: You can do it, but follow the instructions on the page.

A good overview of license compatibility can be found on Wikipedia: https://en.wikipedia.org/wiki/License_compatibility

[ghost]

@TheAssassin: OK, btw I didn't really mean relicensing, but I meant including that code and refactoring it a lot. So basically I could just do that? Or will I need to do some specific things? Thanks!

[TheAssassin]

@wb9688 well you said "relicense". Of course you can modify that code, but it will continue to be licensed under the terms of the Apache license.

By the way, if you make modifications and they're suitable for the upstream library, think about contributing those patches.

[KeizerDev]

Seems cool, have to keep an eye out on it. Good luck!

[KeizerDev]

I didn't had any problems streaming tho, someone have to make a choice tho to use the YouTube application on the Chromecast or the play media application where you pass an supported media url and it just plays it.

I think both will be a good bet.

Ps: with I, I mean my pr using the default media applications on the Chromecast just sending the direct url you use with the phone media player.

[ghost]

@TheAssassin: But what'd I need to do? Will I only need to include the GPL v3 license in the repo? Or will I also need to link to the upstream? Or will I need to do something else? @KeizerDev: We'll likely use the play media appliation, since we'll also support other services like SoundCloud.

[theScrabi]

Apparently we once also had a thread for UPnP/DLNA streaming.

[ghost]

@theScrabi: I know, I'll add support for DLNA to PipeCast once I've got Chromecast working. (Off-topic: could you please answer my questions on IRC?)

[KeizerDev]

Any progress here so far?

[ghost]

@KeizerDev: I've decided to implement UPnP first, since I can test that at home. The UPnP part is almost finished and I'll probably finish it this weekend. When it's finished, I'll push it to the PipeCast repo. After that and after I've repaired my phone's screen, I'll probably finish the UI for multiple services, which already has a PR. When that PR is merged, I'll start to implement the UI for PipeCast in NewPipe, if nobody else has done that by the time.

[KeizerDev]

@wb9688 I want to look into Chromecast support once you've pushed it 👍

[tkosamja]

Thanks for working on this! I really miss the feature of casting my videos to the TV.

[theScrabi]

If you have kodi, and the youtube app installed there you can use the "open in kodi" function to make newpipe look like its streaming.

[ghost]

@KeizerDev: I haven't had time yet to finish my UPnP streamer, but I've pushed the discoverer to the PipeCast repo. You can test it by cloning PipeCast, building it and running something like this, while running GMediaRender on another PC.

@mauriciocolli or @theScrabi: Could you please review that code? Btw could you set dev as the default branch there? (And can we also create a dev branch in NewPipeExtractor?)

[theScrabi]

And can we also create a dev branch in NewPipeExtractor

Yep I think that was a good idea.

[tdbe]

This is all a bit handwavy and ultimately unconvincing.... For example, "tightly coupled to Google services" — what; in contrast to YouTube? YouTube, the stated purpose of NewPipe?

There is a difference between "we build a client that can query YouTube in a privacy friendly way and does not need any sort of account or other authorization" and "we, the maintainers of NewPipe, need to request some kind of developer API key stuff in order for Chromecast to work". In case I am wrong about this, feel free to correct me, but do so with facts, not cheap whataboutism...

Please keep the discussion on topic. This is not a support forum, it is an issue tracker. We have an IRC channel for (less) on-topic discussions.

Then why not use a small 3rd party app that newpipe can share the url to, and that 3rd party generic app sends the url to chromecast or any other dnla device?

also heh, irc - that hot new thing known for lots of traction and ease of setup. Why not Matrix/Riot/Element?

[theScrabi]

Then why not use a small 3rd party app that newpipe can share the url to, and that 3rd party generic app sends the url to chromecast or any other dnla device?

This may not always wotk with chromecast as long as i know.

[JVT038]

For me, an acceptable workaround for using Chromecast with NewPipe:

1. install VLC

2. enable `Use external video player` and `Use external audio player` in `Settings` -> `Video and audio`

3. use VLC to cast the video

It's an extra step, but it works well enough.

For some reason VLC doesn't play audio when I try to do this...

[mmguero]

For me, an acceptable workaround for using Chromecast with NewPipe:

1. install VLC

2. enable `Use external video player` and `Use external audio player` in `Settings` -> `Video and audio`

3. use VLC to cast the video

It's an extra step, but it works well enough.

For some reason VLC doesn't play audio when I try to do this...

I have the problem depending on the resolution I choose. Usually if I choose 360p, 720p, or 1080p the sound comes along with it okay. If I choose something else I don't get sound either.

[Massimo-B]

I never succeeded sending to VLC for casting to a Chromecast (I just installed VLC org.videolan.vlc 3.5.2 from F-Droid, default settings). VLC can be connected to the Chromecase, but when sending a video from PipeWire I inly see something about VLC re-coding but the video never starts on the Chromecast.
The only cast thing that works is audio only via BubbleUPnP. For getting this to work it needs to set [x] Use external Audio player. After that I can press "Background" inside a video, choosing BubbleUPnP to take over. A bit confusing is that Choosing ""Play in background" from the context menu of a video item doesn't call BubbleUPnP but use the internal backgrounding. While actually setting this option it usually breaks the internal backgrounding in favour for using an external app, but based on the current behaviour it is comfortable to still have both options.

Back to casting the full video stream, it would be absolutely fine to have some external app doing the casting and just using the "Share" button. Which solution it there for getting video playing on Chromecast currently?

[opusforlife2]

@Massimo-B #668 (comment)

[Massimo-B]

Well, I did it like this.

[opusforlife2]

but when sending a video from PipeWire

Might be this. Do other apps cast fine?

[Massimo-B]

The Chromecast functionality itself works in all other apps. However I never cast local videos that need transcoding. And sharing a stream link from NewPipe to VLC or whatever doing the cast to Chromecast should not need any transcoding either. So actually I'm not sure if the casting from VLC is broken here or if there is something wrong with the content I share from NewPipe.

[opusforlife2]

You'll have to debug this by trying some other apps with VLC.

[Massimo-B]

What is the current workaround to get a stream from NewPipe to Chromecast? Still VLC? Did anybody get this working?

[mmguero]

VLC is still how I do it. It's kind of a pain sometimes (having to change the setting back and forth from external player when I do/don't want to use VLC, and sometimes opening a new video in newpipe still causes the previous video to load in VLC) but it's better than nothing.

[Massimo-B]

And your VLC on Android does not need to Re-encode the stream? My VLC works to send something local to the Chromecast. But I can't get a Stream shared from NewPipe to VLC, it says it needs re-encode and nothing happens. I don't even see any stream item in the playlist of VLC. For sending streams to Chromecast I usually use BubbleUPnP. Did anybody get a Youtube stream casted with that app?

[mmguero]

No, I don't have that issue. It just opens in VLC. In NewPipe I have Settings > Video and Audio > Use external video player set to on, then when I hit play on a video newpipe asks me what resolution to use. Some of them don't work on VLC, but if I use 720p or 1080p that seems to work. Then (the first time, at least) android asked me which app to use to open it and I selected VLC and it plays, at which point I can use VLC to cast.

[peat80]

Maybe instead of wasting time trying to implement closed source chromecast casting could be supported to an open protocol instead?

There is for example fcast, an open source casting protocol that could fit well here.
(https://fcast.org/)
They have an open source receiver app available in the playstore and code examples how to implement this into an app. 🤔

[Atemu]

That should probably be a separate feature request as this issue is specifically about the Chromecast protocol which will not happen.

See for instance #7346

[erebion]

Seems Miracast has not yet been suggested and something more open. :)

Some devices, like my projector, even have built-in support. :D

[Atemu]

Again, separate issue please. Also, miracast sucks.

[VvLuijovV]

Not to be rude, but I agree, miracast is pretty bad...

…

On Tue, 26 Dec 2023, 08:54 Atemu, ***@***.***> wrote: Again, separate issue please. Also, miracast sucks. — Reply to this email directly, view it on GitHub <#668 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHUFWYJ3EAHUIOIDELUVVKLYLLJKLAVCNFSM4DZMEGV2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBWHE2TMMRRGEZA> . You are receiving this because you commented.Message ID: ***@***.***>

[erebion]

Could you elaborate please? I think open standards are great.

[vilhelmgray]

Miracast was already discussed earlier in this issue page: #668 (comment)

[kevincox]

At the risk of going way off topic...

The linked comment seems wrong, Miracast is a standard and has fairly broad (although definitely not ubiquitous) support.

However Miracast is very different than protocols like Chromecast. It has different tradeoffs. Miracast is more like a wireless HDMI/DP cable than a remote control browser like Chromecast. In Miracast the sender streams a video the the receiver. This is different from Chromecast where the sender basically sends a URL to the receiver.

Pros:

• Naturally works offline. There is no network even involved, whereas I don't think Chromecast works offline at all. (Although the concept of a remote-controlled browser could work offline. For example if the page could be transmitted from the sender, for example a data: URL.)
• No concerns with network perspective. For example if I use a VPN to access a private service I don't need to worry about the receiver having access to that service as well as all of the access will be done by the sender and then sent directly to the receiver. The receiver doesn't even need network access.
• Less compatibility concerns/simpler protocol. For example with Chromecast I need to worry if the receiver can support AV1 video, whereas with Miracast I can just transcode whatever is available into pixels for the receiver.
• Open standard.

Cons:

• The sender is very active. It must be online and transmitting video wirelessly. This puts great load on the sender, other use of the sender device may cause stutters in the video stream and the sender must stay online and in-range of the receiver. This is awful for mobile battery.
• Wireless. Chromecast may often be used over wireless but that is typically the setup. Once initiated the video will typically be streamed directly to the receiver which may be hardwired for a much more reliable connection and causing less traffic in the air.
• Less reliable in general. There is much less room for buffering. So temporary wireless interference will stutter the stream whereas the Chromecast can buffer up a substantial amount of video.
• Lower quality. The video transmitted isn't lossless. So you are decoding the source video, then losslily re-encoding it. This will lose quality.

I would say that for most people this is a worse tradeoff. Personally I love that Chromecast uses no battery on my phone, I can use it freely or take it to the bathroom without disrupting the video in the living room. Miracast is great to, and has many use cases where it is a better tradeoff. But I think for watching online video on a TV it usually isn't the best option.

I really hope that we finally get an open protocol that can talk to Chromecast and other remote-browser dongles. (I'm still salty about the Mozilla Matchstick being cancelled.) But for now Chromecast is the most practical option for me.

[vilhelmgray]

I'm not familiar with Miracast so perhaps that comment I linked is wrong afterall (it sounds like Miracast is an open protocol from your description of it). It'll be best to open a new issue with your pros and cons for adding Miracast support so that we can continue the discussion there in a more dedicated thread.