audio - reproducir - ffmpeg tutorial español

¿Cómo modifico mi comando FFMPEG para que mis transmisiones en vivo HTTP sean más eficientes?

Question

Quiero reducir la sobrecarga de muxing al crear archivos .ts usando FFMPEG.

Estoy usando FFMPEG para crear una serie de archivos de flujo de transporte utilizados para la transmisión en vivo HTTP .

./ffmpeg -i myInputFile.ismv /
-vcodec copy /
-acodec copy /
-bsf h264_mp4toannexb /
-map 0 /
-f segment /
-segment_time 10/
-segment_list_size 999999 /
-segment_list output/myVarientPlaylist.m3u8 /
-segment_format mpegts /
output/myAudioVideoFile-%04d.ts

Mi entrada está en formato ismv y contiene un flujo de video y audio:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 320x240, 348 kb/s, 29.97 tbr, 10000k tbn, 59.94 tbc
Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 63 kb/s

Hay un problema relacionado con el muxing que está causando una gran cantidad de sobrecarga que se agrega a las secuencias. Así es como me describieron el problema para el audio:

Entonces, para un flujo aac dado, la sobrecarga será del 88% (ya que 200 bytes se asignarán a paquetes de 2 x 188 bytes).

Para el video, los paquetes iframe son bastante grandes, por lo que se traducen muy bien en paquetes .ts, sin embargo, las diferencias pueden ser tan pequeñas como un paquete de audio, por lo tanto, tienen el mismo problema.

La solución es combinar varios paquetes de AAC en un flujo más grande antes de empaquetarlos en .ts. ¿Es esto posible fuera de la caja con FFMPEG?

Answer 1

He arreglado el peor problema de la sincronización de la salida de TS en cada cuadro en http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=75c8d7c2b4972f6ba2cef605949f57322f7c0361 - por favor intente una versión después de eso.

Answer 2

No es posible Los códecs se basan en el contenedor de encapsulación para el encuadre, lo que significa señalar el inicio y la longitud de un marco.

Su gráfico en realidad pierde un elemento, que es el paquete PES. Su cuadro de audio se colocará primero en un paquete PES (que indica su longitud ), luego el paquete PES se cortará en trozos más pequeños que serán paquetes TS.

Por diseño, no puede iniciar un nuevo paquete PES (que contiene un cuadro de audio en su caso) en un paquete TS que ya contiene datos. Un nuevo paquete PES siempre comenzará en un nuevo paquete TS. De lo contrario, sería imposible comenzar a reproducir a mitad de la secuencia (ubicación de transmisión); sería imposible saber en qué byte del TS comienza el nuevo PES (recuerde que se ha perdido el comienzo del PES actual).

Hay algunos factores atenuantes, el hardware de red probablemente comprimirá el relleno FF FF FF . Además, si está utilizando HTTP (en lugar de UDP o RDP), la compresión gzip se puede habilitar (pero dudo que ayude mucho).