Twitch Auto Clipの振る舞い
Twitchでクリップ作成ボタンを押した段階で作成される30秒の一時クリップをここではAuto Clipと呼ぶことにする 関心はAuto Clip作成の処理の概観
30秒未満の場合があるという現象があるらしい
Twitchのクリップ仕様
クリップボタンを押下するとクリップ編集画面に遷移する
編集可能範囲1分30秒
デフォルトのクリップ範囲が30秒(?)
設定可能なdurationは5秒~1分
実はこのとき30秒のauto clipが作成されている
クリップタイトルが配信タイトルと同一
デフォルト範囲なので30秒(?)
この仕様を知らずにクリップボタンを押したものの消されずに残っているものが多い
編集画面でdurationや切り取り箇所を指定してPublishを押すと編集されたクリップが公開される
同時にauto clipが削除される
30秒未満のものが作成されることがあるという話で振る舞いが気になったので調べた
クリップ作成中にAndroidの戻るボタンを押したら26秒程度のものが作成されるという話
クリップ作成の処理が中断されるので30秒未満になるのでは?という推測がされた
これはないと思っているmtane0412.icon
サーバーサイドで受け取ってさらにクライアントサイドで生成する処理は普通に煩雑そう
サーバー側生成をクライアント側で制御するとしたらさらに超煩雑になる
クライアントサイドでそれなりに重い処理を伴うので他端末でも普通に再現できそうだが同手順で再現できなかった
試行錯誤してChromeで30秒未満のClipを作成することに成功した
26-28秒程度のものが作成される
再現条件は不明
というかやはりクライアントサイドの操作は関係ないように思える
デフォルト範囲ではなく編集可能範囲全体から数秒削られている
https://gyazo.com/e5c33f739c0b9286bd0b9947e438ed0c
iPhoneでは何度試してもだめだった
秒数まで時間表示している配信でクリップしたところ、押下時より数秒先までクリップされていた
クリップは28秒
わかること
サーバー側がリクエストを受け取るまでのラグがあり、リクエスト受け取り時点がクリップの終点として設定されている?
再現
https://i.gyazo.com/c2da5a2a8891e44a87898ee4c83eb11e.mp4
12:01:00にクリップボタンを押下
生成されたクリップの最新部分は12:01:02
クリップの長さは28秒
DiscordのTwitch Developerサーバーで質問したときのアンバサダーの回答
As far as I'm aware though default clip length should be 30s, but isn't guaranteed.
not guaranteedなので30秒と保証されているわけではないと推測しているようだ
Those "auto clips" will be around 30 seconds in length and have the title of the stream as the title.
aroundなので同上
挙動を総合した推測(00:03:00時点でクリップボタンを押下したとする)
クリップボタン押下(00:03:00時点)
サーバーにclip作成リクエストを飛ばしている
サーバーがリクエスト承り太郎(00:03:06)
サーバーはリクエスト受け取り時点の経過時間をクリップの終点として設定する
そのため押下時点より数秒先が指定されている
この受取時間やクリップ作成開始の処理に入る時間差がその時の通信状態に左右されている
サーバーサイドでクリップ範囲が設定される
クリップ開始点: リクエスト受け取り時点の1分30秒前=00:01:36
クリップ終了点: リクエスト受け取り時間 00:03:06
ここで最新部分はまだエンコードが済んでいないので削ぎ落とされるのでは
エンコード完了時点の00:03:04に設定される
クリップ範囲00:01:36-00:03:04(1分28秒)、デフォルトクリップ範囲28秒になる
Chromeで再現条件がバラバラに見えるのも理解可能
サーバーとの通信状態に左右されるので、有り体に言えば調子がすこぶるいいときにいくら試してもベストエフォートの30秒クリップしか再現できない
クライアント-サーバ間の通信がどちゃくそ早いとき
クライアント側の低遅延モードの調子が悪いとき(最新部分よりもだいぶ遅いとき)
逆に26-28秒になった状態から30秒に戻すこともなかなかできない
iPhoneでだけ再現できない問題を考える
それ以外は低遅延モードはオプトアウト=デフォルトでオン
Androidには低遅延モードがないという情報もある
試しにChromeで低遅延モードをオフにしたら30秒クリップを安定して作成できるようになった
この挙動も理解可能
要は最新エンコード部分からかなり前なので未エンコード部分が含まれることがない
iOS版でも低遅延モードをオンにすれば再現できるはず!!と思ったがそこは再現できなかった
Chromeの低遅延モードとiOSの低遅延モードを比べるとiOSのほうがまだ若干遅い
だからiOS版はまだプレビュー機能なのだろう
未エンコード部分にふれるくらいの低遅延がまだ実現できていない?
再現
https://i.gyazo.com/d0d0ffab07d7333d6ca8b2d3e5ca3f37.mp4
低遅延モードをオフの状態だと30秒が作成される
押下時から最新部分はやはり若干時間差がある
10秒押下だが14秒
リクエスト受け取って処理開始まで4秒の差があると理解できる
上の低遅延モードオン状態の再現は通信時差4秒かつ未エンコ部分が2秒と理解可能?
が、そもそも最新部分からかなり遅れているのでエンコード欠損が生じない