跨平台TV OTT应用开发：可行性、功能与限定

OTT就是通过互联网提供的流媒体服务，比如网络电视，而不包含broadcast这种调频的节目源。开发这种app，最焦点的固然是Player相干的内容，即使使用了类似react native、flutter之类的跨平台开发框架，底层仍旧使用了平台自身提供的player，框架不外封装了一层。
关于Android TV和Apple TV流媒体传输协议的支持情况：

Device	Player	Streaming protocols	Definition	Note
Android TV	ExoPlayer	HLS	HTTP Live Streaming，最流行的流媒体协议，将流分解为一系列小文件下载，基于HTTP，支持自顺应比特率流媒体
		DASH	Dynamic Adaptive Streaming over HTTP，原理类似HLS，基于HTTP，支持自顺应比特率流媒体
		SmoothStreaming	提供了一种将媒体从服务器传送到客户端的方法，该方法可以通过通信链中的标准 HTTP 缓存署理举行缓存。答应标准 HTTP 缓存署理代表服务器响应请求会增加单个服务器可以服务的客户端数量
		Progressive	progressive streaming，渐进式流式传输，缓冲下载
		RTSP	Real-Time Streaming Protocol，一样平常用于视频监控和闭路电视系统的标准，须要RTSP服务器与RTP等协议配合来完成其流媒体使命。是一个传统协议，流行度较低
	MediaPlayer	HLS draft protocol	HTTP/HTTPS live streaming draft protocol	仅支持 MPEG-2 TS 媒体文件
		Progressive	渐进式流式传输，缓冲下载
		RTSP (RTP, SDP)	Real-Time Streaming Protocol，一样平常用于视频监控和闭路电视系统的标准，须要RTSP服务器与RTP等协议配合来完成其流媒体使命。是一个传统协议，流行度较低
Apple TV	AVPlayer	HLS	HTTP Live Streaming，最流行的流媒体协议，将流分解为一系列小文件下载，基于HTTP，支持自顺应比特率流媒体

分析一下，以上仅是我做的一些数据的收集，实际验证只验证过Android TV，Apple TV没有做过验证。
固然列了许多在上面，着实用得到的只有HLS和DASH，这两个最主流的协议，其他可以忽略掉。安卓的话，如果想开发具有完备功能的app，大概率会直接pass掉MediaPlayer，所以只看ExoPlayer就好。贫苦的是tvos，竟然不支持dash，只支持自家的hls
  

DRM的支持情况：

Device	Player	DRM scheme	Supported formats
Android TV	ExoPlayer	Widevine "cenc"	DASH, HLS (FMP4 only)
		Widevine "cbcs"	DASH, HLS (FMP4 only)
		ClearKey "cenc"	DASH
		PlayReady SL2000 "cenc"	DASH, SmoothStreaming, HLS (FMP4 only)
	MediaPlayer	Widevine	HLS
Apple TV	AVPlayer	FairPlay	HLS

Apple TV还是一如既往的只用自家的那一套。市面上最常见的三类DRM是WideVine、FairPlay和PlayReady，后面的cenc之类的是加密算法，大家对这方面有兴趣的话可以看看OTTVerse的相干文章，介绍的很全：
https://ottverse.com/eme-cenc-cdm-aes-keys-drm-digital-rights-management/
  

关于广告支持：  

Device		Ad Insertion	Result	Note
Android TV	ExoPlayer	CSAI(Client-side ad insertion)	√	https://developer.android.com/media/media3/exoplayer/ad-insertion#client-side-ad
		SSAI(Server-side ad insertion)	√	https://developer.android.com/media/media3/exoplayer/ad-insertion#server-side-ad
	MediaPlayer	x
Apple TV	AVPlayer	CSAI(Client-side ad insertion)	√	手动拼接，将广告作为单独的video播放
		SSAI(Server-side ad insertion)	√	https://developer.apple.com/documentation/avkit/working-with-interstitial-content

SSAI和CSAI是两种范例的广告
刚开始只有CSAI，也就是客户端播一会真正的视频，然后停下来，去获取广告，播出来，这样有两个问题，一个是由于视频播放的初始阶段效果比较差，用户1080p视频看的正开心，忽然变成了360p的广告，广告逐渐也变成了1080p，然后放完了，用户的下一段视频又是从360p　开始，这样肯定是很让人恼火的；还有一个问题，就是客户端在用户手里面，人家马马虎虎装点脚本，发现请求广告直接举行拦截，那咱也没办法
SSAI则在服务端先把视频和广告拼起来拼接好，这样用户体验上广告和视频内容的割裂感就少一些，而且脚本也不顶用了，由于是放在一段视频里的嘛。但是SSAI就没有弊端吗？有，SSAI首先肯定给服务器带来了更多的负担，视频流服务端要处理的嘛，而且对个性化广告推送是不小的挑战，总不可能针对每个用户都生成不同视频吧
所以现在SSAI和CSAI是一个共存的局面，都要考虑的。幸亏android tv和apple tv都支持的不错

---

到这里大家应该也发现了，tvos着实是限定多多，android tv倒是很有搞头。那么接下来再来看一看android tv其他须要考虑的高级功能吧
首先是live channel的EPG，标出每个channel的开始时间和竣事时间的表格。安卓提供了一个叫TIF的接口，答应app自行将频道显示在系统级的epg中，可惜这个东西是Android 5.0 (API level 21) ～ Android 7.1 (API level 25) only：
https://developer.android.com/training/tv/tif
不外在chromecast中，EPG中是有pluto的节目的，估计是它们达成了什么生意业务相助，这种是贸易上的，看公司气力吧
然后是首页保举，电视的Home页面，展示一些app里面的视频，这个是开放的
https://developer.android.com/training/tv/discovery/recommendations
关于引擎，安卓的视频引擎是Stagefright，可以自己更换编解码器，便于从其他平台迁移
https://source.android.com/docs/core/media
多个视频同时播放，这个理论上不支持，但是受限于硬件程度，最好不要去干这种事。手机上最多只能4个，tv上就更难了：
https://stackoverflow.com/questions/67835565/exoplayer-play-multiple-videos-simultaneously

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。