QuickTime Player(或实际上是CoreMedia)在播放HTTP流时如何工作



我正在分析TVB(香港)的直播电视流

众所周知,观看它们的网址是:

http://token.tvb.com/stream/live/hls/mobilehd_hdj.smil
http://token.tvb.com/stream/live/hls/mobilehd_j2.smil
http://token.tvb.com/stream/live/hls/mobilehd_inews.smil

我们可以在任何苹果原生软件(如QuickTime,Safari)中通过上面的网址直接观看,无论是在Mac还是iOS中。并且还知道他们正在使用AppleCoreMedia框架。但它在其他平台上不起作用。您将获得HTTP 200,但在内容中"拒绝访问"。我分析了有关它的所有流量。我发现对端点(服务器真正提供视频)的HTTP请求(通过CoreMedia)包含一个标头:

x-playback-session-id: xxxxx

在我手动添加标题(我在 Chrome 或 Firefox 中尝试过)后,视频到达而不是"访问被拒绝"消息,无论用户代理是什么。但是出现的问题是,在我转储的流量中,我找不到任何其他地方在早期请求中包含此标头(因为它重定向了几次)。所以我很好奇AppleMediaCore在播放http流时做了什么?它是计算了会话 ID(或哈希)还是从我错过的地方获取了 ID?

附言我不确定TVB是否进行IP检查。由于他们有版权或法律问题,所以可能会阻止从某个地方访问。您可能需要一个VPN。

终于找到了答案。x-playback-session-id 是来自 AVPlayer 框架的 UUID。但实际上这不会影响我是否得到令牌。真正的令牌是HTTP cookie

我发现的授权过程:

  1. token.tvb.com 重定向到具有几个 GET 值的 vod 服务器
  2. 云点播服务器检查 GET 值并设置 cookie 是否有效。同时响应 m3u8 文件(包含几个不同质量的流 URL)
  3. 播放器将在 m3u8 中请求一个或多个 url 来检索流。然后,VOD 服务器将检查 cookie 和用户代理作为令牌。
  4. 在接下来的时间里,玩家将继续使用cookie和用户代理作为令牌来请求ts文件。

p.s. 来自 TVB 安卓的 HLS 有不同的过程,我还没有弄清楚。但我发现,如果用户代理包含"Android",那么授权将失败。

相关内容

  • 没有找到相关文章

最新更新