热度 11
2011-10-9 15:29
1946 次阅读|
4 个评论
上接:如何将Android带入互联网数字家庭? 第二篇 如何将Android带入互联网数字家庭? 第三篇 在第一篇中,我们分享了数字家庭软件平台的发展趋势和特点;在第二篇中,我们归纳了将Android移植到电视、机顶盒平台需要面对的五大技术挑战并重点探讨了 挑战1 : 符合电视体验的2D/3D图形性能和用户交互模式方面的挑战 。在本篇中,我们将一起来继续分析其他的技术挑战。 挑战 2 : 适合大屏的丰富多媒体影音体验: Android设计时是以移动手持设备为目标的,因此并没有考虑作为家庭娱乐中心的电视和机顶盒的多媒体影音需求。在下述方面需要改进: 更加优化的多媒体框架; 支持更多的音视频文件格式和容器; 支持更多的音视频编解码标准; 在Android的版本更新进化过程中,Android使用过两套多媒体框架:OpenCore和 Stagefright。 在Gingerbread之前使用的是OpenCore(在Froyo中,OpenCore和Stagefright同时存在),之后Stagefright完全替换了OpenCore。相比较而言,Stagefright架构更加简单,添加新的feature,新的parser更加容易。图一描述了多媒体框架在Android整个软件架构中的位置。 图一 从Froyo到Gingerbread Android多媒体架构的变化 针对多媒体框架的修改和定制,一般我们有三个选择: 直接在OpenCore或者Stagefright上进行修改或者定制。 这个选择相对简单,只需要在相应的框架上做相关的修改。缺点是由于Stagefright支持的文件格式和编解码标准较少,需要一定的工作量来支持一些家庭娱乐中常见的多媒体格式和编码,同时也不便于重用已有的一些成果。 集成已有的成熟的开源多媒体框架,比如Gstreamer或者FFMPEG。 这样做的好处是可以最大程度的利用已有的资源和成果;如果是选择集成Gstreamer的话,则有大量的Plug in可以利用。图二表述了将Gstreamer集成到Android之后的多媒体架构。 图二 集成Gstreamer的Android多媒体架构 集成商业或者私有的多媒体框架。 ARM的合作伙伴特别是在多媒体方面有多年积累的伙伴,会希望将自己私有的多媒体架构集成进Android, 一方面,他们对私有架构的性能非常自信;另一方面也可以重用自身很多已有的成果,形成差异化。另外一方面,ARM的软件合作伙伴也提供了一些商业的多媒体框架供选择,比如VisualOn推出的VOME。 在考虑过选择何种方案定制多媒体框架后, 我们来看看作为家庭娱乐中心的电视、机顶盒对所支持的多媒体格式的需求与Android自身支持能力之间的差异。图三到图五分别列出了电视平台在音视频文件格式(容器)和编码解码格式的主流需求与Android 3.0原生能力之间的差异。 图三 Android TV平台对音视频文件格式的需求与Android 3.0原生能力的差异 图四 Android TV平台对音频编解码格式的需求与Android 3.0原生能力的差异 图五 Android TV平台对音频编解码格式的需求与Android 3.0原生能力的差异 从上面三张图的比较,我们可以看出Android 3.0原生支持的格式与电视平台对媒体文件格式和编解码格式的主流需求还有不小的差距,弥补这些差距正是将Android移植到互联数字家庭必须开展的工作。 挑战 3 : 集成数字电视相关功能: 集成数字电视协议栈,比如DVB-T,DVB-C, ATSC等; 针对数字电视功能扩展API接口; 截至到Android 3.1, Android内没有集成任何数字电视协议相关的协议栈,如DVB-C/T/S 或其他。 因此如何集成DTV/STB 相关协议栈也是Android TV/STB 开发过程中不得不面对的问题。由于各个国家,各个地区的数字电视标准存在较大的差异化,因此对于数字电视相关协议栈的集成需要根据实际需求开展。一般来说,开发Android TV / STB 的合作伙伴具备一定的数字电视/机顶盒开发经验,将软件组件集成进去技术上难度不大,包括对CA的集成。 图六从架构的角度描述了数字电视相关软件组件的集成到Android后的情形。 图六 集成了数字电视相关组件的Android架构 从上图可以看出,除了需要集成相关的C/C++ 库到Library这一层外;在Application Framework这一层也需要做相应的封装将相关的API暴露给应用层。 关于如何实现和定义Android TV数字电视功能相关的API,目前各家Android TV的厂家都没有标准,这也是Android TV/ STB最大的风险和挑战之一。 目前在Android TV/STB中实现数字电视相关的API大致有两种方式(不限于两种): 1. Java Application + Customized Application Framework + JNI + DTV/STB Specific Libraries 2. Browser (HTML5 + JavaScript) + C/C++ DTV/STB Specific Libraries 第一种方式如图六所示,在Application Framework这一层对一系列JNI进行封装,形成数字电视功能相关的Java Level的Class; 第二种方式,通过修改Webkit,让JavaScript去call 相关的C level API从而将数字电视的功能嵌入到浏览器网页之中。 图七和图八给出了第一种方式的一个示例, 包括封装哪些类以及相应的Data Flow的一个示例。 图七 示例: 新增的数字电视功能相关的Java Package/Class 图八 示例 :新增的数字电视功能相关的Java Package/Class的数据流 挑战 4 : 推动应用开发者开发适合于TV的Android应用; Android TV/STB 能否真正取得商业的成功,极大程度上取决于Android TV Application Store能否成功。目前虽然Google Android Market上已经有了20多万的应用,但是没有一个应用是真正为电视量身定做的。换句话说Android TV需要自己的应用和应用商店! 那么,如何推动应用开发者开发适合TV的Android应用?在2011年6月21号ARM在深圳举办的Android TV/STB 技术交流会上,来自于国内主流的运营商,芯片商,电视系统厂商,软件设计公司的代表就这个问题展开了深入的讨论。其中有几个共识一起分享一下: 第一, 需要形成相对统一的Android TV的API规范; 至少要有标准化的Android TV/STB SDK 或者 NDK, 包括Emulator; 第二, 需要各家电视系统商家,包括运营商能以共享的心态来推动应用市场的建设;各家维护各家的应用市场难以支撑Android TV的商业成功; 第三, 需要形成灵活的商业模式吸引应用开发者开发Android TV的应用; 第四, 针对TV的Android应用要充分考虑TV和用户交互方式的特点, 从最简单的“上下左右确认返回”六个键做起; 第五, 需要推动Android TV相关的便利的开发工具在应用开发者的使用 虽然很多共识还需要进一步的细化,更需要落实;但所有的合作伙伴都已经意识到对于Android TV或者说智能电视来说,应用是王道;而要推动应用的发展和繁荣,必须抱着一种开放和共享的心态! 在下一篇(最后一篇)中, 我们会继续探讨将Android带入互联网数字家庭的挑战5 :“如何部署内容保护"以及Android TV和GoogleTV的一些比较。(第三篇完)