Is Google Cast open to third party receiver devices (DIAL 1st-screen devices), or will ChromeCast remain the only option?
Can we expect SmartTV makers to natively support the cast protocol, so that a ChromeCast device will not be needed?
As a developer, what do I have to implement in order to be a Google Cast device?
Related
Is it possible to search for beacon data (uuid, url, ...) with a progressive web application using just web technologies that is without using native mobile technologies (Android, ios, ...)?
Thanks in advance.
Unfortunately, this is not possible as of July 2020. While Google has been working on the WebBluetooth project to bring support for many bluetooth operations to the browser, at least in Google Chrome implementations on Android 6+, Mac or ChromeOS.
Scanning for beacons is not yet possible as of this writing. The API requires that the OS scan for devices matching a requested criteria, and then let the user choose a device to connect to using a user interface. This essentially rules out beacon detection.
Bluetooth scanning APIs are still in draft form here.
EDIT: The APIs mentioned by #zurfyx in the answer below allow you to scan for and connect to an advertised GATT service, but do not allow you to read the data in the advertisement. This is a critical distinction, as reading the data in the advertisement is the key capability required for actual bluetooth beacon detection. That capability is missing from that API. Without that capability, it is impossible to detect a beacon, it is only possible to connect to a BLE device that might be an Eddystone or other service advertisement-based beacon.
UPDATE July 2020: Safari will not be getting any WebBluetooth APIs at all due to privacy concerns, according to a June 2020 announcement by Apple This makes Bluetooth scanning impossible on iOS we apps for the foreseeable future.
As of July 2020, Chrome does not support scanning arbitrary advertisements. See status here: https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md
Disclaimer: I wrote eddystone-web-bluetooth (a library which makes it easy to read and write to an Eddystone device). github#eddystone-web-bluetooth npm#eddystone-web-bluetooth
It is possible to scan for Bluetooth devices by using the Web Bluetooth API (currently supported only by Chrome).
By using Bluetooth GATT service, you can connect to Eddystone devices and send/receive data by communicating following their public specifications (which are basically a list of request codes, and the format in which to send and expect their responses).
These services include information such as:
URL
Advertising interval
Lock state
and more
By using the Bluetooth standard information you can get to know the most generic device information, such as its id and name:
navigator.bluetooth.requestDevice
#beaufortfrancois wrote the probably first Eddystone Web Bluetooth configuration code (source code / demo), so it is probably worth a read if you want to dig more into this. I learned a lot from it.
My Chromecast v2 shows up as an undefined Bluetooth device. Attempts to connect, however, have not been successful. This is most probably due to a secret pairing PIN.
Oddly, nowhere can I find documentation of this feature. Why wouldn't Google mention Bluetooth connectivity?
Can anyone explain what Chromecast uses Bluetooth for and how to connect with it? Eventually, I'd like to connect it with a Bluetooth audio receiver on my HiFi... (I know about external Bluetooth transmitters, I'd like to use the internal one, however, if possible.)
That is for internal use, for example setup, etc and doesn't have any profiles that can be useful to developers, nor is intended to be used by developers.
I'd like to send audio directly from a Raspberry Pi to a Google Cast Audio device.
I'm happy to do this via a fileserver hosted on the Pi (or similar) but no external services can be used- no internet connection is available during operation. Is this possible?
Using Google Cast SDK, you would need a "sender" application to initiate the launch of your app on a cast device and sending the instructions to that. After that is done, your (html5) application on the cast device can continue the playback on its own. Whenever the application on the cast device is brought down, you would need a sender to restart this process. The platforms supported by Cast SDK are Android, iOS and chrome, so RP is not among the supported platforms. Another issue in your scenario is that any cast device requires internet connectivity; without one, such device will not boot up completely and won't be useful.
The Chromecast device is a "receiver device [that] runs a scaled-down Chrome browser with a receiver application". Can I download and install this receiver app on a chrome browser for example on my Windows notebook?
I have implemented a complete chromecast v2 receiver, called YouMap ChromeCast Receiver, available in Google play store and Amazon store, xda-developer thread here: http://forum.xda-developers.com/android-tv/chromecast/app-youmap-chromecast-receiver-android-t3161851
The current Chromecast protocol is a completely different one from the original DIAL based protocol. Right now, only YouTube still uses the old protocol, which chromecast maintains its backward compatibility.
The discovery is mDNS, exactly same as Apple TV bonjour protocol.
The most difficult part is device authentication, the sender and the receiver perform handshakes by exchanging keys and certificates in a way extremely difficult to crack. AppleTV does the same using FairPlay encryption.
The next difficult part is the mirroring protocol, which is also very complicated, need to deal with packet splits, packet retransmissions. Overall, chromecast mirroring protocol is well designed, better than miracast, better than AirPlay mirroring (I have also implemented both of them, so I know what I am talking about).
When I get chances, will write more here.
The chromecast device works using the DIAL protocol. It is completely possible to emulate this protocol using some simple code to listen on the multicast group for discovery and then handle the HTTP requests to launch applications. It is then the launched application that communicates with the casting device, I believe using the RAMP protocol.
Luckily for us the applications that the chromecast device uses are mostly web applications meaning our device emulator just needs to launch a web browser and point it to a specific url when it receives an application request.
For example the youtube app, after device discovery and establishing where the applications are located (part of DIAL). Will send a HTTP POST request containing a pairing key to /<apps url>/YouTube. All the emulating device needs to do now is open https://www.youtube.com/tv?<pairing key> in a browser window. From here, I believe, communication for controlling the youtube app is not sent through the casting device but through the open tabs on the casting device and the emulator.
This is my understanding of how the chromecast device works and specifically the youtube app from looking at https://github.com/dz0ny/leapcast which is a python emulator that has youtube and google music working.
Google is in progress of open sourcing some part of the chrome cast.
https://code.google.com/p/chromium/codesearch#chromium/src/chromecast/
https://code.google.com/p/chromium/issues/list?q=label:Chromecast
So theoretically you can build a similar device.
I wanted to know if it is possible to program one chromecast device to send video to another chromecast device acting like a receiver. I have browsed the API reference on the Google developer website and it doesn't seem to be supported, but also doesn't say it isn't supported.
This is not currently possible, and probably never will be. Chromecast devices don't "source' video, they only transfer from wifi to an HDMI output. it is possible to play the same stream on two different chromecast devices, but there is no way to synchronize them at the moment. In theory this is something the devices could support.