filter - two - ¿Qué son los filtros bitstream en ffmpeg?

ffmpeg merge videos mp4

Question

Después de leer detenidamente la documentación de FFmpeg Bitstream Filters , todavía no entiendo para qué son realmente.

El documento establece que el filtro:

realiza modificaciones de nivel de flujo de bits sin realizar descodificación

¿Podría alguien explicarme eso más? Un caso de uso aclararía las cosas en gran medida. Además, hay claramente diferentes filtros. ¿Cómo difieren?

Answer 1

Déjame explicarte con el ejemplo. Los decodificadores de video FFmpeg suelen funcionar convirtiendo un cuadro de video por llamada a avcodec_decode_video2. Por lo tanto, se espera que la entrada sea una "imagen" con valor de datos de flujo de bits. Consideremos esta cuestión de pasar de un archivo (una matriz de bytes de disco) a imágenes por un segundo.

Para H264 "en bruto" (annexb) (archivos .h264 / .bin / .264), los datos de unidad nal individuales (flujos de bits de cabecera sps / pps o datos de cuadros codificados en cabac) se concatenan en una secuencia de unidades finales, con un inicio código (00 00 01 XX) en el medio, donde XX es el tipo de unidad nal. (Para evitar que los datos finales en sí tengan datos 00 00 01, se escapó RBSP). Por lo tanto, un analizador de cuadros h264 simplemente puede cortar el archivo en los marcadores de código de inicio. Buscan paquetes sucesivos que comiencen con e incluyendo 00 00 01, hasta y excluyendo la próxima ocurrencia de 00 00 01. Luego analizan el tipo de unidad nal y el encabezado de división para encontrar a qué marco pertenece cada paquete, y devuelven un conjunto de nal unidades que componen un cuadro como entrada al decodificador h264 .

Sin embargo, los datos H264 en archivos .mp4 son diferentes. Puede imaginar que el código de inicio 00 00 01 se puede considerar redundante si el formato de multiplexación ya tiene marcadores de longitud, como es el caso de mp4. Por lo tanto, para guardar 3 bytes por cuadro, eliminan el prefijo 00 00 01. También ponen el PPS / SPS en el encabezado del archivo en lugar de anteponerlo antes del primer fotograma, y ​​también pierden sus prefijos 00 00 01. Entonces, si tuviera que ingresar esto en el decodificador h264, que espera los prefijos para todas las unidades finales, no funcionaría. El filtro de flujo de bits h264_mp4toannexb soluciona esto identificando los pps / sps en las partes extraídas del encabezado del archivo (ffmpeg llama a esto "extradata"), anteponiendo esto y cada nal de los paquetes de cuadros individuales con el código de inicio, y concatecándolos nuevamente juntos ingresándolos en el decodificador h264.

Ahora puede sentir que hay una distinción de línea muy fina entre un "analizador sintáctico" y un "filtro de flujo de bits". Esto es verdad. Creo que la definición oficial es que un analizador toma una secuencia de datos de entrada y la divide en cuadros sin descartar ningún dato ni agregar ningún dato. Lo único que hace un analizador es cambiar los límites del paquete. Un filtro de flujo de bits, por otro lado, tiene permitido modificar los datos. No estoy seguro de que esta definición sea del todo cierta (véase, por ejemplo, vp9 a continuación), pero es la razón conceptual por la que mp4toannexb es un BSF, no un analizador sintáctico (porque agrega 00 00 01 prefijos).

Otros casos en los que tales "ajustes de bitstream" ayudan a mantener los decodificadores simples y uniformes, pero nos permiten admitir todas las variantes de archivos que existen en la naturaleza:

• Desempaquetado de marcos mpeg4 (divx) b (para obtener secuencias de fotogramas B como IBP, que están codificadas como IPB, en AVI y obtener las marcas de tiempo correctas, las personas presentaron este concepto de empaquetamiento de cuadros B donde IBP / IPB se empaqueta en marcos como I- (PB) - () , es decir, el tercer paquete está vacío y el segundo tiene dos cuadros. Esto significa que la marca de tiempo asociada con el fotograma P y B en la fase de decodificación es correcta. También significa que tiene dos fotogramas que vale la pena ingresar datos para un paquete, que viola el concepto de ffmpeg de un marco en un marco, así que escribimos un bsf para dividir el paquete en dos, junto con eliminar el marcador que dice que el paquete contiene dos cuadros, por lo tanto un BSF y no un analizador - antes de ingresarlo en el decodificador. En la práctica, esto resuelve problemas difíciles con multihilo de fotogramas. VP9 hace lo mismo (llamado supertrames), pero divide los fotogramas en el analizador sintáctico , por lo que el analizador / división BSF no es siempre teóricamente perfecto, tal vez VP9 debe llamarse BSF)
• hevc mp4 para anexar la conversión (la misma historia que la anterior, pero para hevc)
• aac adts a conversión asc (esto es básicamente lo mismo que h264 / hevc annexb vs. mp4, pero para audio aac)