Cosa sono i filtri bitstream in ffmpeg?

Question

Dopo un'attenta lettura di FFmpeg Bitstream Filters Documentation, non riesco ancora a capire a cosa servano davvero.

Il documento afferma che il filtro:

esegue modifiche a livello di bitstream senza eseguire la decodifica

Qualcuno potrebbe spiegare, inoltre, che a me? Un caso d'uso chiarirebbe molto le cose. Inoltre, ci sono chiaramente diversi filtri. Come si differenziano?

Answer 1

Lasciatemi spiegare con l'esempio. I decodificatori video FFmpeg funzionano generalmente convertendo un fotogramma video per chiamata in avcodec_decode_video2. Quindi l'input dovrebbe essere "una immagine" del valore di dati bitstream. Consideriamo questo problema di passare da un file (una serie di byte di disco) alle immagini per un secondo.

Per file "raw" (annexb) H264 (.h264/.bin/.264), i singoli dati dell'unità nal (bitstream di intestazione sps/pps o dati frame codificati in cabac) sono concatenati in una sequenza di unità nali , con un codice di partenza (00 00 01 XX) in mezzo, dove XX è il tipo di unità nale. (Al fine di evitare che i dati nal abbiano dati 00 00 01, è fuoriuscito da RBSP.) Quindi uno h264 frame parser può semplicemente tagliare il file agli indicatori di codice di avvio. Cercano pacchetti successivi che iniziano con e compreso 00 00 01, fino a ed escludono la successiva occorrenza di 00 00 01. Quindi analizzano il tipo di unità nal e l'intestazione di sezione per trovare a quale frame appartiene ciascun pacchetto e restituiscono un set di nal unità che costituiscono un frame come input per lo h264 decoder.

I dati H264 in .mp4 sono diversi, tuttavia. Si può immaginare che il codice di avvio 00 00 01 possa essere considerato ridondante se il formato di muxing ha già marcatori di lunghezza, come nel caso di mp4. Quindi, per salvare 3 byte per fotogramma, rimuovono il prefisso 00 00 01. Mettono anche PPS/SPS nell'header del file invece di prepilarlo prima del primo frame, e anche questi mancano i loro prefissi 00 00 01. Quindi, se dovessi inserire questo nel decodificatore h264, che si aspetta i prefissi per tutte le unità nal, non funzionerebbe. Il filtro bitstream h264_mp4toannexb risolve questo problema, identificando i pps/sp nelle parti estratte dell'intestazione del file (ffmpeg chiama questo "extradata"), anteponendo questo e ciascun nal da singoli pacchetti di frame con il codice di avvio e concatenandoli di nuovo insieme prima inserendoli nel decodificatore h264.

Si potrebbe ora ritenere che ci sia una distinzione molto sottile tra un "parser" e un "filtro bitstream". Questo è vero. Penso che la definizione ufficiale sia che un parser prende una sequenza di dati di input e la divide in frame senza scartare alcun dato o aggiungere dati. L'unica cosa che fa un parser è cambiare i confini dei pacchetti. Un filtro bitstream, d'altra parte, è autorizzato a modificare effettivamente i dati. Non sono sicuro che questa definizione sia completamente vera (vedi ad esempio vp9 sotto), ma è la ragione concettuale che mp4toannexb è un BSF, non un parser (perché aggiunge 00 00 01 prefissi).

Altri casi in cui tali "ritocchi bitstream" aiutano a mantenere i decoder semplice e uniforme, ma ci consentono di supportare tutti i file varianti che capita di esistere in natura:

• MPEG4 (DivX) b frame unpacking (per ottenere B -frames sequenze come IBP, che sono codificate come IPB, in AVI e ottenere timestamp corretti, la gente ha escogitato questo concetto di imballo B-frame dove IBP/IPB è confezionato in frame come I-(PB)-(), cioè il terzo pacchetto è vuoto e il secondo ha due frame: ciò significa che il timestamp associato al frame P e B in fase di decodifica è corretto.Significa anche che hai due fotogrammi di dati di input per un pacchetto, che viola il concetto di un frame-in-one-frame-out di ffmpeg, quindi abbiamo scritto un file bsf per dividere il pacchetto in due - insieme all'eliminazione del marker che dice che il pacchetto contiene due frame, quindi un BSF e non un parser - prima di inserirlo nel decoder. In pratica, questo risolve altrimenti problemi difficili con il multithreading del frame. VP9 fa la stessa cosa (chiamata superframes), ma divide i frame nello parser, quindi la divisione parser/BSF non è sempre teoricamente perfetta; forse VP9 di dovrebbe essere chiamato un BSF)
• mp4 HEVC a ALLEGATO B di conversione (stessa storia come sopra, ma per HEVC)
• aac adts to asc conversione (questo è fondamentalmente la stessa di h264/HEVC Annexb vs. mp4, ma per aac audio)