如果编码器崩溃，则自动停止YouTube直播活动 [英] Auto-Stop a YouTube Live Event if encoder crashes

问题描述

我知道YouTube API v3，可以让您创建新的直播活动，然后需要将广播与流绑定，手动更改状态等，以便发布直播活动.

I know YouTube API v3, allows you to create new Live Events and then you need to bind broadcasts with streams, change the status manually, etc... in order for your live event to be published.

但是...我注意到，当远程编码器停止将视频发送到流时，事件将继续运行.它将一直运行，直到您手动停止流为止.我想知道是否有任何方法可以在编码器崩溃时自动停止视频流，或者我可能会在推送视频的移动应用中按下主页按钮.

But... I noticed that, when the remote encoder stops sending video to the stream, the Event keeps running. It will keep running until you manually stop the stream. I was wondering if there is any way to auto-stop the stream in the case my encoder crashes, or maybe I press the home button in the mobile app that is pushing the video.

如果您的编码器应用程序在流传输过程中中断，并且您再也没有机会告诉YouTube流已结束，该怎么办?显然，它会一直保留流式垃圾，直到您手动更改状态为止.有什么建议吗?

What do you do if your encoder application breaks during the streaming, and you never got the chance to tell YouTube that the stream is over? Apparently it keeps streaming garbage until you manually change the state. Any Suggestions for this?

推荐答案

我还研究了与YouTube Live Streaming API集成的iOS应用.老实说，我们一直在努力寻找能够解决该问题的好的解决方案.

I also worked on an iOS app that integrated with the YouTube Live Streaming API. To be honest, we struggled to find a good solution that solved this problem as well.

我们在设备上本地保存了liveBroadcast的id，还保存了用户广播的状态(如果用户已经成功安排了广播，是否处于测试阶段，是否处于测试阶段，直播(如果他们已结束广播).如果由于某种原因，设备或编码器在进入结束"状态之前崩溃了，或者用户在实时事件的中间使应用程序后台运行，则在应用程序的AppDelegate中有一个备用API调用，它将终止用户的实时事件.

We saved the liveBroadcast's id locally on the device, as well as saved the state of the user's broadcast (if the user had successfully scheduled a broadcast, if they were in the testing phase, if they were live, if they had ended the broadcast). If for whatever reason the device or the encoder crashed before entering the "ended" state, or the user backgrounded the app in the middle of a live event, we had a fallback API call in the app's AppDelegate that would end the user's live event.

首先，我们将检查用户先前广播的持久状态.如果直播活动未成功结束，我们将启动一系列操作以代表用户结束活动.

First, we would check the persisted state of the user's previous broadcast. If the live event did not end successfully, we would start a chain of actions to end the event on behalf of the user.

我们强制刷新用户的身份验证令牌.我们正在使用带有GTMOAuth的旧版Google+ SDK，因此我们可以调用

We force refreshed the user's auth token. We were using an older version of the Google+ SDK with GTMOAuth, so we we able to call

- (void)authorizeRequest:(NSMutableURLRequest *)request
           completionHandler:(void (^)(NSError *error))handler;

使用nil请求刷新用户的身份验证令牌.

with a nil request to refresh the user's auth token.

然后，对 liveBroadcasts.transition 进行API调用并将broadcastStatus参数值设置为complete.

Then, make an API call to liveBroadcasts.transition and set the broadcastStatus parameter value to complete.

所有操作都是从application:didFinishLaunchingWithOptions:异步完成的，因此用户可以继续使用该应用程序，并准备新的广播，而旧事件则在后台进行清理.

This was all done asynchronously from application:didFinishLaunchingWithOptions:, so the user could continue to use the app, and prepare a new broadcast, while the old event was being cleaned up in the background.

如果此客户端解决方案失败(并且用户从未重新打开应用程序等)，我们还有一个服务器端cron解决方案，该解决方案将检查任何实时但无效"的实时事件并清除它们通过使用其OAuth令牌进行API调用来为用户服务.

If this client-side solution failed (and the user never re-opened the app, etc.), we also had a server-side cron solution that would check any live, but "dead" live events, and clean them up for the user by making an API call with their OAuth token.

我们需要刷新auth令牌，因为我们发现它会在几个小时后过期(任何请求都将返回401 authError).在较新版本的SDK中，这可能已更改.我们还与Parse集成在一起，因此我们可以独立于YouTube跟踪自己的应用程序的广播对象.每当编码器或应用崩溃时，我们都会强制"结束自定义广播，并且如果广播已结束"，但实际的YouTube直播活动仍处于直播"状态，则CloudCode cron作业将代表该YouTube事件结束用户的身份(每次用户登录到应用程序或更新其身份验证令牌时，我们都会将其发送到CloudCode).您还可以手动检查每个YouTube直播事件，以确保如果尝试播放视频，它将进入播放"状态，而不是挂在缓冲"或错误"状态.

We needed to refresh the auth token because we found that it would expire after a few hours (any requests would return a 401 authError). This might have changed in newer versions of the SDK. We also integrated with Parse, so we were keeping track of our own app's broadcast objects independent of YouTube's. We would "force" end our custom broadcast every time the encoder or app would crash, and if our broadcast had "ended," but the actual YouTube live event was still "live," the CloudCode cron job would end the YouTube event on behalf of the user (every time the user logged into the app or updated their auth token, we sent it to CloudCode). You could also manually check each YouTube live event, making sure that if you tried to play the video, it would enter a "playing"s state, and not hang in the "buffering" or "error" states.

这篇关于如果编码器崩溃，则自动停止YouTube直播活动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！