[5ym]

#1921 の続き。

• 50-live-pacing「滑らかに届けば…」の遅延の上限を 0.25 秒から 0.3 秒 (pacing.ts の FLOOR × SMOOTH.catchUpRatio、詰め始める貯まり) に合わせる。0.25〜0.3 秒は作りのうえで詰めない範囲。膨らみ続ける・詰めなくなる、は引き続き落ちる
• 26-hwenc (約160秒) から H.265 のテストを 26-hwenc-hevc に分ける。部品は tests/e2e/hwenc.ts
• 実測の秒数で組を割り直す。名前が後ろの長いスペックは、前に並ぶスペックが少ない組に置く
• 50-live-pacing は 6 組に1本だけのまま。ほかと組ませると、貯める量 (上限 0.25 秒は据え置き) が 5 回に 2 回 0.27〜0.29 秒に上がって落ちた。同じ組のワーカーが動くと届く間隔が乱れ、cover が貯める量を上げるため

🤖 Generated with Claude Code

https://claude.ai/code/session_01XNTXZLNBnfhFULMqQoQmmY

[claude]

Claude finished @5ym's task in 26s —— View job

---

レビュー結果

重大な問題は見つかりませんでした。

• 遅延の上限の変更: pacing.ts の SMOOTH は catchUpRatio: 1.5 / catchUpPad: 0 で、steer は low > target * 1.5 で詰め始めます。FLOOR (0.2) × 1.5 = 0.3 は実装と一致しています。FLOOR は export 済みで、tests/e2e が src/lib を import する例は他にもあります。target <= 0.25 は据え置きで、「膨らみ続ける・詰めなくなる」の検出力も保たれています。
• 26-hwenc の分割: hwenc.ts への切り出しは元のコードと同じ内容で、forgetGpusAfterAll も元の afterAll と同じ処理です。26-hwenc に残ったテストは GPUS / clearGpus / encodeRuns / wayOf を使い、26-hwenc-hevc は rmSync / writeFileSync を使うので、import の過不足はありません。
• shards.json: 26-hwenc-hevc は組 6 だけにあり、重複はありません。ファイル名と組の対応をスクリプトで照合しようとしましたが、コマンドが拒否されて実行できませんでした。CI の「組分けの検算」で確認してください。

要確認 (任意)

• 組 6 は 26-hwenc-hevc と 57-jikkyo / 58-volume で、docs と // の注記にある「映像を長くデコードし続けるスペックは 1 つの組に寄せすぎない」対象が 2 本入っています。50-live-pacing は混むと遅延が増える性質があり、今回の上限の緩和はそれを吸収するためのものと理解しました。それでも、組 6 を混ませる並びで問題ないか、実測の数回分で確かめておくと安心です。
• 26-hwenc-hevc に test.setTimeout(300_000) が残っています。分割後の実測で足りるかも、CI の結果で見てください。

テスト、設計、セキュリティ面の指摘はありません。

[claude]

Claude finished @5ym's task in 15s —— View job

---

レビュー結果

重大な不具合は見つかりませんでした。

• 遅延の上限: FLOOR * SMOOTH.catchUpRatio を直接 import する形に変えたので、実装の値とずれません。target <= 0.25 は据え置きなので、膨らみ続ける・詰めなくなる、の検出力も保たれます。
• 26-hwenc の分割: hwenc.ts への切り出しと import に過不足はありません。26-hwenc-hevc は組 6 だけに入っていて、重複はありません。
• shards.json: 組 1〜6 の間で名前の重複は見当たりませんでした。ファイルとの照合は CI の「組分けの検算」に任せます。

要確認

前回のコメントで、組 6 に 57-jikkyo / 58-volume が入っていると書きましたが、これは誤りでした。実際は組 5 です。組 6 には映像をデコードし続けるスペックは 50-live-pacing と 26-hwenc-hevc だけで、前者を他のデコード系と分ける方針には合っています。

• 組 5 は 22-watch・57-jikkyo・58-volume で、デコードし続けるスペックが 3 本入っています。
• 組 3 は 28-live-raw・40-watch-compat・44-ambient で、同じく 3 本です。

どちらも docs と // の注記にある「1 つの組に寄せすぎない」に当たるかもしれません。ただ、組 5 は 4 本、組 3 は 11 本と並びが違うので、実測で決めた割り振りかもしれません。組 5 と組 3 の所要時間とフレーク(不安定な失敗)の出方は、数回分の CI で確かめてください。

26-hwenc-hevc の test.setTimeout(300_000) も、分割後の実測で足りるか確認してください。

テスト、設計、セキュリティ面のその他の指摘はありません。

[claude]

Claude finished @5ym's task in 15s —— View job

---

レビュー結果

重大な問題は見つかりませんでした。

今回の更新 (ca940bd) は、27-encode-cancel を組 1 へ、01-dashboard を組 6 へ入れ替えるだけです。docs/development.md と shards.json の // 注記に「一緒に始まるスペックも軽いものにする」を追記しています。

• shards.json: 入れ替えた 2 本は、それぞれ元の組から消え、移動先に 1 回ずつだけ入っています。重複はありません。組 6 の先頭は 01-dashboard から始まり、名前順でも 26-hwenc-hevc より前です。
• docs と注記: 2 か所とも同じ内容で、食い違いはありません。理由 (混むと届く間隔が乱れ、貯める量が下限から上がる) も、遅延の上限を 0.3 秒に合わせた変更の説明と合っています。
• 遅延の上限: 0.29 秒で落ちた事例は、0.25 秒から 0.3 秒への変更で収まる範囲です。この変更とは別に、組の入れ替えでも重なりを避けています。
• 26-hwenc の分割と hwenc.ts: 前回までの確認から変わりありません。

要確認 (任意)

• 組 1 に 26-hwenc (約 160 秒から分割後は短くなったもの) と 27-encode-cancel が入りました。どちらもエンコードを使うので、27-encode-cancel のキャンセルのタイミング系の待ちが、混んだときに不安定にならないか。数回分の CI の所要時間とフレーク(不安定な失敗)の出方で確かめてください。コードからは判断できません。
• 前回挙げた組 3・組 5 のデコード系の本数、26-hwenc-hevc の test.setTimeout(300_000) も、引き続き CI の実測で確認してください。

テスト、設計、セキュリティ面のその他の指摘はありません。

[claude]

Claude finished @5ym's task in 20s —— View job

---

レビュー結果

重大な問題は見つかりませんでした。

今回の更新 (90a15e3) は、50-live-pacing を組 6 に 1 本だけ置き、残りの 5 組を割り直す変更です。shards.json と // の注記を見ました。

• shards.json: diff の範囲では、組 1〜5 と組 6 の間に名前の重複は見当たりません。26-hwenc-hevc は組 3 だけにあります。ファイルとの照合は、スクリプトの実行が許可されず、できていません。CI の「組分けの検算」に任せます。
• 注記の制約: 33-recordings-group は組 1、21-onair-fallback は組 3 で、同じ組に入っていません。名前が後ろの長いスペック (51-live-gaps、57-jikkyo、57-jikkyo-recorded) は、それぞれ 5 本・5 本・5 本の組に置かれていて、注記の方針に合っています。
• 遅延の上限: FLOOR * SMOOTH.catchUpRatio を使う形のまま変わりありません。target <= 0.25 も据え置きです。
• 26-hwenc の分割と hwenc.ts: 前回までの確認から変わりありません。

要確認 (任意)

• 組 3 には 26-hwenc-hevc・28-live-raw・40-watch-compat・44-ambient が入り、デコードし続けるスペックが 4 本あります (前回は 3 本)。組 5 も 22-watch・57-jikkyo・58-volume の 3 本です。「1 つの組に寄せすぎない」に当たるかもしれませんが、実測で決めた割り振りなら問題ありません。組 3 の所要時間とフレーク(不安定な失敗)の出方を、数回分の CI で確かめてください。
• 組 1 の 26-hwenc と 27-encode-cancel は、どちらもエンコードを使います。27-encode-cancel のキャンセルのタイミング系の待ちが、混んだときに不安定にならないか、CI の結果で見てください。
• 26-hwenc-hevc の test.setTimeout(300_000) は、分割後の実測で足りるか確認してください。

テスト、設計、セキュリティ面のその他の指摘はありません。
· ブランチ: ci/e2e-hwenc-split