跨平台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