• Google Cast和ChromeCast


    Google Cast类似于DLNA,AirPlayer,Miracast,就是一种投屏技术。
    我们ATV产品是对Google Cast和ChromeCast都是支持的。

    Google Cast 大致工作原理:
    发送端 app(sender app)使用 SDK,将需要播放的媒体的信息发送到 Google 的服务器,服务器再通知接收端播放(所以发送端和接收端必须都可以访问 Google 的服务器才行)。接收端运行的是一个浏览器,它会根据发送端的app ID和媒体信息,去载入对应的一个网页,这个网页(receiver app)也是由发送端 app 的开发者提供的,的将会负责播放相应的媒体内容。即使接收端是 Chromecast Audio 之类只能播放音频的硬件,这个网页也是会载入并渲染的。
    Google Cast 和 DLNA 或者苹果的 AirPlay 不同之处,一是依赖 Google 的服务器,也就是说必须连接到 Internet 才可以用,如果只有一个局域网是不行的。二是前两个的接收端播放器接收端本身提供的,开发者只需要提供要播放的内容就可以,但是 Google Cast 则是需要提供自己的receiver app,这样的好处是开发者可以高度定制(比如可以定制UI,或者加入弹幕、歌词滚动、音乐可视化之类复杂功能),虽然接收端往往运行的并不是Android这样的开放操作系统,但是因为receiver app的本质是网页,所以开发难度并不高。

    ChromeCast和Google Cast
    从Google Cast的官网(https://developers.google.com/cast/)说明我们可以看到Google Cast的作用在于把小屏幕(诸如手机、平板、笔记本)的内容通过无线(WIFI)方式发送到大屏设备(google TV、chromeCast)进行播放,概括一下也即提供小屏设备到大屏设备的多屏互动功能。Google Cast所做的便在于基于不同的平台提供提供为应用开支这种功能的SDK,这些平台即有发送端的也有接收端的,发送端的有IOS、android、chrome浏览器,接收端的有google TV, chromeCast等,可以说这一套解决方案是比较大而全的(就其涵盖的平台)。

    而chromeCast其实是对Google Cast这套机制的具体实现,这种实现的特点是接收端的chromeCast dongle是google自己提供的,开发者的负担只局限与发送端平台的应用开发,当然这种发送端的灵活性也是局限于google所提供的Google Cast API的。
    总结一下Google Cast 和 Chrome Cast的关系,其实就是Google Cast提供了一套进行设备之间互联互通的API,而chromeCast技术则是对这一套API的具体实现,这种实现的优点在于为应用开发者提供了使用Google Cast API进行开发的灵活性(当然这也可以认为是该技术不能支持所有app的局限性)。


    参考:(下面博文可能需要翻墙)
    Google Cast(Chromecast)浏览器 SDK 学习笔记(一)
    https://segmentfault.com/a/1190000006673788

    关于chromeCast介绍
    https://blog.csdn.net/ny_mg/article/details/41379641

  • 相关阅读:
    WPF-触发器
    WPF使用socket实现简单聊天软件
    git常用命令备忘
    (转载)WPF中的动画——(一)基本概念
    WPF中的依赖项属性
    C#中的索引器
    C#中的装箱拆箱
    编程语言的弱类型、强类型、动态类型、静态类型
    WPF中的数据驱动
    WPF中的命令简介
  • 原文地址:https://www.cnblogs.com/lijunamneg/p/8986008.html
Copyright © 2020-2023  润新知