43 ms·

the phone/browser lock-in is largely due to lack of a standardized and open protocol to stream content in this manner. in the wireless-display-sharing ecosystem

the phone/browser lock-in is largely due to lack of a standardized and open protocol to stream content in this manner. in the wireless-display-sharing ecosystem the chromecast is unique in that, when possible, it streams content from the original provider on a local client rather than relying on mirroring your device's display. this gives a better user experience but required participation from each service provider. i'm surprised netflix or amazon hasn't tried to create a standardized protocol for asking another client to initiate a stream from a provider on your behalf, including passing account credentials and allowing for widevine and other drm. if this was successful, it would open the market for chromecast-like-devices from other vendors.

deleted 2y ago
[deleted]
ghaff 2y ago
I was at my brother's on vacation and we were sharing some vacation pics. The mirroring worked pretty well but I do wish there were a straightforward way to just cast a browser to a TV in a standard way.
- vel0city 2y ago
  In Windows, you can press Win+K to pull up the Cast menu. Lots of smart TVs and streaming devices will work with it. You can mirror or extend your display to it. This is through standardized protocols.
  - ghaff 2y ago
    I admittedly don't use Windows.
scarmig 2y ago
> amazon hasn't tried to create a standardized protocol Amazon is pushing Matter Cast, which is in many ways superior to Google Cast, most of all by being open. Its biggest downside is that it's not supported by anyone else.
- mbreese 2y ago
  The new (Google TV Streamer) device seems to support Matter as a protocol, so maybe there is more hope here...
- vel0city 2y ago
  > most of all by being open Didn't Chromecasts work with DIAL which was an open protocol? https://www.dial-multiscreen.org/dial/protocol-specification https://www.dial-multiscreen.org/dial/protocol-specification
  - scarmig 2y ago
    Google Cast was originally built on top of DIAL, but DIAL itself is mostly about device discovery IIRC. Nowadays it's all mDNS instead.
    - vel0city 2y ago
      DIAL is literally discovery and launch. The discovery part is just SSDP. The rest of DIAL is entirely state tracking the stream, sending playback commands, requests to launch content, etc. through REST endpoints. It seems entirely possible to me for a revision of the spec based off mDNS for discovery rather than UPnP, and most of the document would be the same. The DIAL spec documents spend three pages talking about discovery and sixteen pages talking about state tracking, launching, HDMI-CEC, etc. It's a pretty basic protocol spec since it mostly relies on things like UPnP for discovery and HTTP REST so a lot of complications are already defined in other specs.
- cbsmith 2y ago
  Well, better than Doesn't Matter Cast.
- jauntywundrkind 2y ago
  There's a lot of Matter Cast that feels fairly reasonable as a protocol, but the flaws here are so wildly absurd. I want this effort to sink so bad. As a protocol I vastly prefer Open Screen Protocol, which was begat to support W3c Secondary Screen wg's Presentstion API. https://w3c.github.io/openscreenprotocol/ https://w3c.github.io/openscreenprotocol/ https://www.w3.org/TR/presentation-api/ https://www.w3.org/TR/presentation-api/ Matter Cast has what to me are grevious limitations: 1. Connecting clients can only talk to existing Endpoints running on the target device. If I use Tidal for example, the smart speaker or smart TV needs to already be setup with that app, and needs to be willing to let a background service run & register itself with the platform. https://github.com/project-chip/connectedhomeip/blob/master/examples/tv-casting-app/APIs.md#select-an-endpoint-on-the-casting-player https://github.com/project-chip/connectedhomeip/blob/master/... 2. Only native apps are supported. There's no protocol to say open a webpage & control that. As a solo dev I can throw together a universal Presentation API multi-display experience in hours. Shipping even one native app would take many weekends & lots of legal hoops. Getting on the apps store for even 50% of TV's or speakers seems daunting beyond imagining. 3. No support for multi-party sessions. Only one user can interact at a time. 4. No support for the Web's Presentation API. Since it's not based around urls & web pages, it would require lots of additional work to make it support the standard web pages have to spawn a remote display. By compare, Open Screen Protocol lets any target device open any web page, which is very similar to how Chromecast development works today (and how DIAL worked before). Whether the target device is Android, Apple, WebOS, Windows, Tizen, or other, the expectation that I could Open Screen Protocol cast to it remains the same. Where-as Matter Cast requires a native app on the device & the app has to be installed & potentially even greenlit by the target device platform itself. OpenScreenProtocol really looks to have it all, & the model is so much more universal. Really wish we saw some device makers pushing for it these days.
deleted 2y ago
[deleted]
glenstein 2y ago
>the phone/browser lock-in is largely due to lack of a standardized and open protocol to stream content in this manner. I feel like the thing you are describing as lock-in is, in a critical sense, quite the opposite. It gave you the power to make a dumb TV into a versatile streaming system that's not locked down and beholden to Smart TV software.
- HumblyTossed 2y ago
  I wouldn't say opposite. You're still choosing one company's platform.
realityking 2y ago
> in the wireless-display-sharing ecosystem the chromecast is unique in that, when possible, it streams content from the original provider on a local client rather than relying on mirroring your device's display. AirPlay has the same capabilities, I believe even in the original v1 version - back then only for Audio as it didn’t support video at all.
xerox13ster 2y ago
The standardized protocol already exists and it’s called DLNA which Chromecast initially cannibalized in its first release and then basically killed off every single other DLNA provider and app because they Sherlocked the feature into the Android operating system and to the Chrome browser. Now that they are at risk of being split up for their monopoly, and as they lose an Antitrust case for their search monopoly, they are probably looking to kill off the Chrome brand because Chrome is how they entirely dominated the web, warping it to their standards and killing more open standards in favor of their Proprietary technology.
- lern_too_spel 2y ago
  DLNA is meant to play media from a media server on a home network. It doesn't make sense for Internet services to implement DMS. The relevant standard for casting using web protocols is DIAL.
- Shog9 2y ago
  I vaguely remember DLNA... Which is to say, I remember it barely working at best and mostly just wasting a lot of time debugging configuration and network nonsense. Arguably the biggest advantage of Chromecast was just not having to deal with all that.
  - scarmig 2y ago
    Chromecast also allowed you to stream Netflix... I'm not sure DLNA ever got to that point.
  - brnt 2y ago
    I use DLNA every day. It just werx. But yes, it's designed to stream local files, so no Netlix et all.

deleted 2y ago

[deleted]

ghaff 2y ago

I was at my brother's on vacation and we were sharing some vacation pics. The mirroring worked pretty well but I do wish there were a straightforward way to just cast a browser to a TV in a standard way.

vel0city 2y ago
In Windows, you can press Win+K to pull up the Cast menu. Lots of smart TVs and streaming devices will work with it. You can mirror or extend your display to it. This is through standardized protocols.
- ghaff 2y ago
  I admittedly don't use Windows.

scarmig 2y ago

> amazon hasn't tried to create a standardized protocol Amazon is pushing Matter Cast, which is in many ways superior to Google Cast, most of all by being open. Its biggest downside is that it's not supported by anyone else.

mbreese 2y ago
The new (Google TV Streamer) device seems to support Matter as a protocol, so maybe there is more hope here...
vel0city 2y ago
> most of all by being open Didn't Chromecasts work with DIAL which was an open protocol? https://www.dial-multiscreen.org/dial/protocol-specification https://www.dial-multiscreen.org/dial/protocol-specification
- scarmig 2y ago
  Google Cast was originally built on top of DIAL, but DIAL itself is mostly about device discovery IIRC. Nowadays it's all mDNS instead.
  - vel0city 2y ago
    DIAL is literally discovery and launch. The discovery part is just SSDP. The rest of DIAL is entirely state tracking the stream, sending playback commands, requests to launch content, etc. through REST endpoints. It seems entirely possible to me for a revision of the spec based off mDNS for discovery rather than UPnP, and most of the document would be the same. The DIAL spec documents spend three pages talking about discovery and sixteen pages talking about state tracking, launching, HDMI-CEC, etc. It's a pretty basic protocol spec since it mostly relies on things like UPnP for discovery and HTTP REST so a lot of complications are already defined in other specs.
cbsmith 2y ago
Well, better than Doesn't Matter Cast.
jauntywundrkind 2y ago
There's a lot of Matter Cast that feels fairly reasonable as a protocol, but the flaws here are so wildly absurd. I want this effort to sink so bad. As a protocol I vastly prefer Open Screen Protocol, which was begat to support W3c Secondary Screen wg's Presentstion API. https://w3c.github.io/openscreenprotocol/ https://w3c.github.io/openscreenprotocol/ https://www.w3.org/TR/presentation-api/ https://www.w3.org/TR/presentation-api/ Matter Cast has what to me are grevious limitations: 1. Connecting clients can only talk to existing Endpoints running on the target device. If I use Tidal for example, the smart speaker or smart TV needs to already be setup with that app, and needs to be willing to let a background service run & register itself with the platform. https://github.com/project-chip/connectedhomeip/blob/master/examples/tv-casting-app/APIs.md#select-an-endpoint-on-the-casting-player https://github.com/project-chip/connectedhomeip/blob/master/... 2. Only native apps are supported. There's no protocol to say open a webpage & control that. As a solo dev I can throw together a universal Presentation API multi-display experience in hours. Shipping even one native app would take many weekends & lots of legal hoops. Getting on the apps store for even 50% of TV's or speakers seems daunting beyond imagining. 3. No support for multi-party sessions. Only one user can interact at a time. 4. No support for the Web's Presentation API. Since it's not based around urls & web pages, it would require lots of additional work to make it support the standard web pages have to spawn a remote display. By compare, Open Screen Protocol lets any target device open any web page, which is very similar to how Chromecast development works today (and how DIAL worked before). Whether the target device is Android, Apple, WebOS, Windows, Tizen, or other, the expectation that I could Open Screen Protocol cast to it remains the same. Where-as Matter Cast requires a native app on the device & the app has to be installed & potentially even greenlit by the target device platform itself. OpenScreenProtocol really looks to have it all, & the model is so much more universal. Really wish we saw some device makers pushing for it these days.

deleted 2y ago

[deleted]

glenstein 2y ago

>the phone/browser lock-in is largely due to lack of a standardized and open protocol to stream content in this manner. I feel like the thing you are describing as lock-in is, in a critical sense, quite the opposite. It gave you the power to make a dumb TV into a versatile streaming system that's not locked down and beholden to Smart TV software.

HumblyTossed 2y ago
I wouldn't say opposite. You're still choosing one company's platform.

realityking 2y ago

> in the wireless-display-sharing ecosystem the chromecast is unique in that, when possible, it streams content from the original provider on a local client rather than relying on mirroring your device's display. AirPlay has the same capabilities, I believe even in the original v1 version - back then only for Audio as it didn’t support video at all.

xerox13ster 2y ago

The standardized protocol already exists and it’s called DLNA which Chromecast initially cannibalized in its first release and then basically killed off every single other DLNA provider and app because they Sherlocked the feature into the Android operating system and to the Chrome browser. Now that they are at risk of being split up for their monopoly, and as they lose an Antitrust case for their search monopoly, they are probably looking to kill off the Chrome brand because Chrome is how they entirely dominated the web, warping it to their standards and killing more open standards in favor of their Proprietary technology.

lern_too_spel 2y ago
DLNA is meant to play media from a media server on a home network. It doesn't make sense for Internet services to implement DMS. The relevant standard for casting using web protocols is DIAL.
Shog9 2y ago
I vaguely remember DLNA... Which is to say, I remember it barely working at best and mostly just wasting a lot of time debugging configuration and network nonsense. Arguably the biggest advantage of Chromecast was just not having to deal with all that.
- scarmig 2y ago
  Chromecast also allowed you to stream Netflix... I'm not sure DLNA ever got to that point.
- brnt 2y ago
  I use DLNA every day. It just werx. But yes, it's designed to stream local files, so no Netlix et all.