Newpipe: 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 :+1:

[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.

[parkgrrr]

@wb9688 Is there any reason to not use the Google cast android sdk? I would love to cast to my Xbox one as well.
https://developers.google.com/cast/docs/android_sender_integrate

[theScrabi]

Yes it's a nonfree lib and we prevent using those.

[Zykino]

If this is done will it "implements the Cast V1 protocol" and be compatible with the TubeCast app on Kodi? (If so I really want it :) )

[theScrabi]

Cast V1 is compactly different protocol compared to Cast V2. So they should be implemented separately.

Cast V1 makes a device more or less just a remote control for the device, so the player UI should be able to send commands here.

Cast V2+ send actual streams (as long as I know).

Atm there is no action of the team that could lead to support for any of those protocols, however I would love to see them, but someone had to help us implement them. Possibly as a moduled/seperate project.

[Kovaelin]

I know casting isn't available yet, but I just wanted to share that one of the issues I have with the native YT app, is that the queue disappears after you stop casting. This might be one thing to keep in mind when moving forward.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[imShara]

Any news?

[robotsheepboy]

Also wanted to say thanks for the the great work and echo that any news would be appreciated and this is still the only feature keeping lots of people I know (including myself) from using newpipe all the time

[infinity0]

Thanks for making this app! I wanted to +1 this ticket. Did you guys know already that VLC Android can stream to chromecast just fine without Google Play Services? I'm sure some code can be lifted out of there!

[theScrabi]

No good to know

[vilhelmgray]

This looks like the commit which added the chromecast audio passthrough option to VLC Android: https://code.videolan.org/videolan/vlc-android/commit/d01fe83d6ac69cf6d203a04c47989f2dc47c752a

[lephyrus]

While certainly not as good as direct support within NewPipe could be, "sharing" a video to _Play with VLC_ and casting from there works pretty well for me. No queue of course, even though _Append to VLC queue_ could be a nice sharing target for VLC to offer. Not all videos seem to work, but again, that's probably a VLC issue. Anyway, just a pointer for people who use Chromecasts with YouTube and miss that functionality with NewPipe, as I did.

By the way, I've just discovered NewPipe while trying to move to FOSS where possible. It's great - thanks to all contributors!

[ToughGuyKunio]

Another FOSS app that can stream to Chromecast is Jellyfin (Emby fork).

[logos88]

Universal Media Server can stream to Chromecast too.

In fact, in Jellyfin matrix chat the Universal Media Server hardcoded profiles seems recommended to improve their DLNA implementation, besides of implementing getProfile().

[logos88]

And a firefox extesion + app which is implementing the cast option in Firefox:
https://github.com/hensm/fx_cast/blob/master/IMPLEMENTATION.md

[VvLuijovV]

Newpipe is Soooooo good, sometimes it gives me some errors with some videos, but 99% of the time it is What youtube's app and overall what youtube showld've been, even tho that's a fact, the only thing i need to finally uninstall YT's app and free my phone from those 700 mb i have to be cleaninng every certain days is this feature, please, cheers on you guys!!

[sebma]

@lephyrus

While certainly not as good as direct support within NewPipe could be, "sharing" a video to _Play with VLC_ and casting from there works pretty well for me. No queue of course, even though _Append to VLC queue_ could be a nice sharing target for VLC to offer. Not all videos seem to work, but again, that's probably a VLC issue. Anyway, just a pointer for people who use Chromecasts with YouTube and miss that functionality with NewPipe, as I did.

By the way, I've just discovered NewPipe while trying to move to FOSS where possible. It's great - thanks to all contributors!

How do you do it on Android ?

VLC does not seem to support YouTube URLs on my android device.

[lephyrus]

How do you do it on Android ?

@sebma What I've described is exactly what I do on Android. Sharing from NewPipe to VLC. Works most of the time for me.

[luxzg]

Hey all and thanks for this thread (and the app!!). I too miss casting to my Android TV a lot, but VLC as workaround isn't much better, as what I really need is queue/playlist support so I can cast like 20 videos that are just 3-5min long in one playlist, and cast it, and loop it for infinite loop...

[Stypox]

You can install NewPipe on an Android TV, from 0.19.3 it is officially supported @luxzg

[luxzg]

Thanks for the info! I'll try that tomorrow morning

[sentriz]

here's a workaround I've been using that's been good so far
termux + python + pip + catt

$ apt install python
$ pip install --user catt
$ catt scan
$ catt --device <name> set_default

find your video in NewPipe -> share -> copy URL

$ catt play <paste> # play video, overwriting queue
$ catt add <paste>  # add video to queue

EDIT:

even better, create a file ~/bin/termux-url-opener

if [[ "$#" -ne 1 ]]; then
    echo "please provide a url" >&2
    exit 1
fi

case "$1" in
    *://youtube.com/*|*://youtu.be/*) catt add "$1" ;;
    *)                                catt cast "$1" ;;
esac

now you can "Share to Termux" from NewPipe and it will cast it
(more info)

[sh1der]

It would be great to have this feature. Thanks for the work you do, I love NewPipe

[opusforlife2]

It's great that you want this feature, but you should add a thumbs up like the others, otherwise it creates a pointless notification to everyone watching the thread.

[njayarama]

pretty cool app, hands down!!
eager to get casting on TV feature : )

[starsep]

~I created a simple (clearly not-production-ready) prototype using exoplayer:extension-cast here: https://github.com/starsep/NewPipe/tree/exoplayerExtensionCastProtype~
Edit: Removed due to GPL

I have read Contributing guide and https://f-droid.org/en/docs/FAQ_-_App_Developers/#which-libraries-and-dependencies-are-good-to-use and I'm afraid Google Cast API seems to be closed-source. Would a Pull Request using this API be accepted? Possibly in some separate branch?

If not I just would develop this feature for me in my fork.

[opusforlife2]

Any dependency which prevents Newpipe from being distributed on F-Droid will probably be rejected.

[wb9688]

@starsep: It's not legal to add proprietary dependencies to code licensed under the GPL.

[lallulli]

I think that dynamically linking a GPL software to a proprietary dependency is legal. Otherwise porting GPL'd programs to Windows (such as the whole KDE for Windows project) would not be have been possible.

[starsep]

@starsep: It's not legal to add proprietary dependencies to code licensed under the GPL.

Does it also mean that I am not allowed to continue working on such a feature in my own fork? That's unfortunate but thanks for the information. I hoped it's gonna be low effort working solution.

I am willing to invest some of my free time in developing Chromecast support. In this issue some other projects are mentioned. Do you have any consensus on which NewPipe's support should be based on? How can I help :)?

[TheAssassin]

@starsep: It's not legal to add proprietary dependencies to code licensed under the GPL.

Wrong wording. Dependencies added to GPL licensed software must be under the terms of the GPL or a compatible license. The end result will also be GPL-licensed. Proprietary dependencies are never shipped with compatible licenses. This renders the idea illegal.

I think that dynamically linking a GPL software to a proprietary dependency is legal.

See above. It's not.

Otherwise porting GPL'd programs to Windows (such as the whole KDE for Windows project) would not be have been possible.

Mind to elaborate? Why shouldn't it be allowed? The license(s) permit(s) it. TL;DR: system libs are treated differently. Note that it's just an exception (there's just a few), not a generic rule.

Ever asked yourself whether it's possible to link proprietary software on Linux against, say, the libc? libc is distributed under the LGPL, which permits the use of proprietary software as long as you link libc dynamically. Static linking is not allowed, there the license behaves like the GPL. (Though, AFAIK, the FSF says in another FAQ that they won't sue you if you statically link libc. But still, it's not covered by the license, you'd just rely on a promise.)

In your Windows example, you'd be subject to what's commonly referred to as the "system library exception". Very low level libraries may be proprietary, you can still link against them. See https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException, as well as the very specifically applicable https://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL.

By the way: stuff compiled on Windows, e.g., with gcc, will typically link against free software system libs such as the GNU libc. There, no question, that's perfectly fine.

You guys should probably start reading that license, and probably also the FAQ. I know the texsts long, but I often read wrong statements here and in other bug trackers.

I'm not a lawyer and don't provide legal advice, by the way.

[TheAssassin]

@starsep: It's not legal to add proprietary dependencies to code licensed under the GPL.

Does it also mean that I am not allowed to continue working on such a feature in my own fork? That's unfortunate but thanks for the information. I hoped it's gonna be low effort working solution.

You could do it privately, but you offend the library if you publish this software (doesn't matter if just the code or binaries). Putting it on GitHub is a publication.

I am willing to invest some of my free time in developing Chromecast support. In this issue some other projects are mentioned. Do you have any consensus on which NewPipe's support should be based on? How can I help :)?

Do what micro-g has done: reverse engineer the chromecast libraries, and write a free implementation.

Or, significantly better, provide a free, open-source alternative to this *cast stuff. I cannot understand why people want these sticks with proprietary software, but still use NewPipe. (Well, I have a few theories, but they're all basically "I want feature XYZ without paying for Youtube's premium service thingy" or "I prefer convenience over standards like running free software".)

[B0pol]

I cannot understand why people want these sticks with proprietary software, but still use NewPipe

To your theories, I'll add my potential use case:
"I did not buy a chromecast stick, it's included in my “smart„ router provided by my ISP, I almost never use it but it would be cool if I can cast to my tv from NewPipe."

[TheAssassin]

@B0pol thanks, noted. Here one could also argue that it would be nice to have some compatible implementations. Not just limited to the client but also the server side.

We need to return to free, open standards... these proprietary annoyances which can only be used through reverse-engineering really can ruin your day...

[Stypox]

Let me also add my use case: I live with my family and they are not so keen on privacy like I am, so a couple of years ago they brought an old-gen chromecast

[logos88]

@starsep: It's not legal to add proprietary dependencies to code licensed under the GPL.

Does it also mean that I am not allowed to continue working on such a feature in my own fork? That's unfortunate but thanks for the information. I hoped it's gonna be low effort working solution.

I am willing to invest some of my free time in developing Chromecast support. In this issue some other projects are mentioned. Do you have any consensus on which NewPipe's support should be based on? How can I help :)?

If your TV supports DLNA or DIAL you could help the Pipecast project to implement them, since both are open and used in a lot of TVs.

[ericyan]

I would suggest DLNA as well. It's an open standard and widely supported.

If you really want to cast to a Google Cast device (i.e. Chromecast), you could try my project https://github.com/ericyan/omnicast, which exposes Chromecast devices as DLNA media renderers. It is still experimental and undocumented though.

[abaker]

My understanding of this is that the NewPipe copyright holders could grant an exception to use the Cast SDK. This could either be maintained in a fork or as a separate build flavor distributed outside of the main F-Droid repo.

[mddvul22]

FYI, the VLC client (in F-Droid) can cast to Chromecast. So, VLC has it figured out.

[TheAssassin]

My understanding of this is that the NewPipe copyright holders could grant an exception to use the Cast SDK. This could either be maintained in a fork or as a separate build flavor distributed outside of the main F-Droid repo.

Not only would that make licensing more complex (who in the world reads those exceptions?), you'd also have to ask the majority of all contributors to make such a change. It's completely unrealistic. And I don't think Team NewPipe would want to do it anyway.

[ToughGuyKunio]

I cannot understand why people want these sticks with proprietary software, but still use NewPipe. (Well, I have a few theories, but they're all basically "I want feature XYZ without paying for Youtube's premium service thingy" or "I prefer convenience over standards like running free software".)

We use these sticks because most people (or their family members) want streaming services like Netflix, to watch streaming services at all or in decent resolutions you'll need proprietary solutions (please let me know if this has changed since I last looked). You can still prefer free software, there just aren't any good free software alternatives to all the use cases here.

[kinghat]

https://github.com/MayaPosch/NymphCast the problem is it doesnt make use of chromecast hardware, which everyone has.

[starsep]

You could do it privately, but you offend the library if you publish this software (doesn't matter if just the code or binaries). Putting it on GitHub is a publication.

I removed the branch I mentioned above. I think this is a cool project and would like to help which is why I asked whether such a feature could be merged before putting too much effort into it. I have no intentions of offending licence/authors.

I cannot understand why people want these sticks with proprietary software, but still use NewPipe. (Well, I have a few theories, but they're all basically "I want feature XYZ without paying for Youtube's premium service thingy" or "I prefer convenience over standards like running free software".)

For me reasons to use NewPipe over YouTube app are: (order matters)

1. Ability to disable/remove features I don't like/use/want.
2. No ads.
3. Ability to add features, control of the software.
4. Preference for open source.
5. Privacy concerns.

I personally would prefer having closed-source, black-box chromecast support over no such feature.
At the moment I mostly use YouTube app instead, I'd like to stop using it but for me this feature is a must-have.

Let me also add my use case: I live with my family and they are not so keen on privacy like I am, so a couple of years ago they brought an old-gen chromecast

Yeah, my use case is similar, I would like something which is easy-to-use and has all necessary features so I can recommend it to friends/family.

If your TV supports DLNA or DIAL you could help the Pipecast project to implement them, since both are open and used in a lot of TVs.

That's the thing. I don't own a tv. I use a Chromecast with old projector. It has no wireless functionalities.

FYI, the VLC client (in F-Droid) can cast to Chromecast. So, VLC has it figured out.

It looks that they have their implementation in C++. Might be useful in the case of some reverse-engineering route.
https://github.com/videolan/vlc/tree/master/modules/stream_out/chromecast

I would suggest DLNA as well. It's an open standard and widely supported.

If you really want to cast to a Google Cast device (i.e. Chromecast), you could try my project https://github.com/ericyan/omnicast, which exposes Chromecast devices as DLNA media renderers. It is still experimental and undocumented though.

Could you elaborate on how one would use your project? It's implemented in Go. Would I need separate device such as Linux computer/Rasperry Pi? If that's the case I'm not interested, neither my non-technical friends/family. Might be a useful resource though, thanks for the info!

[starsep]

Do what micro-g has done: reverse engineer the chromecast libraries, and write a free implementation.

That's interesting take. I will consider that. I see there are some parts implemented there:
https://github.com/microg/android_packages_apps_GmsCore/tree/master/play-services-cast-framework-api/src/main/java/com/google/android/gms/cast/framework
It has Apache-2.0 License.
I think ExoPlayer Cast Extension also has Apache-2.0 License (as main ExoPlayer).
https://github.com/google/ExoPlayer/tree/release-v2/extensions/cast

It seems that only offending line is
api 'com.google.android.gms:play-services-cast-framework:18.1.0'
https://github.com/google/ExoPlayer/blob/8a0d52be4b5402af0987fc7d009bc49977c72b67/extensions/cast/build.gradle#L17

Maybe:

• ExoPlayer fork
• com.google.android.gms:play-services-cast-framework open source reimplementation

What's your opinion both from the technical standpoint and License-wise?

[TheAssassin]

I have no intentions of offending licence/authors.

We have understood that, don't worry.

That's the thing. I don't own a tv. I use a Chromecast with old projector. It has no wireless functionalities.

Kodi and many other media players provide DLNA as well. You don't need a TV.

Unfortunately, Kodi's support for streaming from the Internet could be improved. I also think DLNA isn't necessarily the right choice. Given that NewPipe already does all the parsing from the websites, it would be awesome if you could just send the MPEG-DASH manifest URL to Kodi and have it render the video (or, as a fallback, a direct URL to a media stream). This could be implemented in a video.

Right now NewPipe can share to Kodi, but it uses this annoying, broken YT API dependent plugin. Instead of integrating with e.g., my (or anyone else's) Invidious plugin, I would suggest to write a plugin for that, exposing a simple universal API to just share these manifests (and maybe some meta info like subtitle language preferences etc.). I can imagine e.g., all media players on F-Droid, would adopt such a protocol quickly, if it isn't a lot of work for them to integrate (and simple and robust enough so you don't have to maintain such a feature very much).

Having written a basic Invidious plugin for Kodi, I can tell that navigating something like NewPipe in Kodi directly is quite annoying anyway. I personally would prefer navigating on my tablet, then click play and have a Kodi device hooked up to my TV play the stream. Kodi supports MPEG-DASH well (see e.g., https://github.com/TheAssassin/kodi-invidious-plugin/blob/master/resources/lib/invidious_plugin.py#L98-L119), and writing plugins isn't that hard (the API is very bad, but it does work).

TL;DR: how about writing our own open and simple sharing protocol, provide a reference client for Kodi and standardize it so other media players can adopt it with little effort?

com.google.android.gms:play-services-cast-framework open source reimplementation

It seems like micro-g already provide that? I don't know whether it has to communicate with Google infrastructure or contacts the cast devices directly, though.

You should be fine with reimplementing, copyright wise. And I don't think they patented their cast stuff, so you should be safe there, too. (Damn software patents...)

[MD77MD]

I personally would prefer navigating on my tablet, then click play and have a Kodi device hooked up to my TV

or to my dlna enabled device... (not all off us can use kodi e.g: Samsung tv)😉

[TheAssassin]

DLNA is just quite old and complex. Even "please play this URL on my device" requires quite some work already. It's annoying. I figure we need some more modern protocol, ideally also with some security layer.

[opusforlife2]

I haven't seen Miracast being mentioned. Is that not something already available for use?

[TheAssassin]

Miracast is a propietary, non-free "entire screen" casting thingy that is supported by no real devices. Even if supported, it doesn't work that well. The few times I tested it it had tons of issues with resolution (especially with tab -> TV, where I could not configure it).

For media casting, it's always better if the device just plays it with its regular player IMO.