the fact that google dropped it from stock android kind of says it all - they clearly think that chromecast isn't good enough to compete without being coddled.
the fact that google dropped it from stock android kind of says it all - they clearly think that chromecast isn't good enough to compete without being coddled.
The beauty of the Google Cast protocol is that you can hand over meta-data as well as the actual source-URL to the receiver and it can initiate the stream directly.
> the fact that google dropped it from stock android kind of says it all - they clearly think that chromecast isn't good enough to compete without being coddled.
Google had a basic implementation in AOSP to kickstart things, but when being deployed to the market it turned out to be too cumbersome and complicated:
1. Each vendor had to certify his device for Miracast implementation with the Wi-Fi Alliance.
2. The Miracast receiver (sink) was buggy in many TV-sets and often didn't even work well with devices from the same vendor (i.e. Samsung Galaxy with Samsung TV)
3. Mobile Chipset vendors (Qualcomm, Mediatek) started to provide their own Miracast implementations to make more efficient use of their HW-architecture
4. Power-consumption of Miracast was too high (the device has to encode it's display content into a H.264 stream)
In the end Google saw the potential to deliver a good experience with a cheap dongle and took matters in their own hands. Miracast on AOSP was not maintained further because it was anyway not used by any major device-vendor (Samsung, LG, Sony, Motorola)
I use it every day and the experience is decent. Google just didnt like the competition from an open standard i guess. but, they dont control what vendors do.
I dont want a proprietary content aware equivalent. There is no beauty to sending metadata separately. There is beauty in having a dead simple way of mirroring whats on my phone that will play any kind of video.
No, as said, vendors add it themselves because the core functionality is now provided and maintained by the vendor of the device-chipset. A generic AOSP ("stock") implementation was proven to be inferior to a custom Miracast component tailored for i.e. Qualcomm DSP/GPU, that's why AOSP didn't continue maintaining it.
not to mention unnecessarily doubling your network bandwidth usage, introducing extra latency, using more power.
Cast and Airplay makes the device itself fetch and play content, with local control and importantly much better display and video manage.
(AirPlay and Cast both support screen sharing, but that is not the main use case.)
I also DGAF about battery life. If im watching TV, I have power nearby and im not moving anywhere. Id be charging my phone anyway.
With one solution, you get good quality playback (including anti-judder from your TV), correct color handling (e.g., 10-bit, HDR, Dolby Vision, whatever), HDMI CEC volume control from the “source” device, and remote control support on the TV.
With the other, you get recompressed content at random source resolution with improper frame pacing (TV cannot so anti-judder of a re-compressed 3:2 pulldown source), poor AV sync, a color space likely crushed to 8-bit with incorrect gamma, no integration and a device that is throwing its battery out the window - even if you don’t feel like you need your battery, Miracast still has no redeeming qualities for this usecase.
Miracast is great for presentations and other scenarios that strictly need screen mirroring though.