HN Explorer

Show HN: ytcast – cast YouTube videos to your smart TV from command-line (github.com)

227 points by marcolucidi ↗ HN
hi, this is a project I've been working on and off for the last three months, it's my first non-trivial, non-hello-world, actually useful (at least to me) go project. it would be very nice if you could just try the program and see if it works on your setup!

the readme[0] explains how it works, why I wrote it and how it fits in my "command-line centric" computing environment (there is also a video demo[1] :)).

if you know go, feel free to take a look at the code and review it! I'm still pretty much new to go and I'd love to hear opinions, feedback and tips from more seasoned go developers :)

[0]: https://github.com/MarcoLucidi01/ytcast#ytcast

[1]: https://www.youtube.com/watch?v=07aWOpi8DVk

56 comments

[ 3.0 ms ] story [ 127 ms ] thread
[deleted]
(comment deleted)
jlkuester7
Nice! Projects like this give me hope for Chromecast support one day from Android devices not running Google Play Services (e.g. GrapheneOS)...
marcolucidi
thanks!

as already said, ytcast won't work "directly" with chromecast since they use a different protocol, but there are other projects linked in this thread which work very nice with chromecast!

stavros
CATT (which I wrote) does the same, except it supports whatever site youtube-dl supports (which is basically everything):

https://github.com/skorokithakis/catt/

rahimnathwani
OP seems to work for any Smart TV with a YT app (e.g. a Samsung or Roku TV), whereas CATT requires a Chromecast?
stavros
There are various protocols for TVs to cast things, it seems like this one uses DIAL, whereas CATT uses Google Cast. I was thrown off by the icon, it does seem like the two are slightly different, thanks for the correction.
rahimnathwani
FWIW I didn't know about CATT, and I actually have some use for it. I sometimes want to cast local video files from my PC to a projector on the other side of the room. That already has a Chromecast so CATT should make it easy.
marcolucidi
yes, ytcast should work with any DIAL enabled device that supports the YouTube on TV app, so it doesn't require a specific device, but it's limited to YouTube videos.
[deleted]
(comment deleted)
[deleted]
(comment deleted)
igravious 

   groobiest@NH5xAx ~/Code/ytcast [master]  ytcast -l
   ab5d4550 192.168.1.2     "[LG] webOS TV OLED55C16LA"    
   groobiest@NH5xAx ~/Code/ytcast [master]  ytcast -d lg https://www.youtube.com/watch?v=VZx-rLoV4do
   

   groobiest@NH5xAx ~/Code  ~/.local/bin/catt scan
   Scanning Chromecasts...
   Error: No devices found.
   𝑥
marcolucidi
cool! good to know about catt! unfortunately i don't have a chromecast to trying it out.
winstonschmidt
Great tool! Does going through ytcast have any impact on whether the played video influences youtube's recommendation algorithm (which annoys me a lot)?
marcolucidi
thanks! yes, unfortunately the algo is still influenced because ytcast "tells" the YouTube on TV app to play the videos.
e12e
Thank you for taking the time to describe how it works in the readme. I loathe "magic" - and love seeing the mechanics of how stuff like this works. Makes your project useful to me, even if right now, I rarely have computer (with a cli) close to my TV.
marcolucidi
i'm very glad you appreciated that!

> I loathe "magic" - and love seeing the mechanics of how stuff like this works.

yeah me too :)

heavyset_go
How does this differ from, say, catt[1]?

[1] https://github.com/skorokithakis/catt

marcolucidi
i learned about catt in this thread and i never used it, so i may be wrong about something, but these should be the main differences:

- they use a different protocol for device discovery, catt uses mDNS, ytcast uses DIAL.

- catt requires a chromecast to work, ytcast should work with any DIAL enabled device that supports the YouTube on TV app.

- catt can cast from many sources including local files, ytcast merely "tells" the YouTube on TV app to play videos, so it's limited to YouTube.

heavyset_go
Cool, thanks for the explanation. I'll give your project a spin.
sahinabi
Thank you for the project and detailed readme, very helpful.
marcolucidi
thanks, very glad you liked the readme :)
pmoriarty
Hopefully this offers some way to avoid the ads, like youtube-dl does.
marcolucidi
unfortunately it doesn't, it merely "tells" the YouTube on TV app to play videos.
rolandog
Ooh, nice! I'll be giving it a try today or tomorrow, as I had been having trouble with MkChromecast.
Loranubi
So if I don't want to get a HDMI cable to connect my TV, but happened to have a network connection instead I would use that?
marcolucidi
yes? i mean for YouTube videos yes (if your tv supports the YouTube app and DIAL protocol).
sharmi
ytcast search functionality is a great feature. When I come across a video that would be interesting for my kids, I cast it on tv. Now I don't need the url to cast, I can just search by the text.

Castnow, mentioned elsewhere in the thread, seems to be able to cast videos saved on the laptop directly. Our usual routine is to copy to pendrive, move to TV and then switch the TV source to usb. This would be a welcome addition.

marcolucidi
thank you! the search video functionality is not builtin into ytcast, but is actually a separate script (ytsearch[0]) so you can use it with other tools!

> cast videos saved on the laptop directly.... This would be a welcome addition.

yeah i know this would be great, but unfortunately it's unfeasible with the current implementation. what ytcast does is merely "telling" the YouTube on TV app to play videos.

[0]: https://github.com/MarcoLucidi01/bin/blob/master/ytsearch

1vuio0pswjnm7
ytsearch does not support continuation searches. (It only retrieves the first 15 results.)

Continuation searches occur when a user scrolls to the bottom of a search results page.

YouTube (or NewPipe, etc.) sends automated search requests to continue the search, triggered automatically via Javascript when the user scrolls to the bottom of the page.

YouTube continuation searches leak a large amount of unnecessary user data to Google.

1.sh[1] sends continuation searches manually and sends only the minimum ($MIN) data needed to fulfill the request.

It can be used to continue a search indefinitely over an extended period of time. Using an app like NewPipe, often recommended on HN, one could try to do continuation searches by repeatedly scrolling to the bottom of the search results page. However if one goes forward to view a result and then presses a back button, she will be returned to the first page the results, losing all the continuation search results. And if the browser tab or app is closed or crashes, the continuation search results are lost. It is easy to lose one's place when doing continuation searches using a Javascript-enabled browser or app. Using this script, this will never happen.

1.sh only uses TLS1.3 so no server certificate is sent in plaintext over the wire. Nor does it send SNI, i.e., plaintext hostnames on the wire.

ytsearch requires sed, column, awk, jq, fzf, and curl.

1.sh requires sed, netcat, stunnel and flex.

1.sh could be adapted to use curl but how does one disable SNI with curl.

Not to mention curl has a TLS fingerprint that sites may use to try to block requests or treat them with prejudice.

Usage for 1.sh is

   1.sh query; #<-- saves line-oriented JSON to query.yts

   1.sh << query.yts >> query.yts; #<-- appends more JSON to query.yts
To convert our line-oriented JSON to TSV, we can use line-oriented UNIX utilities. In general, this will be faster than jq and more robust for large files.

1. 1.sh is a 25 line, 1000 character shell script. https://news.ycombinator.com/item?id=30408770

marcolucidi
oh wow, that's pretty cool and impressive! thanks for sharing.

> ytsearch does not support continuation searches.... Continuation searches occur when a user scrolls to the bottom of a search results page.

true, I never bothered adding "continuation searches" feature to ytsearch because I very rarely scroll down to the second page of results. usually if what I'm looking for is not in the first 4-5 results, I just "refine" the search query.

ytsearch is a quick-and-dirty script that avoids me to open the browser for simple YouTube searches (I stole the idea from the initial version of ytfzf).

> It only retrieves the first 15 results.

that's not true, I always get more than 20-25 results on average and it's usually enough for my use:

    $ ytsearch foo | sort | uniq | wc -l
    37
> 1.sh only uses TLS1.3 so no server certificate is sent in plaintext over the wire. Nor does it send SNI, i.e., plaintext hostnames on the wire.

> 1.sh could be adapted to use curl but how does one disable SNI with curl.

that's pretty cool if you care about this kind of stuff!

> Not to mention curl has a TLS fingerprint that sites may use to try to block requests or treat them with prejudice.

yes I see how this could become a problem.

> ytsearch requires sed, column, awk, jq, fzf, and curl.

> 1.sh requires sed, netcat, stunnel and flex.

what are you implying here? do you think those 6 dependencies are "too much" for ytsearch compared to those of 1.sh?

anyway, it seems that the 2 tools offer a slightly different user experience out-of-the-box:

- 1.sh dumps json and can be used to continue searches without leaking too much data.

- ytsearch allows to quickly select a few urls and it's meant to be used interactively.

> To convert our line-oriented JSON to TSV, we can use line-oriented UNIX utilities. In general, this will be faster than jq and more robust for large files.

faster yes, but how it will be "more robust for large files" than jq? I always thought jq is the right tool for the job when dealing with json.

1vuio0pswjnm7
The number of results, as well as the schema of the JSON, might vary based on YouTube's "guess" as to the form factor of the computer being used to send the request. For example, when no User-Agent header is sent I have noticed sometimes web developers just assume the form factor is "mobile".

Providing a list of requirements is a courtesy for the reader.

[deleted]
(comment deleted)
[deleted]
(comment deleted)
phoronixrly
I found the magic behind "play on TV" so creepy that I made sure my LG TV was never to be connected to a network. I can achieve similar functionality via my libreelec box without proprietary software connected to my LAN.
mastazi
Is there something like a chromecast "server"?

What I mean: I have a Linux box connected to my TV - I want to know if there is a way to cast from a phone to the Linux box, by installing some software on the linux box that makes it appear as a Chromecast to other devices

35mm
Kodi has this feature for AirPlay, not sure if it works with Chromecast too.

Also maybe look into OpenMax + Raspicast

mastazi
Nice, thank you I will look into those
MayeulC
Chromecast is completely closed-source, I'd argue against buying into that ecosystem.

Nymphcast [1] is an alternative, but wouldn't be compatible with existing clients, since the protocol is different.

Miraclecast [2] is an implementation of miracast/wi-fi display that runs on Linux. There is also a myriad of alternatives: vnc, raspicast, etc.

Leapcast [3] used to be an implementation of what you want (while using chrome as a black box).

There are some implementations of airplay servers.

And lastly, a lot of media players implement some way of playing on one another (vlc, kodi, jellyfin, plex).

Funnily, you might just be interested in UPNP and DLNA. Support for these is quite robust, but it tends to disappear on newer devices (to the benefit of proprietary solutions like chromecast and airplay).

[1]: http://nyanko.ws/product_nymphcast.php

[2]: https://github.com/albfan/miraclecast

[3]: https://github.com/dz0ny/leapcast

mastazi
Thank you good list, and yeah I get that it's a closed source system but wouldn't it be cool if the FOSS community was able to reverse engineer it?

Thanks I'll look into the alternatives you linked

MayeulC
Even if it succeeded, it would be yet another cat-and-mouse game with Google, for little benefit. Of course anyone is free to work on whatever they want, and I might use it if a solution existed.

Nymphcast and Kodi work relatively well as a substitute, but aren't integrated in google's products like youtube (you can still use "share to" usually).

bncy
That's amazing, I often have problems with sending video to my tv, somehow chrome is not that good for it, thanks!
marcolucidi
thank you! another handy thing that ytcast does and that chrome / YouTube smartphone app don't do is to wake-on-lan my tv if it's off when i want to play a video.