Obtuve el Pi B + y la cámara Pi y ahora estoy tratando de encontrar la configuración más eficiente (CPU baja) y la latencia más baja para transmitir video codificado H.264 desde la cámara al servidor de mi casa.
He leído lo siguiente:
(Todos los enlaces usan gstreamer-1.0 de deb http://vontaene.de/raspbian-updates/ . main.)
Se ha hecho mucho al respecto en los últimos años.
Originalmente, teníamos que canalizar la salida de raspividen gst-launch-1.0(ver enlace 1).
Luego (enlace 2) se creó el controlador oficial V4L2, que ahora es estándar, y permite obtener directamente los datos sin una tubería, utilizando solo gstreamer (ver especialmente la publicación de towolf »sáb 07 de diciembre de 2013 3:34 pm en el enlace 2):
Remitente (Pi): gst-launch-1.0 -e v4l2src do-timestamp=true ! video/x-h264,width=640,height=480,framerate=30/1 ! h264parse ! rtph264pay config-interval=1 ! gdppay ! udpsink host=192.168.178.20 port=5000
Receptor: gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false
Si entiendo correctamente, ambas formas usan la GPU para hacer la decodificación H264, pero la última es un poco más eficiente ya que no necesita pasar por el núcleo otra vez ya que no hay una tubería entre los procesos involucrados.
Ahora tengo algunas preguntas sobre esto.
¿Sigue siendo la última la forma más reciente de obtener eficientemente H264 de la cámara? He leído sobre
gst-omx, lo que permite las tuberías gstreamer como... video/x-raw ! omxh264enc ! .... ¿Esto hace algo diferente al simple usovideo/x-h264, o podría incluso ser más eficiente? ¿Cual es la diferencia?¿Cómo puedo saber qué plugin de codificación gstreamer se usa realmente cuando uso la
video/x-h264 ...canalización? Esto parece estar especificando el formato que quiero, en comparación con las otras partes de la tubería, donde explícitamente nombro el componente (código) (comoh264parseofpsdisplaysink).En esta respuesta al enlace 1, Mikael Lepistö menciona "Eliminé un paso de filtro innecesario del lado de transmisión" , lo que significa que cortó el
gdppayygdpdepay. ¿Qué hacen esos? ¿Por qué son necesarios? ¿Realmente puedo quitarlos?También menciona que al especificar
caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96"parámetros para eludpsrclado receptor, puede iniciar / reanudar la transmisión en el medio de la transmisión. ¿Qué logran estos límites, por qué estas opciones específicas, dónde puedo leer más sobre ellos?Cuando hago lo que se sugiere en las preguntas 3 y 4 (agregando
caps, soltandogdppayygdpdepay), mi latencia de video se vuelve mucho peor (y parece acumularse, la latencia aumenta con el tiempo, y después de unos minutos, el video se detiene). ¿Por qué podría ser eso? Me gustaría obtener la latencia que obtuve con el comando original, pero también tengo la característica de poder unirme a la transmisión en cualquier momento.He leído que RTSP + RTP usualmente usan una combinación de TCP y UDP: TCP para mensajes de control y otras cosas que no deben perderse, y UDP para la transmisión de datos de video real. En las configuraciones anteriores, ¿estoy realmente usando eso, o solo estoy usando UDP? Es un poco opaco para mí si gstreamer se encarga de esto o no.
¡Agradecería cualquier respuesta a una sola de estas preguntas!
cat file | grep ...lugar de grep ... file. La tubería agrega otra capa de copia hacia y desde el núcleo, que es fácilmente medible, especialmente en dispositivos con poco ancho de banda de memoria. Si gstreamer puede leer directamente el archivo del dispositivo, ¿por qué no usarlo? Con respecto a su raspivid | cvlcsugerencia: estaba usando esto antes de cambiar a la solución basada en gstreamer, tiene una latencia de hasta 3 segundos más que gstreamer (no sé por qué).
cvlcusa ~ 45%, pero solo pasar por una tubería a esa velocidad de datos (teniendo en cuenta nuevamente que la tubería no lo está desacelerando ) apenas movería la aguja, creo. Me gusta <5%. No es totalmente insignificante si quieres hacer esto de la manera más eficiente posible, por supuesto ...
raspivid | cvlcque es 40-50%. Las personas pueden responder mejor a una pregunta que los desafía a mejorar en una figura específica. En este momento estás preguntando mucho por qué, sin explicar por qué cada uno es significativo.
|crea algún problema en este contexto es una pieza increíble de BS ¿Has probado algúnraspivid | cvlcmétodo? No he tenido la cámara durante mucho tiempo o mucho tiempo para jugar con ella, pero usar eso para producir una transmisión http (visible en Linux en el otro extremo convlc) parece funcionar bien.