¿Cómo realizar una encoding en tiempo real de una secuencia de imágenes fijas (video) para enviarlas desde C # a Python?

Obtengo los marcos de Profundidad y Color del Kinect 2, usando el SDK de Kinect ( C# ), y los envío a los clientes de Python usando ZeroMQ .

 this.shorts = new ushort[ 217088]; // 512 * 424 this.depthBytes = new Byte[ 434176]; // 512 * 424 * 2 this.colorBytes = new Byte[4147200]; // 1920 * 1080 * 4 public void SendDepthFrame(DepthFrame depthFrame) { depthFrame.CopyFrameDataToArray(this.shorts); Buffer.BlockCopy(shorts, 0, this.depthBytes, 0, this.depthBytes.Length); this.depthPublisher.SendByteArray(this.depthBytes); } public void SendColorFrame(ColorFrame colorFrame, WriteableBitmap map) { colorFrame.CopyRawFrameDataToArray(this.colorBytes); this.colorPublisher.SendByteArray(this.colorBytes); } 

Ya que estoy enviando datos sin comprimir, estoy sobrecargando la red y me gustaría comprimir estos marcos.

¿Es esto posible para un procesamiento continuo de flujo?

Sé que puedo hacerlo comprimiendo en un PNG/JPEG , pero me gustaría mantener la noción de flujo de video.

El objective es enviar los datos comprimidos en C# y luego decodificarlos en Python.

¿Hay alguna libs que permita hacer eso?

Puede olvidarse de la compresión por el momento y reducir la escala para PoC

Si su diseño realmente tiene sentido, intente enfocarse más bien en la funcionalidad CV principal, a un costo de FPS reducido (escala reducida), profundidad de color, resolución (en este orden de prioridad).

Los datos indicados producen aproximadamente 1 Gbps de flujo de datos de salida, donde el próximo procesamiento de CV ahogará de todos modos, con un notable rendimiento de procesamiento de CV (retraso / latencia) / representaciones de datos provisionales en los cuellos de botella en la gestión de memoria.

Dicho esto, el PoC puede beneficiarse de 1/4 – 1/10 de adquisición de FPS / procesamiento de flujo más lento y la solución ajustada puede mostrarle, cuántos nanosegundos por ttwig tiene su código en el margen de procesamiento de flujo (para finalmente decidir si hay tiempo y potencia de procesamiento suficiente para incluir cualquier tipo de procesamiento de CODEC en la tubería que funciona de otra manera)

introduzca la descripción de la imagen aquí

compruebe los retrasos de la ventana inferior izquierda en [usec] haciendo clic con el botón derecho -> [Abrir en una nueva pestaña]
para ver ampliado y realizar una escala / orden de magnitud de unas pocas latencias reales de openCV openCV de aproximadamente 1/4 de su imagen fija FullFD en un procesamiento del mundo real con FPS mucho más pequeños en un dispositivo i7 / 3.33 GHz un solo hilo , donde los tamaños de caché L3 pueden transportar hasta 15 MB de datos de imágenes con las latencias más rápidas de menos de 13 ns ( core-local access case ) .. 40 ns ( core-remote NUMA access case ) + naturaleza de bloque del CV -el procesamiento de imágenes orquestado se beneficia mucho de una tasa de errores de caché mínima, si no nula, pero este no es un escenario de hardware de implementación universal en el que basarse: introduzca la descripción de la imagen aquí
Los costos ( penalty ) de cada falta de memoria caché y la necesidad de solicitar y realizar un acceso a los datos en la DDR-RAM principal son aproximadamente +100 ns >>> https://stackoverflow.com/a/33065382/3666197

Sin un canal de trabajo , no hay datos cuantitativos sobre el procesamiento continuo de la stream / su margen por ttwig para decidir el dilema a priori de CODEC implementación de PoC propuesta.