Transmisión MJPEG

en https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/pktvideoaag.html

dice:

Otro tipo de compresión de video es MJPEG... el flujo de video resultante es más grande pero los tamaños de los paquetes son más consistentes a 1316 bytes (carga útil)

¿es eso cierto?

Probablemente. Mjpeg no tiene compresión entre cuadros. Hace que las tasas de datos sean más predecibles.
@DigiVisionMedia Ok, ¿eso tiene algo que ver con el tamaño del paquete?
No sé. Solo estoy especulando. Con un esquema de compresión como mjpeg, cada fotograma suele tener un tamaño muy parecido al de los anteriores y posteriores. Un protocolo de transmisión inteligente podría usar esto en su beneficio.
Consulte el artículo de wikipedia MJPEG . "La transmisión HTTP [MJPEG] crea paquetes de una secuencia de imágenes JPEG que los clientes pueden recibir". Apoya mi especulación. En cuanto a verificar ese número de tamaño de paquete exacto, no puedo encontrar nada. Parte del problema es que no hay un estándar oficial en MJPEG. Es como el tatarabuelo del video web moderno, nacido cuando la web aún era salvaje.
@DigiVisionMedia, supongo. Creo que cada cuadro nunca va a caber en un paquete de satélite Ethernet e IP o RTTY o ATM o X.25 o Ku Band QAM de todos modos. Entonces, si los marcos tienen un tamaño similar, no tiene nada que ver con los paquetes. Vas a llenar un montón de paquetes, como miles y miles antes de obtener incluso un cuadro completo. Ya sea que llene ese último paquete hasta 1299 o 1305, no hará ninguna diferencia.
@DigiVisionMedia En una segunda nota, he visto que MJPEG también se vuelve muy variable en la tasa de bits, todo depende de la complejidad del contenido. Si tiene una pantalla de banner como "WORLD TV" y es toda una pantalla blanca y letras negras grandes, el cuantificador JPEG reduce cada cuadro a 98 o 200 k. Por lo tanto, no importa no tener compresión temporal dentro del cuadro porque cuando obtiene un cuadro después de los cuadros de "WORLD TV" que es como 400 colores diferentes, sesenta y setenta siluetas diferentes de animales, personas, etc., obtiene la idea de la tasa de bits cohetes a 1M 2M 3Mbits/seg.
Eso es cierto para todas las compresiones. Si el video es muy activo, toma más datos. Pero los videos significativos rara vez saltan de colores estáticos de 2 bits a escenas de la naturaleza de 16 bits con mucho movimiento. Al menos, no más de un par de veces aquí y allá. Como dije, estaba especulando. Entiendo mjpeg bastante bien. No entiendo nada de redes. Podría estar completamente apagado.
@DigiVisionMedia Bueno, solo tenga en cuenta lo básico. La transmisión de datos a través de una red siempre ocurre en pequeños fragmentos, como REALMENTE pequeños, como 1316 BYTES . Entonces, incluso un color de 8 bits de 320x288 será una gran cantidad de paquetes. Esta afirmación en el documento de CICSO parece que alguien la acaba de enviar por correo porque no se me ocurre nada que tenga algún sentido.
@DigiVisionMedia Creo que tal vez si miras una LÍNEA ARRENDADA o un TRANSPONDEDOR SAT sabes que tienes una cierta velocidad de enlace y si no la usas a esa velocidad, te cobran de todos modos, así que si terminas comprimiendo tu El video H264 hasta 800 KB/S es simplemente estúpido porque pagas por 10 MB/S. Así que sabes que MJPEG lo reducirá a 8 MB/s y será básicamente más alto que h264. Todavía no estoy seguro de su afirmación de que la tasa de datos es más predecible.

Respuestas (1)

Aunque MJPEG puede tener una tasa de bits promedio local temporal más estable y más alta, su tasa de bits puede variar ampliamente según el contenido de entrada. Consulte Compresión MJPEG ; la afirmación de que las tramas/paquetes de red resultantes serán más consistentes no tiene ningún fundamento. Puede ser, a nivel macro, dado, por ejemplo, un transpondedor satelital de haz puntual de banda Ku de 10 Mb/s, MJPEG puede simular una función HARD MUXRATE que normalmente realizaría el muxer MPEG Transport Stream, pero incluso esto es cuestionable, dado que MJPEG es altamente variable. bitrate dado un contenido muy simple.

Muxrate duro: https://stackoverflow.com/questions/44392689/ffmpeg-vbr-cbr-conversion-and-streaming-of-mpeg-2-ts-video-files