2013-05-13 12 views
6

Sto registrando un flusso continuo in diretta su un flusso HLS ad alto bitrate. Quindi voglio transcodificarlo in modo asincrono su diversi formati/bitrate. Ho questo lavoro, per lo più, ad eccezione di artefatti audio che appaiono tra ogni segmento (spazi vuoti e pop).Transcode HLS Segments singolarmente utilizzando FFMPEG

Ecco un esempio di riga di comando ffmpeg:

ffmpeg -threads 1 -nostdin -loglevel verbose \ 
    -nostdin -y -i input.ts -c:a libfdk_aac \ 
    -ac 2 -b:a 64k -y -metadata -vn output.ts 

Ispezione un esempio file audio mostra che c'è un divario alla fine dell'audio:

End

e l'inizio della il file sembra attenuato con sospetto (anche se questo potrebbe non essere un problema):

Start

Il mio sospetto è che questi artefatti stiano accadendo perché la transcodifica si sta verificando senza il contesto del flusso nel suo insieme.

Qualche idea su come convincere FFMPEG a produrre audio che possa rientrare in uno stream HLS?

** AGGIORNAMENTO 1 **

Ecco l'inizio/fine del segmento originale . Come puoi vedere, la partenza sembra sempre la stessa, ma la fine è pulita a 30 secondi. Mi aspetto un certo grado di imbottitura con la codifica lossy, ma c'è qualche modo che HLS riesce a fare la riproduzione senza pause (Is This correlate a iTunes metodo con metadati personalizzati?)

Original Start Original End

** aggiornato 2 **

Così, ho convertito sia l'originale (128k aac in MPEG2 TS) sia il transcodificato (64k aac in aac/adts container) in WAV e ho messo i due side-by-side. Questo è il risultato:

Side-by-side start Side-by-side end

Non sono sicuro se questo è rappresentativo di come un cliente riprodurla, ma sembra un po 'strano che la decodifica quello transcodifica introduce un vuoto nella avvia e rende il segmento più lungo. Dato che sono entrambi codifica lossy, mi sarei aspettato che il padding fosse ugualmente presente in entrambi (se non del tutto).

** AGGIORNAMENTO 3 **

Secondo http://en.wikipedia.org/wiki/Gapless_playback - Solo una manciata di encoder supportano senza pause - per MP3, ho passato a lame in ffmpeg, e il problema, finora, sembra essere andato.

Per AAC (vedi http://en.wikipedia.org/wiki/FAAC), ho provato libfaac (al contrario di libfdk_aac) e sembra anche produrre audio senza pause. Tuttavia, la qualità di quest'ultimo non è eccezionale e preferisco usare libfdk_aac è possibile.

+0

E come si confronta la forma d'onda con il file di input? – vipw

+0

Aggiornato con forme d'onda originali e confrontate – rayh

risposta

0

Questa è più una risposta concettuale piuttosto che contenere strumenti espliciti da usare, mi spiace, ma potrebbe essere di qualche utilità in ogni caso - rimuove il problema dell'introduzione di artefatti audio a scapito dell'introduzione di una maggiore complessità nell'elaborazione strato.

Il mio suggerimento sarebbe quello di non dividere il proprio audio di ingresso non compresso, ma solo produrre un flusso compresso contiguo che si riversa in un proxy audio come un server icecast2 (o simile, se icecast non supporta AAC) e quindi fai lo split/ricombine sul lato client del proxy usando blocchi di audio compresso.

Quindi, il metodo qui sarebbe quello di regolare (ad esempio, ogni 60 secondi?) Connettersi al proxy e raccogliere un blocco di audio un po 'più grande del periodo in cui si sta eseguendo il polling (ad esempio, vale 75sec?) - questo deve essere impostato per funzionare in parallelo, poiché in alcuni punti ci saranno due client in esecuzione - potrebbe anche essere eseguito da cron se necessario o in background da uno script di shell ...

Una volta che funziona, si avere una serie di frammenti di audio che si sovrappongono un po '- allora dovresti fare qualche lavoro di elaborazione per confrontare questi e isolare la sezione dell'audio nel mezzo che è unica per ogni pezzo ...

Ovviamente questo è una semplificazione on, ma supponendo che il proxy non aggiunga informazioni sui metadati (cioè dati ICY o suggerimenti) quindi suddividere l'audio in questo modo dovrebbe consentire la concatenazione dei blocchi processati senza artefatti audio poiché esiste solo un set di output per l'input audio originale e il loro confronto saranno un gioco da ragazzi dato che in realtà non ti interessa il formato, sono solo byte a quel punto.

Il vantaggio qui è che hai scollegato il codificatore audio dal client, quindi se vuoi eseguire qualche altro processo in parallelo per transcodificare in diversi formati o bit rate o frammentare il flusso in modo più aggressivo per altri utenti allora questo non cambia nulla sul lato encoder del proxy: basta aggiungere un altro client al proxy usando una catena di strumenti simile a quella sopra.

+0

Mi piace l'idea di avere un semplice proxy che memorizzerebbe i dati audio dal dispositivo. Ciò consentirebbe il riavvio della codifica senza perdere dati ... specialmente se comprendesse campioni e potessero dividere i dati su confini del campione. – rayh

+0

Tuttavia, senza risolvere il problema originale, la transcodifica nei frammenti degli anni '60 introdurrà solo quei problemi al limite dei blocchi - gli artefatti sembrano essere il risultato della codifica di aac, quindi probabilmente influirebbero anche su tutti i file audio. – rayh

+0

probabilmente storia antica, mi dispiace, ma questo è il motivo per cui ho suggerito di tagliare l'audio compresso al limite del frame (che, ammettiamolo, potrebbe non essere esattamente divisibile dove lo vuoi ma non sarà lontano) ... ora, se prendi due pezzi diversi di audio compresso e li esegui insieme otterrai comunque artefatti, ma non se fossero originariamente contigui –

Problemi correlati