Rilevamento automatico o rifiuto dei caricamenti video VP9 incompatibili con iOS Safari

Contribuisci Funzionalità
1

Ho recentemente scoperto che diversi video sul mio forum Discourse in self-hosted non venivano riprodotti su iPhone e iPad senza generare errori. Dopo un’indagine, ho individuato la causa principale: i video erano stati codificati con il codec VP9 all’interno di un contenitore MP4, una combinazione che iOS Safari non è in grado di riprodurre.

Come si verifica

Facebook (e probabilmente altre piattaforme) a volte fornisce video codificati in VP9 quando gli utenti scaricano i propri contenuti. Quando questi file vengono caricati su Discourse, vengono accettati senza problemi: l’estensione .mp4 non fornisce alcuna indicazione sul codec contenuto. Su browser desktop e Android i video vengono riprodotti correttamente, quindi il problema passa inosservato. Su iOS Safari, il video mostra un’anteprima e un pulsante di riproduzione, ma toccandolo appare solo un indicatore di caricamento in rotazione. Gli utenti tendono solitamente a pensare che si tratti di un problema di rete e procedono senza segnalarlo.

Perché è difficile rilevare il problema

  • L’estensione del file (.mp4) è identica a quella di un file H.264 funzionante
  • I browser desktop supportano VP9, quindi gli amministratori che effettuano test su desktop non rilevano alcun problema
  • Gli utenti iOS spesso non segnalano singoli errori multimediali, specialmente quando altri contenuti nello stesso post sono visibili e riproducibili
  • Non esiste alcun avviso o errore rivolto all’amministratore

Soluzione suggerita

Al momento del caricamento di un video, Discourse potrebbe analizzare il codec video (ffprobe è già disponibile nel contenitore Docker) e:

  1. Rifiutare il caricamento con un messaggio chiaro che spiega che VP9 non è supportato su iOS, chiedendo all’utente di ricodificare il video in H.264, oppure
  2. Trascondere automaticamente il video in H.264 al momento del caricamento (similmente a quanto fanno alcune piattaforme per normalizzare i caricamenti)

L’opzione 1 è meno complessa e rappresenterebbe già un miglioramento significativo. L’opzione 2 sarebbe ideale per un’esperienza utente senza interruzioni.

Ambiente

  • Discourse in self-hosted su Docker, archiviazione locale (nessun S3)
  • Versione di Discourse: 2026.4.0-latest
  • Proxy inverso Apache davanti a nginx di Discourse

Soluzione temporanea

Per gli amministratori che si trovano di fronte a questo problema, la correzione richiede:

  1. Identificare i file VP9 con ffprobe
  2. Ricodificarli in H.264 con ffmpeg -c:v libx264 -profile:v main -level 3.1 -r 30 -movflags +faststart
  3. Aggiornare i campi sha1, url, filesize nella tabella uploads
  4. Aggiornare i token URL brevi upload:// nel markdown grezzo dei post interessati
  5. Rigenerare (rebake) i post interessati

Si tratta di un processo manuale non banale che la maggior parte degli amministratori di forum non è in grado di eseguire.

1 Mi Piace
2

Per la trascodifica automatica puoi consultare Discourse Video Stream :movie_camera:.

La trascodifica locale automatica funziona, ma la sfida principale è garantire che il risultato sia sicuro per la maggior parte delle configurazioni.

2 Mi Piace
3

Grazie per il riferimento al plugin Video Stream, @Falco. Per un forum di appassionati piccolo come il mio, aggiungere una dipendenza da un servizio a pagamento di terze parti sembra più di quanto il problema richieda — anche se capisco l’appeal per siti con traffico elevato e un uso intensivo di video.

La tua nota sulla transcodifica locale è interessante. Ho eseguito manualmente ffmpeg sui 9 file interessati sul mio VPS durante il processo di risoluzione, e il server l’ha gestito senza problemi. Comprendo le preoccupazioni legate all’esecuzione in modo sincrono durante il caricamento: picchi di CPU, timeout e pressione sul disco sono rischi reali. Ma un approccio basato su un’attività di background asincrona non risolverebbe la maggior parte di queste problematiche? Il caricamento si completerebbe normalmente, e la transcodifica avverrebbe in un’attività in coda successivamente, proprio come Discourse gestisce già la creazione delle miniature delle immagini. Il video semplicemente non sarebbe riproducibile su iOS fino al completamento dell’attività, il che sembra un compromesso accettabile.

Anche senza arrivare alla transcodifica completa, un’opzione più leggera — rilevare VP9 durante il caricamento e rifiutarlo con un messaggio di errore chiaro oppure segnalarlo nel pannello di amministrazione — farebbe molto per gli amministratori self-hosted che potrebbero non avere le competenze tecniche per diagnosticare i fallimenti silenziosi della riproduzione su iOS.

1 Mi Piace
4

Il video è un po’ più complicato, poiché ci sono molti modi in cui un utente potrebbe caricare qualcosa in modo malevolo per monopolizzare la CPU, specialmente nelle numerose istanze self-hosted con 1 vCPU.

Posso provare a esplorare un plugin qui, in modo che diventi un’opzione a cui l’amministratore può accedere solo se è soddisfatto dei compromessi.

3 Mi Piace