ChromeCast背景视频播放支持iOS [英] ChromeCast background video playback support iOS

问题描述

我有一个问题，当我的应用程序进入后台时，chromecast iOS api的GCKSocket关闭，我从api得到这种错误

I have a problem that when I my application goes in background the GCKSocket of chromecast iOS api closes and I get this typr of error from api

-[GCKCastSocket socketDidDisconnect:withError:]  socketDidDisconnect:withError: "(null)"

然后，如果我将应用程序带到前台，api会自动创建套接字并将播放状态设置为暂停。如果我现在尝试再次播放视频，它会正常播放。

and then if I bring the application to foreground the api creates the socket automatically and set the playback state to paused. If I now try to play the video again it plays normally.

我开始在这样的后台线程上播放媒体。

I am starting the playback of the media on the background thread like this.

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,
                                             0), ^ {
[[CastViewController instance] castMedia:self.media];      

});

即使应用程序进入后台，如何保持播放活动？

How to keep playback alive even when the application goes to background?

这里是来自api的记录

here is the logging from api

2014-02-25 17:19:01.388 CastVideos[28470:60b] -[GCKCastSocket disconnect] disconnect

2014-02-25 17:19:01.391 CastVideos[28470:60b] -[GCKCastSocket doTeardownWithError:] doTeardownWithError

2014-02-25 17:19:01.395 CastVideos[28470:60b] -[GCKCastSocket doTeardownWithError:] notifying delegate that socket is disconnected

2014-02-25 17:19:01.399 CastVideos[28470:60b] -[GCKHeartbeatChannel didDisconnect] disconnected - stopping heartbeat timer if necessary

2014-02-25 17:19:01.457 CastVideos[28470:60b] -[GCKCastSocket socketDidDisconnect:withError:] socketDidDisconnect:withError: "(null)"

推荐答案

目前，当您转到后台时，Cast iOS SDK会关闭套接字，此时这不是可配置项。但是，这并不意味着Cast设备上的媒体播放应该停止;事实上，正确的行为如下：

Currently, the Cast iOS SDK closes the socket when you go to background, and that is not a configurable item at this point. However, that doesn't mean that your media playback on the Cast device should stop; in fact the correct behavior is the following:

• 如果用户明确地将自己与演员设备断开连接，并且如果她是接收器的最后连接设备，则接收器应停止播放，否则接收器应继续播放。

• if user has explicitly disconnected herself from the cast device, and if she is the last connected device to the receiver, then the receiver should stop the playback, otherwise receiver should continue playback.

密钥这是明确的部分;例如，如果发送方超出wifi范围并断开连接，或者如果发送方进入休眠状态并断开连接，则这些被视为隐式断开连接，并且不应导致接收方停止。

The key here is the "explicit" part; if, for example, the sender goes out of wifi range and gets disconnected, or if the sender goes to sleep and gets disconnected, these are considered "implicit" disconnects and should not cause the receiver to stop.

换句话说，真正的接收者应该有逻辑来决定它是否必须自行停止或继续播放，并且为了工作，它必须能够决定是否一个设备断开是由隐式或显式引起的。在当前的接收器SDK API中，遗憾的是，它不包含在接收器获得的onSenderDisconnected事件中;在接收器的下一次更新中，它将发生变化，因此接收器可以看到发生断开的原因，至少与区分显式和隐式的一样多。然后它可以实现逻辑。同时，发件人需要有一个带外频道才能发送表明其明确意图的消息。

In other words, it is really the receiver who should have the logic to decide if it has to stop itself or keep playing, and for that to work, it has to be able to decided if a device disconnect was caused implicitly or explicitly. In the current receiver SDK APIs, unfortunately that is not included in the onSenderDisconnected event that the receiver gets; in the next update or so of the receiver, it will change so receiver can see why a disconnect is happening, at least as much as it needs to distinguish an explicit from an implicit one. Then it can implement the logic. Meanwhile, sender needs to have an out-of-band channel to send a message indicating its explicit intention.

更新： Receiver SDK已经已更新以获取可以判断发件人是否已隐式或明确断开连接的信息，请参阅 docs 。

Update: Receiver SDK has been updated to have the information that can tell whether the sender was implicitly or explicitly disconnected, see the docs.

这篇关于ChromeCast背景视频播放支持iOS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！