Add support for Chromecast

[jstritar]

Would be great if MPlayer supported Chromecast so we can stream to other devices easily.

[pigoz]

I am not very familiar with this but they seem to only provide a sender API for Android, iOS and Chrome, while we would need a cross-platform C API. So it's not possible at the moment. Anyhow, if this is anything like Apple's AirPlay mpv would need to transcode the file to h264 and stream that to the receiver.

[lidel]

Chromecast is using open protocol called DIAL -- developed by Netflix and YouTube as AirPlay alternative.
See DIAL project page, especially DIAL Protocol Specification.

Support should not be hard to implement, as there are 3rd party clients already, eg. AllCast for Android.

[pigoz]

I'm not sure how I missed your comment (I blame gmail!). I am very sorry for the late reply.

Thanks for pointing out the DIAL protocol. Just to make sure, we want to make mpv what the DIAL Specification calls a 2nd screen app right? i.e.: you can share what is playing on mpv on another device which is called the 1st screen.

I downloaded the sample code from the DIAL website and also looking at the specification there is nothing about sharing a video/audio stream. I guess that is a Chromecast specific protocol that sits on top of DIAL?

[lidel]

I did some research and there is an additional layer called RAMP, which is not documented well.
Projects at github more or less reverse-engineered it, as people were too anxious to wait for official documentation, which I hope will be published after Developer Preview period.

My high-level/simplified understanding of what happens after DIAL discovery is that Sender (mpv) posts URL to Receiver (cast-enabled device) via RAMP. Then Receiver just... plays it on its own from URL via simple HTTP GET.

To make it work Sender needs to act as a HTTP server (and optionally a transcoder, if Receiver does not support codec etc). For example Fling project provides a way of casting local (optionally transcoded) video to a DIAL device with a help of.. VLC's built-in HTTP server.

I wonder how complex would it be to implement all these moving parts inside of mpv and to be as easy to use as selecting just another video output driver: -vo dial:cast-device-name
Perhaps we should just go with a separate tool such as Fling and drop the idea of supporting DIAL inside of mpv?

What is your view on this?

PS. Quick digression about requirement of having dedicated device, if someone wants to play with it anyway:
The official Chromecast SDK is still in Developer Preview and to use a custom Sender App you need to whitelist your device. If you have an Android phone or tablet, you can turn it into a Chromecast for free with an app called CheapCast without the need of any whitelisting. There is also a desktop emulator called leapcast, which may be useful too.

[pigoz]

RAMP looks very similar in concept to Apple's AirPlay where you expose the h264 stream over HTTP. There would literally be no benefit of using mpv to do this (you would not be using the mpv ao/vo/filter chains/timing code).

You just need a HTTP server and a transcoder to make this work!

[ghost]

Not really sure how this should be handled.

[AndreasA]

Any news regarding this? VLC is also currently working on Chromecast support.
Do you intend to support it in the future or will it "never" be supported?

[ghost]

Nothing new. I don't even know what this is about or what it has to do with mpv.

[AndreasA]

chromecast is a HDMI "stick" that you can plug in your TV and the nstream fotos/videos/music from any device and app that supports it via W-LAN.

So in case of mpv it would be the support to stream music and videos to it.
http://en.wikipedia.org/wiki/Chromecast

It is also relatively inexpensive ( < 35 Euro).

Though it not the only device that goes in that direction.
For instance something independend of the application (works with iOS, Android, Windows, Linux, Mac):
https://airtame.com/
but is more expensive and not yet released.

[ghost]

But mpv is a video player, not a streaming server...

[AndreasA]

It is a different kind of streaming then a streaming server actually. You do not initiate playback from the Chromecast but from an application which supports e.g. video on e.g. your Android phone or iPhone or Windows (if it is supported), e.g. Chrome supports playback as far as I know.

[lidel]

@AndreasA VLC ships with streaming and transcoding tools built-in, while m[player]* (in my opinion, after removal of mencoder) aims to do one thing right: playback.

If you want to send videos to Chromecast use something like /stefanor/chromecastplayer (or write your own with pychromecast).
If you have videos that are in format which is not supported by Chromecast, you may transcode them manually via ffmpeg, or use a script like /bc-petrkotek/chromecastize.

(If you find better alternatives, please post link in a comment here, as it may help other people with similar needs.)

[emk2203]

@lidel https://github.com/xat/castnow seems to be the most interesting way to send stuff to chromecast. It can transcode to mp4 and accepts torrents, local files and URI for casting.

With close to 1000 people starring it, it's the most popular program here for this purpose.

[ghost]

You can consider chromecast as a monitor, so showing it as a renderer seems correct to me.

Then Xorg or Wayland should add chromecast support.

[snaggen]

No, Casting should not be implemented on Xorg/Wayland level since it is a lot more specific than a monitor. When you cast a video stream to a chromecast, you expect it to show only the video stream with audio and nothing else, like notification popups and different desktop sounds. So casting should be implemented on the application level.

[bartenbach]

+1

[akvadrako]

From the user's perspective, casting is the job of the video player, because you want the local controls and capabilities of your normal player, plus the ability to switch between local and casted playback. It's really just a special output device.

[Qwerty-Space]

↑ This.

Instead of sending the video to your monitor, it sends over LAN to another supported device.

However, I do believe it should be a plugin.

[ghost]

7 years later and this still seems like an absurd idea to me. To really make the "remote" output device behave like local video, it'd have to transcode it, which will use a loot of power and reduce quality, and even then the behavior would be nowhere near local. For example, pausing and unpausing would necessarily have a noticeable delay.

I don't know if there are "cleverer" implementations, but it doesn't get less dumb.

[philipl]

There are apps out there that do local transcode and transmit, but the only efficient way is to play back material that's already in a format the cast device can play natively, and in either case the app is just a controller, and not doing any actual media playback tasks.

[ghost]

That would make even less sense for mpv.

[sebma]

@wm4 Most videos available on the net come from youtube (big video provider :-D, just kidding) which can provide the mpeg-4 (avc+aac) format.
The latter format does not need to be re-encoded to cast it to chromecast devices.

In the meantime, why not pipe the output of mpv to castnow ?

So I tried this but it does not work so I need help outputing mpv output to a pipe correctly :

$ mpv --no-config --ytdl-raw-options-add='sub-lang="en,eng,enUS,en-US,fr"' https://www.youtube.com/watch?v=-9sWEf_6ZS8 --o=/dev/stdout | castnow -
[encode] format not found
Encoding initialization failed.

Exiting... (Fatal error)
Error: Load failed

[CounterPillow]

mpeg-4 (avc+aac) format

If you're going to lecture multimedia developers about multimedia you should probably not do it like this. The MPEG-4 you're referring to is a container. I'm assuming by putting avc+aac in parenthesis, you mean to say that this implies those codecs. It does not automatically imply AVC+AAC, but AVC+AAC is a popular choice for it. However, AV1+Opus can be in MPEG-4 too. Or MPEG-4 Part 2 + MP3. But even if we assume every .mp4 contains only AVC with AAC, it gets a bit hairier because there is a lot to AVC

The latter format does not need to be re-encoded to cast it to chromecast devices.

Not always the case. This depends entirely on the used level and profile of AVC. H.264 baseline? Sure, will work. H.264 main? Probably also very widely supported now. H.264 High? Oh now we're getting spicy. Level > 4.2? This is getting a lot less likely. 422? 444? Hi10? Predictive? Yep this won't work.

Not to mention how any subtitles will probably be lost too.

Let's restrict it to only things youtube generates then, which then leads us to the next question: why use mpv for this? You're streaming video from a Google service to a Google device through mpv for what reason? It seems like what you actually want is something that remuxes the DASH stuff from youtube-dl and then sends it into castnow, without any reencoding.

[akvadrako]

Most video players with casting ability do transcoding - sometimes always. Usually subtitles are sent as is.

[ghost]

In the meantime, why not pipe the output of mpv to castnow ?

What advantage would that have over just passing the video file directly to castnow?

[CounterPillow]

So you'd need something that:

1. Automatically figures out when to transcode, based on
   • input format
   • chromecast device supported playback formats
   • CPU performance of the device running mpv
   • available hardware encoders in case we have bad CPU perf but good wifi
   • bandwidth of the wifi connection to the dongle
   • whether the output device supports the subtitle format of the input file
2. Behaves like a media player except for when a special button is pressed, in which case
   • it begins either transcoding or remuxing the video stream from the current playback position on
   • it exposes this output through a locally started HTTP server as HLS/DASH
   • it tells the Chromecast device what URL to fetch this from
   • it then acts as a remote control for this completely separate media player that is the chromecast device
3. Resumes behaving like a media player when the button is pressed again
   • keeping track of what playback position the chromecast was at before its casting was tragically cut so short
   • stops remuxing, transcoding, shuts down the HTTP server
   • makes the remote control behave like a media player again
   • actually starts feeding the video stream into its own core playback loop seeking to the playback position

This does not seem to make this a "special output device", but something that is so far removed from mpv's core playback purpose it's difficult to imagine how this can be fit into mpv. It seems to me to be a much cleaner design if you make an application that makes use of libmpv, but has its own chromecast-specific logic to run outside of mpv's playback logic, only using mpv as a player for local playback but hiding this from the user.

[sebma]

@CounterPillow I was talking about the avc+aac format provided by youtube, but then, you're right, not every avc profile will be supported as it is by chromecast devices.

I didn't mean to lecture multimedia developers about multimedia.
If that was perceived this way then I apologize.

[sebma]

@wm4

In the meantime, why not pipe the output of mpv to castnow ?

What advantage would that have over just passing the video file directly to castnow?

The argument I gave to my mpv command example was a URL not a file.

Anyway, I have another workaround since mpv uses youtube-dl to fetch the "direct" URL of the video stream, one can cast any URL supported by youtube-dl this way :

\youtube-dl --ignore-config --no-continue --embed-subs --write-auto-sub --sub-lang="en,fr,es,de" -o- -- https://www.youtube.com/watch?v=-9sWEf_6ZS8 | castnow --quiet -

With this method neither seeking nor subtitles are supported but other controls (pause/play/vol UP/vol DOWN/stop) work fine.

[akvadrako]

This does not seem to make this a "special output device", but something that is so far removed from mpv's core playback purpose it's difficult to imagine how this can be fit into mpv. It seems to me to be a much cleaner design if you make an application that makes use of libmpv, but has its own chromecast-specific logic to run outside of mpv's playback logic, only using mpv as a player for local playback but hiding this from the user.

I thought mpv was a movie player, not just libmpv. Indeed SMPlayer is something like what you describe. It uses mpv for local playback and also does casting.

Actually I don't like the cromecast protocol much because it's awkward and proprietary - it would be great if a program could sit in between mpv and chomecast which acts like a monitor with media controls; something that handles the transcoding also. The tricky part is you need a fairly broad protocol.

[ghost]

mpv is a media player, not a media server.

[akvadrako]

These days, casting is an expected feature for media players.

[ghost]

We don't really give a shit what's expected, though.

Realistically, at most you could probably implement a Lua script that does the remote control part, and mpv might offer a way to output the raw media stream to a FIFO or so (like --stream-dump).

[snaggen]

And let's face, with that attitude towards the users you ensure that the feelings are mutual... To be honest, I don't give a shit about this project any longer. VLC imlements features the users want, like proper chomecast support... So, that is what I use. And while I had hopes for this project once, you just made it clear that this is not the project for people hoping for a user friendly media player.

[ghost]

If VLC works for you, that's great, but please stop trolling our issue tracker.

[snaggen]

I'm not sure I am the one with the trollish attitude here...

[ghost]

Well, you're the one who threw a tantrum after it's been explained to you how this feature doesn't really make a lot of sense in this project, and/or how this would raise a lot of unsolved problems. Add the fact on top that the chromecast protocol is proprietary and needs to be reverse engineered, that using transcoding or URL passing instead of a HDMI cable is a grossly inefficient method for sending video to a display, that none of mpv's advantages and features could be effectively used with casting (the receiving device would decode and render video, perform seeking, caching, and all these things which mpv puts major effort into to do them right), and that you could write a 4 lines Lua script to turn mpv into a "controller" for castnow which would achieve the same (for example relaying the source URL and pause/seek commands), and that there is tons of other software that exists to make chromacast accessible to the lowbrow user.

It's very much a trollish thing to claim that just because this feature wasn't implemented we'd reject "user friendliness". You could raise the same tantrum about having a "full" GUI, a media library, turning mpv into a streaming server, and other stuff. That doesn't change that such broader things are out of scope of the project, and are at best something for a project that uses mpv.

And last but not least: fuck shitty users like you, life is much better without them.

[CounterPillow]

And let's face, with that attitude towards the developers you ensure that the feelings are mutual... To be honest, I don't give a shit about this user any longer. wm4 imlements features he wants, like proper scripting support... So, that is what I use. And while I had hopes for this user once, you just made it clear that this is not the user for people hoping for a well designed media player.

[snaggen]

@wm4 I only reacted to your comment about not giving a shit... but what ever makes you feel better.

[Qwerty-Space]

why use mpv for this? You're streaming video from a Google service to a Google device through mpv for what reason?

What advantage would that have over just passing the video file directly to castnow?

1. Google Chromecast isn't the only device you can "cast" to. Viera TVs and Amazon FireSticks are also an option.

2. youtube-dl supports more than just Google services

3. We would like to use mpv controls and configuration for casting.

MPV supporting castnow via a hotkey would be very cool.

[shmerl]

One common use case is a wireless projector. Ideally, you could attach a projector over DisplayPort cable, but wireless connection (over WiFi for instance) offers some convenience. So being able to cast to such device is useful. But if the point is that mpv is the wrong tool for it - that may be. VLC at least supports it.

[ghost]

I maintain that this wouldn't be useful for something like mpv. What is the point of using mpv if you don't use its playback engine, and just as glorified remote control? You could as well use a browser or a phone or something to "cast", or if you prefer the command line, use castnow (or, as it was said, write a mpv script that uses "castnow"). I really don't understand what users want here, why they keep prodding this after everything was explained over and over again in thorough details, and to be honest, it fucking freaks me out. It's a bit like someone making a feature request to add facial recognition to mpv, or to use it as drive control software for self-driving cars. What the fuck?

Unless you want mpv to be a media server, which is a nice idea, but would require some major work.

Also I don't have a single device that does/accepts casting, and the way this class of hardware is increasingly aggressively bullshit with builtin spying on you, I don't plan on getting any.

[pigoz]

What if I want to cast chinese cartoons to my smart washing machine? My smart washing machine has a really nice display.. it would be a waste of money not using it! I'd use VLC just to spite you, but I don't speak chinese so I need the subtitles.

[vlad88sv]

I reached this post looking to see if MPV had something like VLC (they integrated Chromecast as a renderer) but then I found Kodi and Plex and I think they serve a better purpose than mpv for this task.

Still I consider that it's not about making an app a "glorified remote control", but I often watch things in mpv on my Ubuntu, but then I have to move to another room, I have to close the video, open it on VLC, seek the correct time and then I cast it to the new room.

When I go back to my Ubuntu PC I say "fuck it" and then I keep using VLC from that point until the next day

[CounterPillow]

I spot the ill-fated issue's title in my list of notifications. Sweat beads start to roll down my forehead as I struggle to keep my hand steady moving the mouse cursor over it. I close my eyes, breathe in slowly, and hold my breath as I click the link. The page goes blank, in a perfect mirror image of my mind. Then, text appears, words upon words, black on white, the utterings of the past echo through my head as the loading indicator finishes its cursed journey. I exhale. I am here now, my eyes quickly fleeting over the text of the latest comment. I read it in its entirety, my breathing now sharp and rapid. Words jump out at me, "Kodi", "my Ubuntu", "VLC". My eyes begin rolling into the back of my head as The Dark Lord Satan overtakes my fleshy mortal form. My hands, strained and shaking like those of a madman clinging onto his last bit of sanity, move to the keyboard. They begin to type; the words are as clear in the text box as they are in my mind: "chromecast big doodoo lmao"

[ghost]

You can write a script that invokes castnow, and bind it to a key. Where's the problem?

[vlad88sv]

So I read almost all the comments to understand why it was not supported and why it won't be supported; and https://kodi.tv/ and https://www.plex.tv/ are the perfect solution instead for my use case.

Also I think after reading @CounterPillow "answer" I'm not really looking for a "mpv solution" at this point, but thank you @wm4 for suggesting it.

[ghost]

I suggested this before your first post and before CounterPillow suggested it, but thank for being one of Those users.

[ctxcode]

Just a note, it's 2020 and there are 0 media players in the world that fit my needs. I just want a simple media player with the most simple interface (vlc,mpc,mpv) that can switch to my tv when i want to sit in my couch. I would use vlc, but the freaking "always on top" function is broken and im 10000% certain it's not me, but a bug in the player and reinstalling vlc or even windows itselfs, does not fix it. Nor running as admin or any other solution. So i came to look here. but nope. anyway, good luck with the project.

[JJRcop]

If nobody wants to do the work then this won't happen, but for now if you are using mpv for the easy ytdl hook and want to cast that, you can use catt https://github.com/skorokithakis/catt

[sebma]

@JJRcop Thanks a lot for that catt link !

[maop]

Surprised nobody mentioned Jellyfin, is super simple to install and use, i highly recommend it over kodi/plex. I use mpv for everything in my pc for youtube, twitch and random videos, but i too was tired of having to open VLC to cast a movie or anime so i installed jellyfin in my homeserver, i just transfer the file and by the time i'm in the couch, it already recognized the new media and catalog it by show/movie/anime/etc, what season/episode and all its metadata, thumbnails, actors, resume, etc.

[sebma]

@maop Is Jellyfin found on https://jellyfin.org ?
Can it handle the playback of videos from sites handled by yt-dlp ?

[JangoFettHD]

+1

[Disonantemus]

+1