Chromecast has been one of those smaller hardware products that have brought about a meaningful experience upgrade. The first Chromecast solved the pain point of clunky TV software interfaces, making it easier to locate content on your handy smartphone and then play it on your big-screen TV. However, a Court in the US has ruled that Google has infringed upon patents with its Chromecast products and that it should pay $338.7 million in damages because of it.
A Western District of Texas jury has ruled that Google has violated three patents held by a company called Touchstream Technologies, as reported by ArsTechnica. The complaint points to several Chromecast products, including the Chromecast Ultra, the Chromecast with Google TV, and other Chromecast-integrated products.
The first patent application in this complaint was filed in April 2011. The three patents relate to “a system for presenting and controlling content on a display device.”
Further, the complaint claims that Touchstream met with Google in December 2011 but was told that the tech giant wasn’t interested in partnering with it in February 2012. For reference, the first generation Google Chromecast was released in 2013. The latest Chromecast with Google TV (HD) was launched in September 2022, while the 4K variant was launched earlier in September 2020.
Chromecast with Google TV HD box 2 Google opposed the complaint, arguing that the patents are “hardly foundational and do not cover every method of selecting content on a personal device and watching it on another screen.” Further, the Chromecast is said to differ in technologies detailed in Touchstream’s patents.
The jury agreed with Touchstream’s allegations and ordered the company to pay $338.7 million in damages for its patent violations.
Google intends to appeal this decision, as mentioned by their spokesperson in their statement to ArsTechnica.
Miracast is plagued by latency problems, but it is still alive. Android itself still has support, it is the Nexus 6 that Google dropped support, to only support their Chromecast. Microsoft Xbox can be used as a Miracast receiver and there is support for Miracast built into Windows 10+, both as a receiver and transmitter. While Miracast was built upon Wi-Fi Direct, (Wi-Di, I believe), it has been extended to work over a wired network too. The biggest difference is that Miracast is transmitting the frames over the network, so that the device transmitting needs to render the content, whereas DIAL and Chromecast are sending steam URLs, authentication, and transport messages to the Chromecast, which then is the device actually rendering. Chromecast is better for mobile device batteries, but I loath the proprietary nature of it.
But that wire has to end at a WiFi transmitter at some point, it won't work purely over ethernet wire, for example.
Very few vendors have bothered to include it, mostly the Chinese low and mid-tier device manufacturers. But it is not widely supported since, I want to say, circa 2017.
Yeah, not sure about that since those devices in question, where I've used it, have some Wi-Fi somewhere. I just remembered that there has been something done to provide it over a wired connection, but the device would have been wired to an access point. My specific use case was an Xbox wired to an AP and casting wirelessly from my laptop. So there is a wireless hop in the mix.
It was standard in Android. The only time I had ran into a situation where I haven't had it was Google Nexus 6+. I haven't tried a lot of different OEMs, but OnePlus and Microsoft have (had) it for sure. Samsung I have used their Smart View service, but I thought it was Miracast with Samsung specific extensions. Meta Quest 2, I was surprised seems to only work with Chromecast. However that suggests that you may be right. Most of my devices have support, but not all do.
The operative word in your comment is the word “was”. Like, I'm not trying to be rude. I also wanted Miracast to grow up and become the thing to send video over local networks. But Google killed it dead.
I selected "was" simply because I don't have enough understanding of the current situation to argue it from that standpoint.
In many ways, Chromecast is superior. Removing the rendering task from the tablet or phone, and letting the receiver manage that, it's significantly better than making the mobile device decompress the source stream and then decompress it for a Miracast receiver. The only real advantage Miracast has in this is that it doesn't need to receive firmware updates to keep it up to date with newer protocols. With Miracast being built in to TVs, and possibly implemented in an ASIC, it should be a universal fallback. With Android 4.2 it was a built in protocol to AOSP. What I didn't know was that it was actually stripped back out with Android 6. I thought dropping support was specific to Google devices only.
What really needs to be implemented is a non-proprietary extension to Miracast which goes back to the early Chromecast days when it was based on the DIAL protocol. It's incredible that we have to deal with so many proprietary standards from Airplay and Chromecast, and then also support the wifi alliance standard for Miracast.
They have different objectives honestly. Miracast was supposed to stream frames exclusively. Chromecast hands datastreams to the target device who then has to do the heavy lifting, sometimes even fetching the source itself. Entirely different use cases and tech stacks. I would like to show my PC screen on the living room. I can't do that without paying either Google or Valve (still Google), despite the fact it is not technically difficult or complex with contemporary technology to stream raw frame buffers to a screen. But that's patent trolling and monopolies. They will sap all the fun out of tech for those extra pennies.
They are different as you and I have both described, but when the sink device can support different streams, it has a significant advantage, because it automatically can support sinking frames from the broadcasting device and it removes the overhead of decompressing and then recompressing with practically assured data loss. It is yet another example of how patents, especially software patents, work against the original intent of the patent process.