L’audio surround senza perdita attiva la conversione quando un dispositivo o un livello software nella catena di riproduzione non è in grado di accettare il codec e la configurazione dei canali senza modificarli.
Un film può riprodurre direttamente il video mentre il server multimediale converte Dolby TrueHD, DTS-HD Master Audio, FLAC multicanale o un’altra traccia senza perdita in AC-3, E-AC-3, AAC o PCM stereo. La decisione dipende dall’app client, dal televisore, dal dispositivo di streaming, dalla connessione HDMI, dal percorso ARC o eARC, dal ricevitore, dal lettore selezionato e dalle capacità dichiarate. Diagnostica il percorso audio esatto invece di presumere che la pagina del prodotto del televisore dimostri il passthrough completo dall’origine alla destinazione.
Conferma che venga convertito solo il flusso audio
Avvia lo stesso titolo sul client interessato con la qualità video impostata su originale e i sottotitoli disabilitati. Registra nel pannello del server la modalità video, la modalità audio, la traccia selezionata, il codec di output, il numero di canali e il motivo della transcodifica.
La conversione audio non richiede sempre la codifica video. Un problema di Jellyfin mostra un video H.264 copiato mentre il flusso audio non supportato veniva convertito in AAC tramite HLS, dimostrando che la transcodifica del solo audio segue un percorso separato.
Se il pannello segnala anche la conversione video, rimuovi le variabili relative a sottotitoli, bitrate, HDR e contenitore prima di diagnosticare la traccia surround. L’obiettivo è ottenere una sessione controllata in cui cambi solo la selezione audio.
Identifica il codec, il profilo e la configurazione dei canali esatti
Esamina il flusso selezionato con il server multimediale o con uno strumento di analisi dei file multimediali. Registra se si tratta di TrueHD, TrueHD con Atmos, DTS-HD MA, DTS:X, FLAC multicanale, PCM, E-AC-3 o AC-3, oltre alla configurazione dei canali e alla frequenza di campionamento.
Un client che supporta il normale DTS o Dolby Digital non supporta automaticamente l’estensione senza perdita. Un rapporto attuale su una regressione di Android TV descrive il mancato passthrough di DTS-HD MA, anche se lo stesso dispositivo e un altro lettore riuscivano a trasmettere correttamente la traccia.
Confronta la traccia senza perdita con una traccia alternativa AC-3, E-AC-3, AAC o stereo incorporata nello stesso file. Se la traccia alternativa viene riprodotta direttamente mentre quella senza perdita viene convertita, il video, lo spazio di archiviazione e la rete non sono la causa principale.
Traccia l’intero percorso audio dal client al ricevitore
Annota il percorso effettivo: dall’app multimediale al dispositivo di streaming o al televisore, poi tramite HDMI al televisore o al ricevitore, seguito da ARC o eARC se l’audio ritorna dal display. Ogni passaggio deve trasmettere il codec selezionato senza modificarlo.
Alcuni dispositivi possono decodificare un formato localmente, ma non trasmetterlo in bitstream attraverso il percorso di uscita selezionato. L’interfaccia client di Jellyfin avvisa che TrueHD deve essere abilitato solo quando il dispositivo o il ricevitore collegato lo supporta, perché un’impostazione errata delle capacità può causare un errore di riproduzione anziché il passthrough.
Prova a collegare il lettore direttamente al ricevitore e poi attraverso il televisore. Se il collegamento diretto al ricevitore funziona ma il percorso di ritorno dal televisore converte l’audio o genera errori, controlla la modalità eARC, l’uscita audio digitale, le impostazioni di passthrough, le capacità dell’ingresso HDMI e la negoziazione del cavo invece di modificare il server multimediale.
Confronta le impostazioni di passthrough del client e le versioni del lettore
Verifica se l’app utilizza il passthrough audio automatico, diretto o disabilitato e se seleziona un lettore nativo, ExoPlayer, un lettore web o un lettore esterno. Registra la versione del client prima di modificare le impostazioni.
Il software client può dichiarare capacità inferiori a quelle dell’hardware, che in realtà supporta un codec senza perdita. Un problema di Android TV mostra la conversione dell’audio TrueHD e DTS anche se il ricevitore e il client risultavano compatibili, indicando una discordanza nella dichiarazione delle capacità.
Prova un’altra app sullo stesso dispositivo e con lo stesso ricevitore senza modificare il file. Se un lettore trasmette la traccia mentre un altro la converte, mantieni invariata la configurazione del server e concentrati sul profilo del client che presenta il problema, sulla versione dell’app e sul motore di riproduzione selezionato.
Controlla i limiti dei canali e il downmix
Un client può accettare AAC o PCM solo in stereo, oppure può dichiarare sei canali mentre l’app ne richiede due. Confronta il numero di canali in uscita indicato dal server con il formato mostrato sul pannello frontale del ricevitore e con l’attività degli altoparlanti.
Gli utenti di Jellyfin WebOS hanno segnalato la conversione di DTS-HD MA e FLAC multicanale, seguita dalla riduzione a stereo, dimostrando che la conversione del codec e la riduzione dei canali possono verificarsi nella stessa sessione.
Se il ricevitore mostra l’audio stereo dopo la conversione, controlla il numero massimo di canali audio del client e il profilo di transcodifica del server. Non aumentare i canali alla cieca quando il contenitore di distribuzione o il televisore non possono trasportare PCM o AAC multicanale attraverso quel percorso.
Scegli un’alternativa compatibile senza ricodificare il video
Preferisci una traccia di compatibilità AC-3 o E-AC-3 già presente quando i client interessati non possono trasmettere l’audio senza perdita. Mantieni la traccia originale TrueHD o DTS-HD per i client compatibili con l’impianto home theater.
Quando la libreria non dispone di una traccia alternativa, crea una traccia audio secondaria o una versione multimediale alternativa invece di sostituire la sorgente senza perdita. La conversione del solo audio è molto meno impegnativa della transcodifica video e preserva l’immagine originale.
La spiegazione di ZimaSpace sulla pipeline di transcodifica audio illustra il meccanismo correlato e aiuta a capire perché una traccia alternativa compatibile può preservare la riproduzione diretta del video.
Verifica passthrough, sincronizzazione e ripresa della riproduzione
Ripeti il test delle tracce senza perdita e alternative dall’inizio, dopo un salto nella riproduzione e dopo la ripresa. Conferma la modalità del server, il formato del ricevitore, l’uscita dei canali, la sincronizzazione labiale e la capacità di continuare la riproduzione dopo il riavvio dell’app.
La conversione del solo audio può far emergere problemi di ricerca specifici del client. Un problema su un televisore con Jellyfin segnala il blocco della riproduzione dopo un salto quando solo l’audio richiedeva la transcodifica.
La diagnosi è completa quando i client compatibili trasmettono la traccia senza perdita senza modificarla, i client limitati selezionano una traccia compatibile e stabile, il video viene riprodotto direttamente quando possibile e il ricevitore mostra il codec e la configurazione dei canali previsti per tutta la riproduzione normale.
Supporto e consigli
Altro da leggere

Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...

Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...

Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...

