如果编码器崩溃，自动停止YouTube直播事件
我知道YouTube API v3，允许您创build新的实时事件，然后您需要绑定与stream的广播，手动更改状态等…为了您的现场活动发表。
但是…我注意到，当远程编码器停止发送video到stream，事件继续运行。 它将继续运行，直到您手动停止stream。 我想知道是否有任何方法来自动停止stream的情况下，我的编码器崩溃，或者我可以按下推动video的移动应用程序的主页button。
如果您的编码器应用程序在stream式传输过程中发生中断，您会怎么做？您从来没有机会告诉YouTubestream式传输已经结束？ 显然它会保持stream式垃圾直到你手动改变状态。 对此有何build议？
我还参与了一个与YouTube直播streamAPI集成的iOS应用程序。 说实话，我们努力寻找解决这个问题的好方法。
我们在设备上本地保存了liveBroadcast的id ，并且保存了用户广播的状态（如果用户已经成功地安排了广播，他们是否处于testing阶段，如果他们是活的，是否已经结束了广播）。 如果出于某种原因，设备或编码器在进入“结束”状态之前崩溃，或者用户在现场活动中间使应用程序退出，我们在应用程序的AppDelegate中有一个可以结束用户现场事件的回退API调用。
首先，我们将检查用户先前广播的持续状态。 如果现场活动没有成功结束，我们将开始一连串的行动来代表用户结束活动。
我们强制刷新用户的身份validation令牌。 我们在GTMOAuth中使用了较早版本的Google+ SDK，因此我们可以打电话给他们
- (void)authorizeRequest:(NSMutableURLRequest *)request completionHandler:(void (^)(NSError *error))handler;
没有请求刷新用户的authentication令牌。
然后，对liveBroadcasts.transition进行API调用，并设置broadcastStatus参数值complete 。
这一切都是从application:didFinishLaunchingWithOptions:asynchronous完成的，所以用户可以继续使用应用程序，并准备新的广播，而旧的事件正在后台清理。
如果这个客户端解决scheme失败（并且用户从不重新打开应用程序等），我们也有一个服务器端的cron解决scheme，可以检查任何活的，但是“死”的现场活动，并清理用户通过使用其OAuth令牌进行API调用。
我们需要刷新auth令牌，因为我们发现它会在几个小时后过期（任何请求都会返回401 authError ）。 在较新版本的SDK中，这可能已经发生了变化。 我们还与Parse集成，所以我们跟踪独立于YouTube的应用程序的广播对象。 每当编码器或应用程序崩溃时，我们将“强制”结束我们的自定义广播，如果我们的广播“结束了”，但实际的YouTube直播活动仍然是“现场”，则CloudCode cron作业将代表YouTube事件结束的用户（每次用户login到应用程序或更新他们的authentication令牌，我们都将其发送到CloudCode）。 您也可以手动检查每个YouTube直播活动，确保如果您尝试播放video，它将进入“播放”状态，而不是挂在“缓冲”或“错误”状态。