¿Tasas de bits variables para la transmisión?

Estoy creando ajustes preestablecidos para que nuestros usuarios conviertan los videos a un formato apropiado para nuestro repositorio de videos en línea. Dado que ha pasado un tiempo desde que construí algo como esto desde cero, he estado mirando lo que otros recomiendan y noté que muchos de ellos recomiendan específicamente la codificación de tasa de bits variable. Por ejemplo:

https://support.google.com/youtube/answer/1722171?hl=en

Incluso con transmisión progresiva o pseudotransmisión, ¿no introduciría eso pausas y tartamudeos en la reproducción una vez que llegue a un segmento con una tasa de bits alta? Simplemente parece extraño como recomendación general cuando es probable que cree una mala experiencia de reproducción. ¿O simplemente estoy sobreestimando los problemas ya que han pasado algunos años desde la última vez que lo investigué? ¿Utiliza generalmente una tasa de bits variable para la entrega en línea en estos días?

Creo que no entiendes lo que hace la codificación de tasa de bits variable. No presenta tartamudeos ni pausas.
IDK que rechazó esto. No es una mala pregunta, en mi opinión, solo una pregunta para principiantes.
Oh, también tenga en cuenta que su enlace es sobre cómo hacer videos para CARGAR en youtube, para que se transcodifiquen antes de transmitirlos. Ese caso de uso de codificar una vez, decodificar una vez, sin restricciones de tiempo real, es completamente diferente de alojar videos para que las personas los transmitan. Para cargar a YouTube, desea utilizar una gran cantidad de bits y, si tiene el ancho de banda de carga, el tiempo de codificación tiene un valor similar al tamaño de archivo resultante. Así que podrías usar x264 --crf 16 --preset fast.
No estoy malinterpretando, ni soy un principiante (construí mi primer servicio de transmisión de video en 1997 en realidad). Responderé al resto en su respuesta allí, pero para aclarar, el enlace fue solo un ejemplo de una recomendación que veo en todas partes. Según sus respuestas, parece que todo el mundo simplemente asume que las tuberías y los búferes son lo suficientemente grandes como para compensar los picos en las tasas de bits en estos días.

Respuestas (1)

Los reproductores almacenan en búfer las transmisiones. Cuanto mayor sea el tamaño del búfer, mayor será la ventana que tiene el codificador para usar tasas de bits más altas para el contenido duro, y luego menos bits antes o después para el contenido fácil, para lograr una calidad similar para todo el video.

Asumiré que vas a usar h.264 (también conocido como AVC) como códec, ya que es el estándar de facto para la transmisión de video en Internet. VP8 no es tan buena calidad. VP9 puede verse mejor que h.264, pero el soporte es limitado. HEVC (h.265) también es mejor que h.264, pero, de nuevo, la compatibilidad con los jugadores es limitada. (Y la aceleración de decodificación de hardware no se generalizará durante años. Esto es importante, porque HEVC requiere mucha CPU para decodificar, más que AVC).

Las comparaciones de calidad de las que hablo son con los mejores codificadores disponibles para cada códec. x264 para AVC, VPx de Google para VP8/VP9 y x265 para HEVC. Todos con ajustes activados casi por completo. Sin embargo, x265 comenzará a pasar a segundos por cuadro en lugar de cuadros por segundo para 1080p con configuraciones tan lentas. (x264 órdenes de magnitud más rápido, ya que ha estado esencialmente maduro durante un par de años, y se han encontrado pocas mejoras de velocidad o mejoras de calidad).

Todos estos codificadores son software gratuito de código abierto. Es bueno que no tengas que pagar nada para obtener códecs de calidad mundial en estos días. :)

Un éxito aleatorio de Google en x264 vbv para transmisión: http://forum.doom9.org/showthread.php?t=147460

Un ejemplo de x264 --fullhelp:

  Constant bitrate at 1000kbps with a 2 second-buffer:
        x264 --vbv-bufsize 2000 --bitrate 1000 -o <output> <input>

(Sin embargo, en realidad no use el modo de tasa de bits de destino de un solo paso. O 2 pases si tiene una tasa de bits de destino específica, o crf con una calidad de destino).

editar: el uso recomendado para la transmisión, según el desarrollador principal de x264 (Jason Garrett-Glaser), es el modo de objetivo de calidad (CRF) con tasa de bits restringida por VBV. p.ej

x264 --vbv-bufsize 2000 --vbv-maxrate 1000 --crf 22 -preset slower -o <output> <input>

vbv-maxratees la velocidad máxima a la que se puede llenar el búfer. (es decir, el ancho de banda máximo de la red). vbv-bufsizees, por supuesto, el tamaño del búfer, que permite picos de tasa de bits no sostenidos superiores a vbv-maxrate.

Y, por supuesto, si está codificando una vez para crear un archivo que se transmitirá muchas veces, invierta tanto tiempo de CPU como pueda. El tiempo de codificación tiene poca importancia en comparación con obtener la mayor calidad por tasa de bits (intercambio de distorsión de tasa, también conocido como RD). La codificación solo ocurre una vez, y cualquier bit que pueda guardar (manteniendo la misma calidad) se guarda para cada descarga. por ejemplo, use x264 con --preset veryslow.

Como dices, los reproductores amortiguan las transmisiones. Entonces, ¿qué sucede cuando se agota el búfer? ¡Por qué la reproducción tartamudea y se detiene, por supuesto! Tome su ejemplo citado anteriormente. Imagine que un usuario obtiene una conexión sólida de 1200 kbit/s a mi servicio. Imagine que el usuario está viendo una transmisión que requiere alrededor de 1000 kbit/s durante los primeros cinco minutos. ¡Gran! Pero ahora, si ese archivo es VBR (tenga en cuenta que su ejemplo no lo es), su archivo podría requerir repentinamente 2500kbit/seg durante los próximos cinco minutos. Su búfer de 2 segundos se agota bastante rápido y el espectador básicamente ya no puede ver el video.
El objetivo de decirle al codificador el tamaño del búfer es que pueda tenerlo en cuenta para el control de velocidad, para asegurarse de que no se desborde el búfer. x264 siempre le avisará si no puede cumplir con sus requisitos de VBV. (por ejemplo, tasa de bits extremadamente baja para HD, y no podría llegar allí ni siquiera desenfocando todo).
Creo que lo que ha encontrado hasta ahora no explica que VBR no tiene por qué significar VBR solo de calidad pura. Los codificadores de audio y video modernos ahora admiten el control de velocidad de VBR restringido, donde también se obedecen los límites de velocidad de bits locales y generales. Pero, de lo contrario, son libres de gastar bits donde sea necesario para obtener la mayor calidad posible para todo el clip. Tiene razón en que hay un problema aquí que debe tenerse en cuenta, y --vbv-buffsizees cómo se hace.
editar: actualicé mi respuesta después de buscar en Google nuevamente. vbv-maxratees la tasa de llenado del búfer, no el pico de decodificación limitado por la CPU del decodificador. Y CRF + VBV es la forma recomendada de codificación de video en línea (en tiempo real) o fuera de línea para transmisión.
¿Tasas de bits variables para la transmisión?
RespuestasAquíPolítica de privacidad1y, 0v