LOVE21 Site Core v1.3.6 TS2 / LAG8 / VERIFIED ATOMIC SFTP / PRODUCER LABEL
==========================================================

目的
----
5〜6秒単位の音切れを切り分けるため、2秒TSへ戻し、SFTP公開手順を
「書き込み中のファイルをHTTP側へ見せない」方式へ変更した診断兼安定化版です。

固定ポリシー
------------
・TS長: 2秒
・H.264 GOP: 60 frames（30fps x 2秒）
・ローカルHLS window: 20本（約40秒）
・サーバーplaylist: 20本（約40秒）
・再生開始目標: ライブ端から約8秒後ろ
・再生遅延上限目安: 20秒
・SFTP応答待ち: 5秒
・最初の再接続待ち: 1秒（以後 2,4,8,16,30秒上限）

Verified Atomic SFTP
--------------------
TSは正式名へ直接書きません。
  1. .__nativecast_segment.uploading へ全量WRITE
  2. CLOSE
  3. SFTP STATで remote size と local size を比較
  4. 一致した場合だけ正式な stream*.ts へRENAME
  5. 正式名でも再度size確認
  6. size不一致時は同じセッションで1回即再送

stream.m3u8も .__nativecast_playlist.uploading へ書き、size確認後にRENAMEします。
サーバーが posix-rename@openssh.com を通知する場合はatomic replaceを使用します。
通知しないサーバーではSFTP v3標準RENAMEへ安全にフォールバックします。

転送内容検証
------------
・全TS: remote size == local size を確認
・20TSに1本: SFTPでremote TSを読み戻しSHA-256をlocalと比較
・hash不一致: そのTSを即再送して再比較

ログ例:
  TS VERIFY NG ... -> RETRY
  TS VERIFY RETRY OK ...
  TS HASH SAMPLE OK ...
  TS HASH SAMPLE NG ... -> RETRY

ローカル生成TSの事前診断
------------------------
送信するsnapshotに対し、送信前に以下を確認します。
・ファイル長が188バイトの整数倍
・全MPEG-TS packetのsync byteが0x47
・PAT (PID 0) が1個以上存在
・transport_error_indicator (TEI) が0
・adaptation_field_controlが有効
・同一PID内continuity counterに不自然な飛びがない

異常時:
  LOCAL TS VERIFY NG name=... reason=...

これは診断目的です。LOCAL TS VERIFY NG が音切れ時刻と一致すれば、
SFTP以前のCore/生成側で壊れている可能性が高くなります。

サーバー上のTS保持
------------------
playlistに載る最終TSは20本＝約40秒分です。
正式な stream*.ts は最大20本を厳守します。新TSを正式名へ公開する直前に、
新しい20本窓から外れる最古TSを削除して1枠空けます。最古TSは約40秒遅れで、
この版の最大再生遅延20秒より後方なので通常視聴では参照しません。

Uploader/Watchdog再接続後はremote directoryを一度照合し、現在playlistに
含まれない stream*.ts を先に削除します。Uploader再起動による旧TS残留を防ぎます。
一時upload名は固定1本で拡張子は .uploading のため、正式TS数には含まれません。

再生側
------
サーバーへ送る stream.m3u8 のみに追加:
  #EXT-X-START:TIME-OFFSET=-8.000,PRECISE=NO

PC hls.js:
・2秒TS x 4本 = 約8秒後ろを再生目標
・10本 = 約20秒を最大遅延目安

iPhone / iPad native HLS:
・EXT-X-STARTにより約8秒後ろから開始を推奨
・復旧時は20秒超の遅延を約8秒へ戻す

Persistent SSH/SFTP
-------------------
・Windows ssh.exeを1プロセスだけ維持
・Native SFTP v3 packetをstdin/stdoutで直接送受信
・per-cycle sftp.exe起動なし
・ServerAliveInterval=15 / ServerAliveCountMax=3 / TCPKeepAlive=yes
・SFTP応答が5秒ない場合はSSHを破棄して再接続
・初回再接続待ち1秒
・Uploader終了時はUPLOADER_WATCHDOG.ps1がCoreを止めず再起動

変更しない部分
--------------
・AAC-LC 256kbps / 48kHz
・Hardware H.264 854x480 / 30fps（GOPは安定版の60へ復帰）
・Native MPEG-TS/HLS muxer
・FFmpeg不要
・B1.html のレイアウト / CSS / TwitCasting部分

導入
----
1. STOP_SILENT.vbs または STOP.bat で停止
2. 現在のフォルダーをバックアップ
3. このZIPを同じフォルダーへ上書き展開
4. SETTINGS\NativeCastSiteCore.json はZIPに含まれないため既存SSH設定は残る
5. BUILD_CHECK.bat
6. TEST_3MIN.bat
7. 問題なければ START_SILENT.vbs

別途のB1.htmlをWeb側へ置換してください。

正常ログの目安
--------------
Core:
  H264 CodecAPI GOP=60 hr=0x00000000
  NATIVE HLS mux START seg=2s list=20

Uploader:
  UPLOAD START mode=PERSISTENT-SFTP segment=2s playlist=20x2s playbackStart=-8s playbackMax=20s ... atomicPublish=YES sizeVerify=EVERY_TS hashSample=1/20
  SFTP CONNECTED ... protocol=v3 reconnects=1 posixRename=YES/NO
  REMOTE RECONCILE current=... staleDeleted=... maxFinalTs=20
  UPLOAD HEALTH: mode=PERSISTENT-VERIFIED ... sizeOK=... localStructNG=0 hashOK=... hashRetry=0 fail=0 ...

確認ポイント
------------
・実TS durationが約2.000秒
・LOCAL HLSのts数が20で推移
・LOCAL TS VERIFY NG が0
・size mismatch / hash mismatch が出るか
・音切れ時刻と上記VERIFYログが一致するか
・SFTP RECOVER後に1秒ベースで再接続するか

注意
----
サイズ一致・SHA一致でも、生成済みTS内部のtimestamp/codec semantic errorまでは
完全には証明できません。今回のローカル構造チェックと組み合わせて原因を絞ります。
