The real shame is that it had to exist in the first place and that DLNA was never adequate for this.
Of course this isn't a general solution since it requires patching the binary instead of having some other way to use custom keys (they compile them into Chrome today, and of course other devices are even more closed).
0 - https://github.com/thibauts/node-castv2/issues/2#issuecommen... 1 - https://bugs.chromium.org/p/chromium/issues/detail?id=809249
Upnp was build for home automation so i guess it was too ambitious considering the company political minefield. Its successor dpws lives in an equally strange niche now: printer autoconfiguration. The open source community never cared much to provide robust free implementations. (I wrote upnp and dpws gateways for smartdevices more than 10 years ago and the situation hasnt changed since)
I think that's a mischaracterization. Given two identical experiences, one that locked you in and one that didn't, I'd imagine most people (though sadly not all) would choose the more open one.
The locked in experience here is simply substantially more seamless and out-of-the-box ready than the open alternative. Given that the point of a handover system is to make using multiple devices seamless, it's obvious that being "more seamless" is an advantage.
I setup a Chromecast for my mother who doesn't have cable or anything at home, and it took several explanations spread out over a year before she finally started using it on her own, but now she's using it daily. Any harder to use and it wouldn't have been helpful at all.
She's not exactly a luddite either, this is actually the first thing I've tried to teach her that she's struggled so hard with. Hopefully it's not a sign of aging...
You want some video to appear on the TV, so instead of driving some thing that's attached to the TV, you cause that thing to pull the video, using your phone or other device. It has never "clicked" for me.
Think of it like pushing the video you're watching to the other device. You're taking the thing you have and throwing it onto the TV.
It's less confusing if you don't think too hard about it.
You should be saying that the phone is a remote control.
That is both what's actually going on, and a paradigm everyone understands. And it's a stupid short and simple phrase to say. They've ingested it before they even got a chance to subconsciously go into "I don't want to try to figure this out." mode.
I would also say while giving that explaination something like "It's not you. Google intentionally makes this confusing because they want you to think you are casting or projecting something for who knows what marketing reasons." Takes the bad feelings of not understanding something off their shoulders and lets you both comiserate over a 3rd party, Google, and any stress is is laid on them instead of you or themselves. "You find this confusing and difficult, and guess what, so does your sysadmin son! Google is annoying but you & me will get it anyway."
> That is both what's actually going on, and a paradigm everyone understands. And it's a stupid short and simple phrase to say. They've ingested it before they even got a chance to subconsciously go into "I don't want to try to figure this out." mode.
I just finished saying that this strategy did not work for me for nearly a year, but please, tell me more.
Explaining it as a remote control is way more confusing because it doesn't behave like any remote control you've ever seen. Every other remote control (short of niche techie phone apps or expensive Logitech remotes that these users have never seen before) is a system where they press buttons to navigate menus or change things directly on the TV. This system requires them to select something on their phone instead, which is very confusing with the remote analogy.
> I would also say while giving that explaination something like "It's not you. Google intentionally makes this confusing because they want you to think you are casting or projecting something for who knows what marketing reasons."
I don't think it's marketing reasons. I think that unless you're super technical, it's just flat out an easier metaphor for people to understand.
Hell, even with an understanding of what's actually going on, I still don't think it's inaccurate. The lie is just that you're taking the source URL and credentials and casting them to the TV, rather than casting the content itself. But you are definitely moving state from one device to the other, and that's the metaphor the device is built around.
Although there concept is simple: your phone is the remote, you need to connect to the TV. The app you would normally play it on, shares it to the TV.
I don't know how to explain it more simple
Here's simpler:
Start watching something on your phone. Now hit this button, this is the button to send what you're watching to the TV. Now choose the TV. See, it's stopped playing on your phone and picked up on the TV from right where you were.
Other than the need for the two devices to each be connected to the same Wi-Fi network and the non-obviousness of being able to use your phone for other things once you start casting, I find it generally seamless, bit again I'm an 'inmate in the asylum' :)
I think it's sort of like what the other reply was talking about. Thinking about getting something onto the TV by opening something on her phone and then hitting some buttons was confusing.
I started presenting it as a process where you take something on your phone and push it to the TV, and I think that helped.
Instead just tell them to watch something on their phone. Then press this button and it sends it over to the TV instead. End of instructions. This was what finally made it click for my mother.
I don't think this is true or fair.
Competition in capitalism is the reason companies create ecosystems like this in the first place (and also different adapters ;P).
If we (the society) would reward interoperability and punish lock-downs e.g. because they are bad for customers and harm the environment the market would have no choice but react to this.
But because it is not like that we will suffer adapter-hell and missing interop until we dedicate enough effort, tears and blood to hack together systems that kind-of-work for some time (I've been there and done that, learned a lot and lost a lot of time and nerves in the process).
I only invest in ecosystems because it saves time and I can do what I intended to do instead of hacking and slaying my way to it. I hate the lock-down and if we would have more open alternatives I would jump on it in a minute but so far the open source world just can't offer some of the services/protocols/features that I just want to use.
When possible I still hack and I admire many very skilled people in this area so please don't get me wrong. E.g. I just jailbroke my iPad to get UTM (QEMU for iOS) running to break out of the "shiny apple ecosystem" but it is again more hacking and playing than doing some serious work or "just using stuff as it was intended to be used".
It is not the fault of the consumer alone while I am sure a rational consumer would put more knowledge and effort into politics and consumption to get companies more aligned with what is good for the planet and the people.
As long as most people only buy and never complain or do something about it this will probably not change.
My PC would show corrupted video streams, my iPhone worked via an included app but lacked any sort of context awareness (just blindly mirrors the screen) and doesn’t work well with DRM
I finally caved in after all these years and got an Apple TV and it’s so much nicer of an experience, even looking strictly at mirroring.
Apps are context aware to the fact they’re mirroring, much lower latency from my PC (despite using a 3rd party app), no weird dependency on WiFi for initial pairing (Window's native mirroring won’t work with my Miracast device because my PC doesn’t have a WiFi card installed)
I don’t know if it’s an ecosystem problem for Miracast (I’m pretty sure the only “high quality” implementation of it is the Microsoft adapter, but there’s an ocean of dongles that “support it”) or a technological limitation, but it wasn’t good
https://www.reddit.com/r/TheExpanse/comments/8ty16z/a_techno...
Lots of people dislike X11 and even more dislike the naked protocol.
It seems to work well from Windows 10 though.
Both bring angry geeks for different reasons, but as long as most people reward them for being locked up in a closed ecosystem, I don't see why they would change.
One of the things that kills these common standards is that every company has to tack on its own obscuring trade name. DLNA, HDMI-CEC, probably others I can't remember have all had this.
It's kind of a wonder that SMTP managed to be known as just "email", but even that is largely eroded into branded experiences.
DLNA could, in theory, be all things to all people, but like similar "all things" it's such a pain in the arse to get renderers and servers all talking to each other it never really "just works".
Of course, all of that wouldn't necessarily be a problem except that Apple and Google are deeply invested in non-compatibility.
The audio only version of AirPlay (AirTunes) goes back a decade before Miracast, and the version that also supports video predates Miracast by two years.
It would be nice to be able to add an iOS plugin to add system wide support for Miracast instead of just having some apps choose to support it.
I don’t know where the failing was, but it really only worked reliably when the compute device and TV were from the same manufacturer. Cross-vendor compatibility was hit or miss.
(It also didn’t help that different vendors used their own proprietary name for their Miracast feature - most users have no clue what Miracast is.)
https://arstechnica.com/gadgets/2019/11/google-is-killing-go...
(At one point open bluetooth was a thing, immediately exploited to drop dick pics to random strangers on public transport)
Given a box being able to reach Chromecast via standard IP routing and Chromecast being able to reach the box via a standard IP routing and a box being able to spinup a HTTP(s) sever one can cast to Chromecast. No need to be on a same network.
Catt does it.
The only thing being authenticated does is allows me to set the timezone, change the background art, and re-name it, which are all secondary features I don't need.
Don't think the common enduser would agree with that.
The largest use case for something from Plan9 is 9P transport used by QEMU to share host folders with guests.
For example Plan 9 was released in a market where UNIX was already successful and "good enough". So it was always going to be a tough sell. Whereas BeOS was released in an era when desktop OSs totally sucked (NT wasn't yet ready for home users, Windows 9x was an unstable mess, Mac OS 8 and 9 were even worse than Win 9x, Linux wasn't even remotely ready for the casual user and Atari / Amiga dead and becoming increasingly irrelevant in all but a few niche scenes). Even at that time it felt like desktop operating systems sucked and then along came BeOS and proved just how much better things could be. It felt light years ahead of the competition and yet still failed (I'm not bitter at all!)
It's also worth noting that Plan 9 did go on to influence UNIX and Linux quite a lot since. So while 9P transport might superficially feel like the only Plan 9 tool to survive (it's not because people do use other stuff like ACME), there's a lot of Plan 9's influence in modern *nix too (eg FUSE).
This does not pass the smell test. I can cast onto any of my Chromecasts using VLC and Catt[0] and while the former is limited to media, Catt lets me render websites just fine.
I believe Catt's author is on HN.
However I'm still unclear... if the goal is to render output on Chromecast, a combination of ability to render web pages, video and audio streams and images seem to cover pretty much everything needed to interact with the device.
I believe the applications have to be registered with Google? (Who presumably can ban them?)
My point is why not push media/web pages using something like catt bypassing all the mess? I certainly see the appeal of using anything with HDMI port to push the media out but RPI and likes aren't anywhere close to Chromecast dongles in polish and what one needs for adoption is ease of use.
The point is we already have a cheap HDMI renderer that can be connected to a network, has a fantastic form factor, most of the needed features, is so incredibly brain-dead simple to use that my wife's mother who can't make a programmable coffee machine work took less than 10 minutes to connect it to watch Netflix and is available in Walmart/Target/BestBuy/OfficeDepot/Staples etc.
The biggest enabler of non-restricted casting would not be a renderer interface. It would be an easy to integrate library in non-geek languages (i.e. not C/C++/Rust/Go but Python, JavaScript, PHP, Ruby, Perl, etc ) with interfaces like PlayMediaFile(chromecastid, url) and RenderWebPage(chromecastid, state, url) to drive a Chromecast from a local box/smartphone without having any support from a content provider.
I have been playing with Jellyfin/Plex/etc recently and they are atrocious in the UX for anyone who is not invested in making them work well because they all try to solve all of the annoying problem of handling and organizing media libraries, pulling media sources together and interfacing with casting devices. They do everything OK, but do nothing well. Give their authors a solid way to cast to Chromecast that just works and we will have an explosion of content to TV solutions.