Alleggerisce il relay YouTube e rilascia Android 2.0.8.

ffmpeg fa solo remux copy A/V; le app fissano AAC 48 kHz mono; sync deploy non cancella più garage.prod.toml.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/infrastructure/HETZNER_CLOUD_RELAY_OVERFLOW.md

@@ -29,7 +29,7 @@ Se il telefono andasse diretto a YouTube (o a un ingest cloud senza hold), la li
 
 ### Problema di capacità
 
-Ogni diretta `platform=youtube` avvia un processo `ffmpeg` in Sidekiq (`Streams::YoutubeRelay`: video **copy**, audio **AAC**).  
+Ogni diretta `platform=youtube` avvia un processo `ffmpeg` in Sidekiq (`Streams::YoutubeRelay`: video+audio **copy** / remux).  
 Il carico scala con **N processi**, non con gli spettatori HLS.
 
 Sul box attuale (~4 CPU / 8 GB, stack completo sullo stesso host):
@@ -299,7 +299,7 @@ Finché D1 non è chiusa, non stimare bandwitdh né SLA del picco.
 
 ## 7. Dimensionamento indicativo
 
-Ipotesi: 720p, video copy, AAC mono — **~0.3–0.7 vCPU** medi per relay (picchi più alti su analyze/reconnect).
+Ipotesi: 720p, remux copy A/V — **~0.15–0.4 vCPU** medi per relay (picchi su analyze/reconnect).
 
 | Target live YT | Dedicated (relay) | Overflow tipico | Note |
 |----------------|-------------------|-----------------|------|
@@ -349,7 +349,7 @@ Questi numeri vanno **calibati** con un load test (N sessioni fake + ffmpeg cont
 ### Fase 4 — Solo se necessario
 
 - Secondo MediaMTX / sharding
-- Audio copy se l’encoder telefono è già YouTube-compatibile (meno CPU)
+- ~~Audio copy se l’encoder telefono è già YouTube-compatibile (meno CPU)~~ → fatto (app AAC 48k mono + relay `-c:a copy`)
 - Dedicated più grosso come baseline (spesso più economico dell’overflow cronico ogni weekend)
 
 ---