5 ms·

> 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

> 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.

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.