TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Use Unix Pipes to Improve Chromecast Playback

174 点作者 lowmemcpu将近 5 年前

13 条评论

fooblat将近 5 年前
My friends often tease me because I read the manual from everything I buy. Even if it is a tiny pamphlet.<p>I really like this informative blog post on unix pipes, but reading the readme would have saved some time.<p>It contains the answer in a simple form:<p><pre><code> `youtube-dl -o - https:&#x2F;&#x2F;youtu.be&#x2F;BaW_jenozKc | castnow --quiet -`</code></pre>
评论 #23677849 未加载
评论 #23678277 未加载
评论 #23678194 未加载
评论 #23685539 未加载
gregmac将近 5 年前
So this (and I assume every other solution people have mentioned) are using youtube-dl -- which means the chromecast is playing a stream from the device initiating the cast.<p>When I cast from my Android phone to a cast receiver, my understanding is it&#x27;s basically sending the URL to the receiver and my phone is no longer involved, other than as a remote to control position. (And frustratingly, I find my phone will often get disconnected even though the video is still playing, so I have to spend several seconds waiting or forcing it to reconnect to be able to pause&#x2F;stop).<p>What&#x27;s the difference between these two modes? Is there something preventing the URL method from working, or is there a reason it&#x27;s preferable to download + stream?
steve_adams_86将近 5 年前
Maybe this isn’t a great place to ask, but:<p>I’m so sick of my chromecast. The audio and video issues are absurd. I have a fibre connection but I can’t manage to keep a 1080p cast working from my machine, and Youtube frequently stutters and lags.<p>Sometimes I go to Apple’s website and almost buy an Apple TV, other times I think about something more DIY like a raspberry pi media centre.<p>But what I wonder is... is all of this stuff shit? Do I just stick with my chromecast? Maybe I’m just fooling myself that spending money and switching would be any better.<p>Reading this just reminded me of how obnoxious my chromecast is.
评论 #23675951 未加载
评论 #23675769 未加载
评论 #23676792 未加载
评论 #23675802 未加载
评论 #23678117 未加载
评论 #23677924 未加载
评论 #23676990 未加载
评论 #23677457 未加载
评论 #23675824 未加载
commotionfever将近 5 年前
maybe I&#x27;ve missed something, but `catt` supports youtube natively.<p><pre><code> $ catt cast https:&#x2F;&#x2F;youtube.com&#x2F;watch?v=xxx $ catt add https:&#x2F;&#x2F;youtube.com&#x2F;watch?v=xxx </code></pre> the latter will even add to your existing youtube chromecast queue<p>(it&#x27;s using youtube-dl in the backgroud, but no need to mess about with pipes)
评论 #23678330 未加载
Bnshsysjab将近 5 年前
I’ve never figured out if it’s possible to stream to anything that’s not a chromecast, e.g pc -&gt; phone, or phone -&gt; pc. Are these possible using ‘cast’ technologies available in iOS and Android?
评论 #23677591 未加载
steerablesafe将近 5 年前
Re seeking: instead of pipes one could probably use youtube-dl to dump the url and use a fuse filesystem to mount the url as a seekable file (it is typically implemented as range requests). I found httpfs2 [1] in the Debian repositories [2].<p>[1] <a href="https:&#x2F;&#x2F;sourceforge.net&#x2F;projects&#x2F;httpfs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sourceforge.net&#x2F;projects&#x2F;httpfs&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;packages.debian.org&#x2F;sid&#x2F;httpfs2" rel="nofollow">https:&#x2F;&#x2F;packages.debian.org&#x2F;sid&#x2F;httpfs2</a>
knorker将近 5 年前
Uhm, the castnow readme has an example of how to cast from stdin. Are you saying that doesn&#x27;t work for you?
jeffbee将近 5 年前
What does the author mean about the &quot;final update&quot;? Is the original Chromecast really not getting any new software?
评论 #23679169 未加载
评论 #23678829 未加载
评论 #23678313 未加载
mnw21cam将近 5 年前
Is there anything particularly wrong with running:<p><pre><code> youtube-dl -q -o - &#x27;url&#x27; | castnow &#x2F;dev&#x2F;stdin</code></pre>
评论 #23676885 未加载
frafra将近 5 年前
I wrote something similar 9 months ago (just relying on VLC functionalities + youtube-dl + avahi) and I have been using it since then (but less elegant): <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;frafra&#x2F;9f5770c6af6e4dcdf91ba815225e5e65" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;frafra&#x2F;9f5770c6af6e4dcdf91ba815225e5...</a><p>The main problem I have is that it is not possible to easily resume the stream when youtube-dl stops working and you use a pipe or mkfifo. It would be cool to be able to rerun the program again and continue from where it left, but some streams are not seekable, so you would need to restart the software automatically, consume or skip the first part and start adding the new content at the end of the FIFO device.
Foxboron将近 5 年前
&gt; ip=$(dig +short chromecast.lan | tail -n 1)<p>This line requires some mdns server setup I believe. I didn&#x27;t like running avahi and thought there should be some super simple client for this, but after searching I didn&#x27;t find anything.<p>I wrote up 10 lines of go which spits out chromecast devices as json and use jq to get the appropriate IP. Works quit well and now I have a fairly seemless way to play videos to my chromecast from qutebrowser.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Foxboron&#x2F;mdns" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Foxboron&#x2F;mdns</a>
sdfhbdf将近 5 年前
It&#x27;s a nice solution to a problem that the author found. I am afraid that knowing Google&#x27;s walled garden around Chromecast, the `castnow` and `catt` utilities might have trouble staying afloat.
评论 #23677027 未加载
barbegal将近 5 年前
What are the advantages of using a named rather than an anonymous pipe?
评论 #23675753 未加载
评论 #23675768 未加载