Chromecast是否支持投射来自Reddit的视频? (HLS和Dash视频) [英] Does the Chromecast support casting videos from Reddit? (HLS and Dash videos)

问题描述

具有URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLSPlaylist.m3u8 通过URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLS_540_v4称为代理. m3u8 通过URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLS_AUDIO_160_K_v4称为代理. m3u8 通过URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLS_224_v4称为代理. m3u8

Called proxy with URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLSPlaylist.m3u8 Called proxy with URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLS_540_v4.m3u8 Called proxy with URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLS_AUDIO_160_K_v4.m3u8 Called proxy with URL http://192.168.xx.xx:8080/3hyw7hwoajn21/HLS_224_v4.m3u8

以下是Reddit视频示例: https://www.reddit.com/r/me_irl/comments/b3vrs4/me_irl

Here's an example Reddit video: https://www.reddit.com/r/me_irl/comments/b3vrs4/me_irl

浏览 JSON ，它有一些视频源选项:

Looking through the JSON, it has a few options for video sources:

"reddit_video": {
    "dash_url": "https://v.redd.it/3hyw7hwoajn21/DASHPlaylist.mpd",
    "duration": 76,
    "fallback_url": "https://v.redd.it/3hyw7hwoajn21/DASH_720?source=fallback",
    "height": 720,
    "hls_url": "https://v.redd.it/3hyw7hwoajn21/HLSPlaylist.m3u8",
    "is_gif": false,
    "scrubber_media_url": "https://v.redd.it/3hyw7hwoajn21/DASH_240",
    "transcoding_status": "completed",
    "width": 1280
}

虽然我似乎可以将其他HLS/m3u8视频与Chromecast SDK配合使用(例如

While I seemingly can get other HLS/m3u8 videos to work with the Chromecast SDK (for example Google's own example HLS video), I cannot seem to get any of these sources to work.

我已经尝试过 https://v.redd.it/3hyw7hwoajn21/HLSPlaylist.m3u8 将流类型设置为实时"或缓冲"，我尝试将内容类型设置为"application/x-mpegURL"，并且对于破折号URL https://v.redd.it/3hyw7hwoajn21/DASHPlaylist.mpd 的内容类型为"application/dash + xml"也无济于事.我发现这个问题似乎表明某种可能性?

I've tried https://v.redd.it/3hyw7hwoajn21/HLSPlaylist.m3u8 with the stream type set to both "live" or "buffered", I've tried the content type as "application/x-mpegURL", and I've tried the same for the dash URL https://v.redd.it/3hyw7hwoajn21/DASHPlaylist.mpd with content type "application/dash+xml" also to no avail. I found this question that seems to indicate some possibility?

我还注意到DASH文件中有单独的视频和音频流( https://v.redd.it/3hyw7hwoajn21/DASH_720 和 https://v.redd.it/3hyw7hwoajn21/audio )最坏的情况是，有没有办法在Chromecast上同时播放视频流和单独的音频流?

I've also noticed with the DASH file there's a separate video and audio stream (https://v.redd.it/3hyw7hwoajn21/DASH_720 and https://v.redd.it/3hyw7hwoajn21/audio) worst case scenario is there a way to play the video stream with the separate audio stream playing too on the Chromecast?

Chromecast不能播放这些视频类型吗?

Is it not possible for the Chromecast to play these video types?

Jesse和aergistal认为这与缺少CORS标头有关.我构建了一个自定义的接收器应用程序，以便能够获得更好的调试日志，这确实是(第一个)问题. Chromecast抱怨CORS.

Jesse and aergistal suggested that it has to do with the lack of CORS headers. I built a custom receiver app to be able to get better debugging logs, and this was indeed (the first) issue; Chromecast complains about CORS.

在使用nginx时，我构建了一个本地反向代理，其中添加了所有CORS标头，然后我为Chromecast提供了该代理URL，而这个CORS错误就消失了.

Using nginx on I built a local reverse proxy that adds all the CORS headers, then I give Chromecast that proxy URL instead and this CORS error went away.

但是，使用HLS/m3u8链接仍然不会流式传输.现在它抱怨以下内容:

However, using the HLS/m3u8 link it still wouldn't stream. Now it complains of the following:

[cast.player.hls.PackedAudioParser]在0处均未找到ID3或ADTS标头

[cast.player.hls.PackedAudioParser] Neither ID3 nor ADTS header was found at 0

和

[cast.player.api.Host]错误:cast.player.api.ErrorCode.NETWORK/315

[cast.player.api.Host] error: cast.player.api.ErrorCode.NETWORK/315

和

[cast.receiver.MediaManager]加载元数据错误:错误

[cast.receiver.MediaManager] Load metadata error: Error

完整日志:

这导致它仍然无法播放.有什么想法吗?

Which causes it to still not play. Any ideas?

添加CORS问题可以加载DASHPlaylist.mpd变体(以前不会)，这很好，但同时却不那么好，因为反向代理要求您首先下载整个响应，以及在哪里下载DASH URL只是整个MP4(而HLS是字节范围)，这意味着反向代理必须先下载整个DASH视频，然后再显示它，这要比HLS花费时间.

Adding the CORS issue allows the DASHPlaylist.mpd variant to load (it wouldn't before), which is great, but not so great at the same time because the reverse proxy requires you to download the entire response first, and where the DASH URL is just an entire MP4 (whereas the HLS is byte ranges) it means the reverse proxy has to download the entire DASH video first before showing it, which takes ages compared to the HLS.

因此，由于速度的原因，使HLS正常运行仍然是最佳选择，但是由于Chromecast上的播放问题，注定它不能正常工作吗?

So it'd still be optimal to get the HLS working due to speed, but is it just doomed not to work due to a playback issue on the Chromecast?

推荐答案

具有单独音轨的HLS解决方案

根据最新日志中的信息，所选的段格式与流中使用的实际格式不匹配.流使用MPEG-TS中的AAC，而Cast SDK尝试将其解析为打包的音频.

Based on the information from the latest log there is a mismatch between the chosen segment format and actual format used in the stream. The stream uses AAC in MPEG-TS whereas the Cast SDK tries to parse it as packed audio.

回复显示HlsSegmentFormat默认为MPEG2_TS如果流是多路复用的，则MPEG_AUDIO_ES否则.

A reply on the Cast issue tracker shows that the HlsSegmentFormat defaults to MPEG2_TS if the stream is multiplexed and MPEG_AUDIO_ES otherwise.

对于CAF接收器，建议的解决方案是拦截加载请求并使用loadRequestData.media.hlsSegmentFormat = cast.framework.messages.HlsSegmentFormat.TS覆盖段格式.稍作修改的示例:

The suggested solution for the CAF receiver is to intercept the load requests and override the segment format with loadRequestData.media.hlsSegmentFormat = cast.framework.messages.HlsSegmentFormat.TS. A slightly modified example:

<html>
<head>
</head>
<body>
  <cast-media-player id="player"></cast-media-player>
  <script type="text/javascript" src="//www.gstatic.com/cast/sdk/libs/caf_receiver/v3/cast_receiver_framework.js">
  </script>
  <script>
    const context = cast.framework.CastReceiverContext.getInstance();
    const playerManager = context.getPlayerManager();
    // intercept the LOAD request
    playerManager.setMessageInterceptor(
        cast.framework.messages.MessageType.LOAD, loadRequestData => {
            loadRequestData.media.hlsSegmentFormat = cast.framework.messages.HlsSegmentFormat.TS;
            return loadRequestData;
        });
    context.start();
  </script>
</body>
</html>

原始来源

再举个例子

CORS解决方案

Google Cast参考为您提供了解决方案:

The Google Cast reference gives you the solution:

如果您在Cast设备上播放流时遇到问题，则可能是CORS的问题.使用公开可用的 CORS代理服务器来测试您的流

可公开使用的代理服务器的问题在于，由于带宽问题，它们强制执行大小限制，因此请自行制作或使用开源的代理服务器.如果该应用程序在移动设备上运行，您还可以将其设置为本地服务器.

The problem with the publicly available proxies is that they enforce a size limit due to bandwidth concerns, so make your own or use an open-source one. If the app runs on a mobile device you can also make it a local server.

当前流不受DRM保护.如果他们添加CDN身份验证或使用DRM保护流，这将变得更加复杂或完全不可能.

The current streams are not protected by DRM. This will get more complicated or outright impossible later if they add CDN authentication or protect the streams with DRM.

关于CORS标头，您必须确保支持预检请求:客户端可能会先发送OPTIONS来检查CORS支持(包括允许的方法和标头).

Regarding the CORS headers you must make sure preflight requests are supported: the client might send an OPTIONS first to check CORS support (including allowed methods and headers).

您的流还必须支持HTTP范围请求，这意味着必须授权并公开适当的标头.

HTTP range requests must also be supported for your streams meaning the appropriate headers must be authorized and exposed.

来自 https://enable-cors.org 的示例飞行前请求配置:

Example preflight request configuration from https://enable-cors.org:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,OPTIONS
Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range
Access-Control-Expose-Headers: Content-Length,Content-Range

您将至少需要允许:GET，OPTIONS，Content-Type和Range标头，并公开Content-Length，Content-Range.如果远程服务器提供了重复的标头，则将其删除.

You will need to allow at least: GET, OPTIONS, the Content-Type and Range headers, and expose Content-Length,Content-Range. Remove duplicate headers if provided by the remote server.

这篇关于Chromecast是否支持投射来自Reddit的视频? (HLS和Dash视频)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！