Google Cast播放某些视频流缓慢 [英] Google Cast slow for some streams

问题描述

我有一个Android应用程序，可通过Google Cast播放网络实时直播(主要是Icecast).一切正常且快速，但是现在某些流开始(发出声音)需要花费更长的时间.这可能与Chromecast固件升级有关，因为我的Chromecast设备最近更新到了最新版本(1.32.124602).

I have an Android app which plays live streams from web (mostly icecast) via Google Cast. Everything worked fine and fast, but now it takes much longer time for some streams to start (make sound). This may be somehow related to the Chromecast firmware upgrade as my Chromecast device got updated to the latest version (1.32.124602) recently.

这就是我通过Cast播放流的方式:

This is how I play stream via Cast:

MediaMetadata metadata = new MediaMetadata(MediaMetadata.MEDIA_TYPE_GENERIC);
metadata.putString(MediaMetadata.KEY_TITLE, "My title");
metadata.putString(MediaMetadata.KEY_SUBTITLE, "My subtitle");
metadata.addImage(new WebImage(myImageUri);
MediaInfo mediaInfo = new MediaInfo.Builder(streamUrl)
        .setStreamType(MediaInfo.STREAM_TYPE_LIVE)
        .setContentType("audio/mpeg")
        .setMetadata(metadata)
        .build();
MediaLoadOptions options = new MediaLoadOptions.Builder()
       .setAutoplay(true)
       .setPlayPosition(0)
       .build();
sessionManager.getCurrentCastSession().getRemoteMediaClient().load(mediaInfo, options);

奇怪的是，有些流非常快，而另一些却没有:

Strange thing is, that some streams are pretty fast and others not:

1. http://stream.funradio.sk:8000/dance128.mp3 -这会在20秒钟后发出声音
2. http://stream.expres.sk:8000/128.mp3 -这样一秒钟就能发出声音

1. http://stream.funradio.sk:8000/dance128.mp3 - This makes sound after more than 20 seconds
2. http://stream.expres.sk:8000/128.mp3 - This makes sound in 1 second

我还注意到load()函数的ResultCallback在第二个流中几乎立即被触发，而第一个流大约需要3秒钟.

I also noticed that ResultCallback of the load() function is triggered almost instantly for the second stream, while first one takes about 3 seconds.

我非常感谢您提供任何帮助或想法，以解决此问题.

I appreciate any help or idea how to fix this.

推荐答案

第二个链接具有更大的缓冲区可刷新给您.

The second link has a larger buffer to flush to you.

此图显示吞吐量.第一个弯曲是当我在stream.funradio.sk:8000上测试第一个URL时.第二个花样是当我在stream.expres.sk:8000上测试第二个URL时.

This graph shows throughput. The first squiggle is when I tested the first URL on stream.funradio.sk:8000. The second squiggle is when I tested the second URL on stream.expres.sk:8000.

您会注意到，在这两种连接的开头都有大量的数据.它们旨在尽快填充播放器缓冲区，以立即开始播放.您还将注意到，在连接开始时，第二个流具有更多的功能.这是因为它准备好了音频数据的缓冲区.

You'll notice that in both, there is a burst of data right at the beginning of the connection. These are designed to fill the player buffers as fast as possible, to start playback immediately. You'll also notice that the second stream has a lot more of this at the start of the connection. This is because it had a buffer of audio data ready to go.

每个流的缓冲区大小是可配置的.配置第二个流的人们认为可以增加此缓冲区，从而可以使侦听器快速启动，这对于保留侦听器至关重要.唯一真正的权衡是延迟.第二个流实际上已经预先录制了几秒钟的音频，以发送给新客户.对于大多数互联网广播电台而言，此延迟根本不是问题.最好让该流快速启动，并且 对于具有斑点连接的侦听器来说更可靠.

The buffer size is configurable per-stream. The folks that configured the second stream thought to increase this buffer, which enables fast starts for listeners, which has been found to be critically important in retaining listeners. The only real tradeoff here is latency. That second stream has effectively pre-recorded several seconds of audio to send to new clients. For most internet radio stations, this latency isn't a problem at all. It's far better to have that stream start quickly, and be more reliable for listeners with spotty connections.

我非常感谢您提供任何帮助或想法，以解决此问题.

I appreciate any help or idea how to fix this.

代理流的简短内容，您无能为力. Android设备和Chromecast对MP3流特别挑剔，并且需要大量数据才能与其同步.

Short of proxying the streams, there isn't much you can do about it. Android devices and Chromecast are particularly picky about MP3 streams and require a lot of data to synchronize to them.

此外，Chrome正在使用该算法来确定缓冲区是否足够满，可以播放而不会停顿，这并不知道您正在向其发送广播流，并且看到速率下降并在开始播放前缓冲了更多缓冲区.可以通过完全编码自己的播放器来解决此问题，该播放器可以缓冲数据，然后将其传递给解码器，而不仅仅是给底层系统提供URL.在网络上，可以使用Media Source Extensions来完成.对于Android，我在那儿没有太多经验.

Additionally, the algorithm Chrome is using to determine if the buffer is sufficiently full to play without stalling doesn't know you're giving it a radio stream, and sees the drop in rate and buffers a bit more before starting. This issue can be worked around by coding up your own player entirely that buffers the data and then passes it off to a decoder, rather than just giving the underlying system a URL. On the web, this can be done with Media Source Extensions. For Android, I don't have much experience there.

这篇关于Google Cast播放某些视频流缓慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！