¿Cómo puedo transmitir video H.264 desde el módulo de cámara Raspberry Pi a través de un servidor web?

50

Así que hoy obtuve la cámara Raspberry y las imágenes fijas funcionan bien.

Capture una imagen en formato JPEG:

raspistill -o image.jpg

Capture un video de 5 segundos en formato H.264 :

raspivid -o video.h264

No quiero instalar ninguna aplicación adicional, ya que quiero aprovechar HTML5 que está fácilmente disponible. Como Chrome / Safari tiene decodificadores integrados para H.264, solo quiero apuntar mi navegador a la URL y ver la transmisión.

¿Cómo puedo conseguir esto?

webcam streaming-video camera Piotr Kula
fuente
2
Estoy trabajando en esto también. Yo creo que es necesario agregar MP4 apoyo a nginx o algo por el estilo. Te haré saber si tengo un gran avance.
retrantha
@recantha ¿Has tenido nuevos avances con la transmisión de video?
Piotr Kula
3
La mejor solución que he encontrado se basa en RaspiMJPEG de Silvan Melchoir. Echa un vistazo a mi blog que contiene un enlace al foro de la Fundación Raspberry Pi que explica todo. ( recantha.co.uk/blog/?p=11176 )
recantha
2
Sí, se ve increíble poder transmitir a varios dispositivos. ¿Qué FPS y retraso obtienes? Logré que uv4l funcione bastante bien con VLC y OSD. Una demo muy corta y mala. Hará uno mejor pronto. Se hizo tarde en la noche después de horas de prueba y error. youtu.be/LO10Ytlauag
Piotr Kula
@ppumkin, ¿cómo puedo grabar a través de un script de Python mientras RaspiMJPEG se está ejecutando? Da un inicio de grabación de video, pero graba en formato .h264, ¿cómo puedo hacer que un script de Python se ejecute presionando start_recording?
Coderaemon

Respuestas:

32

Streaming con HLS

Método patentado de Apple para transmitir video en vivo. Se llama HTTP Live Streaming (HLS) y solo es compatible con la tecnología de Apple. Google (Chromium / YouTube) usa su propia implementación llamada dash mpeg y todos los demás están confundidos o usan H.264 encapsulado en MP4 .

PROS

  • Puede transmitir HD 1080p en LAN a cualquier dispositivo que admita .m3u8listas de reproducción
  • Utiliza semántica HTML5 (pero no es un formato estandarizado)
  • Se puede utilizar algún soporte en software premium de terceros como jwplayer 6

CONTRAS

  • Tiene un retraso de al menos 5 segundos (en esta aplicación, pero usando la duplicación del iPhone a AppleTv logran 50 ms - 500 ms de alguna manera). Por lo tanto, no es bueno para aplicaciones de control remoto donde se requieren reacciones instantáneas, es decir, robots o helicópteros.
  • Tiene que pagar por software de terceros si desea ampliar la compatibilidad con el navegador que puede parpadear.

m3u8

  • .m3u8es simplemente una versión UTF-8 del formato M3U. (Los archivos .m3u pueden tener varias codificaciones). Algunas personas afirman que cambiar el nombre de un .m3u8 a .m3u funcionará como se espera en todos los navegadores HTML5. Intenté esto, y no funcionó para mí.

El concepto detrás de esta transmisión es que segmentos cortos de archivos, de al menos 5 segundos de duración (en este ejemplo, es posible que haya nuevas formas disponibles para acelerarlo) se graban y guardan en un archivo adecuado. El archivo de la lista de reproducción se actualiza con el nuevo nombre de archivo y el cliente siempre sondea esta lista de reproducción y descarga el archivo más reciente. Hay algunas mecánicas involucradas para fusionar el video sin problemas en el cliente. Es por eso que otros desarrolladores no quieren implementar esto porque requiere mucho esfuerzo y no cumple con los estándares HTML5 (a pesar de que no hay un estándar HTML5 adecuado para las transmisiones en vivo ?? Ehh, suspiro ).

Instalando

Necesita compilar ffmpeg, no lo use apt-get installpara FFmpeg

Esto puede tomar hasta 5 horas - Se tiene a ser la versión 1.1 o superior que soporta segmento de streaming. Puede usar esto para clonarlo y compilarlo.

cd /usr/src
git clone git://source.ffmpeg.org/ffmpeg.git

cd ffmpeg
./configure
make && make install
  • Instalar nginx (engine-x) : nginx fue especialmente diseñado para dispositivos integrados y es el servidor web con PHP más liviano y rápido disponible en este momento. (Sí, es mejor que Apache voluminoso )
  • Cree un directorio, por ejemplo, viva en su carpeta www, /usr/share/nginx/www/

Haga un archivo de script Bash llamado algo así video.sh, aplíquelo chmod +xy péguelo. Cambie la carpeta base a donde viva su servidor HTTP . Solía nginx,/usr/share/nginx/www/

#!/bin/bash

base="/data/live"

cd $base

raspivid -n -w 720 -h 405 -fps 25 -vf -t 86400000 -b 1800000 -ih -o - \
| ffmpeg -y \
    -i - \
    -c:v copy \
    -map 0:0 \
    -f ssegment \
    -segment_time 4 \
    -segment_format mpegts \
    -segment_list "$base/stream.m3u8" \
    -segment_list_size 720 \
    -segment_list_flags live \
    -segment_list_type m3u8 \
    "segments/%08d.ts"


trap "rm stream.m3u8 segments/*.ts" EXIT

# vim:ts=2:sw=2:sts=2:et:ft=sh

Crea un archivo HTML que cargará la lista de reproducción

<html>
  <head>
    <title>PiVid</title>
  </head>
  <body>
    <video controls="controls" width="1280" height="720" autoplay="autoplay" >
      <source src="stream.m3u8" type="application/x-mpegURL" />
    </video>
  </body>
</html>

Apoyo

  • iPhone, abre la página, pero cae en QuickTime . ¡La calidad es realmente asombrosa!
  • Safari de Windows, se transmite bien.
  • Macintosh o Windows, QuickTime. Corrientes bien.
  • Android 2.3.5 y no funcionaba, pero se suponía que era compatible desde 2.1.x
  • Windows, Chrome: nada
  • Windows, Internet Explorer 10 --- Nada (tipo de video no compatible)
  • Windows, reproductor multimedia VLC : nada

Referencia: http://www.raspberrypi.org/phpBB3/viewtopic.php?p=351392&sid=5b9a46f5eea2c7a0887d2efdfa7edade#p351392

Código original: https://github.com/AndyA/psips/blob/master/examples/hls.sh

ppumkin
fuente
En lo que respecta a acelerar la compilación de ffmpeg Para evitar la baja capacidad computacional de RPI y los largos tiempos de compilación de ffmpeg, intenté usar Qemu con Wheeze pero encontré algún obstáculo para iniciar sesión y tuve que probar con una imagen de Arch . Esto funcionó. También intenté Sqeeze en una imagen de Ubuntu , a través de VirtualBo
luboP
2
¿Hay alguna manera de eliminar automáticamente los segmentos antiguos? La tarjeta SD se llena después de un tiempo. También me gustaría que se eliminen, puedo ejecutar esto en un tmpfs y no arruinar la tarjeta SD.
Dimme
2
@Dimmme Si agrega -segment_wrap 10como argumento a ffmpeg, utilizará un máximo de 10 segmentos de archivos.
Gregers
¿Alguien ha conseguido que esto funcione? Los archivos se crean, pero parecen perder información SPS / PPS, por lo que el video no se reproducirá en iOS Safari ni VLC. El stream.m3u8 tampoco se incluyó segments/al apuntar a los archivos de segmento, por lo que solté la carpeta de segmentos. ¿Entendí mal algo?
Gregers
necesita canalizar la secuencia a través del filtro binario PSIPS. Se suponía que la versión más nueva de raspicam debía hacer esto ... pero por alguna razón no pude hacerlo funcionar sin PSIPS
Piotr Kula
23

UV4L MMAL

Gracias por comentar desde @mpromonet para la actualización del controlador Linux-Projects V4L2 que ahora implementa MMAL de manera muy eficiente, pero aún es un trabajo en progreso.

Siga estas instrucciones para instalar el repositorio de proyecto de Linux e instalar el controlador UV4L con extras. Luego instale el servidor y mjpeg. Si lo desea, también puede experimentar con los demás.

Después de instalar todo, puede acceder al servidor HTTP en el puerto 8080. También debe verificar el /etc/uv4l/confarchivo y configurarlo si desea mjpeg o H.264, ya que marca la diferencia, pero puede ajustar algunas configuraciones a través de la web incorporada servidor.

HTML 5

Esto es lo que todos estábamos esperando (llamado WebRTC ) y gracias al nuevo controlador funciona muy bien (en una Raspberry Pi 2).

Primero, siga estos pasos, http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=14 :

curl http://www.linux-projects.org/listing/uv4l_repo/lrkey.asc | sudo apt-key add -

# Add the following line to the file /etc/apt/sources.list
# deb http://www.linux-projects.org/listing/uv4l_repo/raspbian/ wheezy main

sudo apt-get update
sudo apt-get install uv4l uv4l-raspicam

sudo apt-get install uv4l-raspicam-extras

Luego, en su Raspberry Pi 2 instale esto el WebRTC (para un Raspberry Pi 1, lea el sitio vinculado para otras opciones)

sudo apt-get install uv4l-webrtc

Reinicie todos los controladores y vaya a

http://raspberry:8080/

Ahora tiene transmisión de video de baja latencia y alta calidad directamente en un navegador moderno como Chrome o Firefox. (Tal vez Safari, pero no puedo comprobarlo porque ya no hacen Winblows e Internet Explorer ... eh)

MJPEG

Por defecto, se usa mjpega 1080p, y es muy lento. Lo ajusté a 800x600 cuadros de tamaño y usando algo como iSpy para procesar video. Por seguridad, obtengo unos 10 fps en un video nítido. Es mucho mejor que los 3 fps a 640x480 antes de este controlador. Funciona en iPhone con Safari, Android Chrome y casi todo lo demás.

http://raspberrypi:8080/stream/video.mjpeg

Esto también significa que motiondebería (todavía necesito probar y comparar) funcionar mucho mejor ahora. Asegúrese de establecer la configuración para usar v4l2_palette 8ov4l2_palette 2

H.264

Esto ahora se ha solucionado para la "transmisión", y no tenemos que hacer grandes esfuerzos para ver el video H.264 a través del reproductor multimedia VLC . El flujo es aún RAW H.264, por lo que debe demuxux o transcodificar / encapsular si necesita que funcione en otro lugar. Debe ajustar el bitrate=xxxxxxarchivo de configuración si está transmitiendo a través de Wi-Fi.

En el reproductor multimedia VLC, debe decirle que desea utilizar el demuxer H.264. Entonces, si está utilizando la GUI, asegúrese de agregar el argumento :demux=264. Desde la línea de comandos, vlc http.../video.h264 --demux h264. De lo contrario, solo verá una pantalla en blanco aunque el LED de la cámara esté encendido.

http://raspberrypi:8080/stream/video.h264

Voila! Transmisión en HD con aproximadamente 500 ms de retraso (con ajustes, hasta 200 ms). Definitivamente es mucho más fácil que usar los viejos métodos. La calidad y el FPS son excelentes, pero no puede incrustar esto en HTML5 sin transcodificar a MP4 o WebM . Espero que esto se implemente, ya que realmente hará de este un gran servidor independiente.

RTSP / RTMP / RTP

No compatible / implementado

http://www.linux-projects.org/uv4l/tutorials/rtsp-server/

HLS

No compatible / implementado

No hay ningún video4linuxcontrolador disponible todavía. Esto significa que no podemos usar ffserver para transmitir datos usando /dev/video0o simlar como una cámara web USB.

Es por eso que es tan difícil encontrar la transmisión en vivo adecuada para los navegadores HTML5.

Piotr Kula
fuente
Ahora hay un video4linuxcontrolador, el controlador V4L2 oficial bcm2835-v4l2 y el controlador V4L2 del espacio de usuario [ linux-projects.org/modules/sections/…
mpromonet
¿Es un controlador v4l real o es solo esa envoltura alrededor de raspivid que da un rendimiento terrible?
Piotr Kula
1
El controlador oficial utiliza la interfaz MMAL, consulte el código fuente [ github.com/raspberrypi/linux/blob/rpi-3.12.y/drivers/media/… . El rendimiento parece correcto.
mpromonet
He estado jugando con esto durante 3 días. La codificación mjpeg es definitivamente mucho más estable y puede ver 800x600 @ 10fps en iPhone, Android o iSpy, de manera confiable. h264 es excelente a 1080p 30 fps y podemos ver esto en vlc usando la --demux h264bandera. Todavía necesitamos transcodificar esto para usarlo en dispositivos móviles o incrustarlo como mp4 / webm en páginas web. Pero es realmente genial avanzar de manera eficiente y de calidad. No confunda con el "otro" controlador UV4L que no es un proyecto de Linux que es basura.
Piotr Kula
Tenga en cuenta que agregar: demux = 264 en el método H264 es para el servidor vlc, no para el cliente vlc. Entonces, la línea de comando para iniciar la transmisión en la frambuesa para obtener compatibilidad con vlc en teléfonos inteligentes es:/usr/bin/cvlc v4l2:///dev/video0 --v4l2-width 800 --v4l2-height 400 --v4l2-chroma h264 --sout '#standard{access=http,mux=ts,dst=0.0.0.0:8080}' :demux=264
Jaime M.
10

Streaming con MJPEG

U4VL

Una interfaz de kernel con una compilación en el servidor HTTP (S).

http://www.linux-projects.org/uv4l/tutorials/streaming-server/

Interfaz web Raspberry Pi Cam

Un buen proyecto de silvanmelchior que implementa un servidor web, como dvr, servidor de transmisión de múltiples destinos . Necesita más información

https://github.com/silvanmelchior/RPi_Cam_Web_Interface

Método heredado

La transmisión con mjpg es compatible con casi todos los navegadores, incluido Internet Explorer 6. Muchas cámaras usadas antes de H.264 usaban hardware mjpg, que esencialmente descargaba archivos JPEG lo más rápido posible en una carpeta mientras que mjpg leía el archivo en un búfer y lo eliminaba ellos. Algunos dispositivos pueden alcanzar hasta 25 fps e incluso si tuviera una mala conexión, obtendría al menos 1 fps.

El soporte para mjpg se eliminó en las cámaras HD porque el archivo JPEG se hizo demasiado grande para transmitir por Internet y H.264 es un protocolo mucho más rápido y de mejor calidad.

Dado que no tenemos forma de transmitir H.264 usando el módulo de la cámara de forma nativa, esto parece ser una alternativa viable ...

Es casi instantáneo, pero no espere obtener más de 1.5 fps. ¡Esto se reduce a raspistillser MUY LENTO! El uso de la función de lapso de tiempo establecido en 100 ms, que debería darnos 10 fps, no funciona porque raspistillsimplemente se ahoga y tiene serios problemas de rendimiento dentro de sí mismo.

  1. Cambio /tmppara usar RAM para la velocidad /etc/default/tmpfs: cambio RAMTMP=yes(Este es un esfuerzo para aumentar los fps, pero raspistill simplemente no puede mantenerse por sí mismo).
  2. Reiniciar
  3. apt-get install git
  4. apt-get install libjpeg8-dev
  5. apt-get install libv4l-dev
  6. apt-get install imagemagick
  7. cd /usr/src, mkdir mjpg-streamer, cd mjpg-streamer ...
  8. git clone https://github.com/engine12/mjpg-streamer.git
  9. make USE_LIBV4L2=true clean all
  10. OPCIONAL Si tiene errores
  11. sudo ln -s /usr/include/libv4l1-videodev.h /usr/include/linux/videodev.h
  12. sudo ln -s /usr/include/lib4l2.h /usr/include/linux/lib4l2.h
  13. Dentro del archivo MAKE, comente todos los complementos, excepto input_file y output_http, y vuelva a hacerlos. Tuve muchos problemas aquí.
  14. Copie el binario, mjpg_streamery sus complementos input_*.soy output_*.sopara /usr/local/bin. De lo contrario, ejecútelo directamente desde el directorio src.
  15. Final opcional
  16. mkdir /tmp/stream
  17. raspistill -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &
  18. LD_LIBRARY_PATH=./ ./mjpg_streamer -i "input_file.so -f /tmp/stream" -o "output_http.so -w ./www" (ejecute esto donde están los binarios y los complementos)
  19. Ir http://<IP-address>:8080
  20. Aquí hay algunas opciones, disfrute de la transmisión "en vivo" a la antigua usanza ... compatible con la mayoría de los navegadores: moderno, antiguo y experimental.

Luché por compilarlo durante aproximadamente 5 horas ... suspiro , pero creo que lo usaré ya que puedo acceder a la transmisión desde cualquier teléfono y cualquier navegador. Solo tengo que esperar hasta que tengamos mejores conductores ... Otro año o dos. :(

No importa qué calidad pruebo, no obtengo ni más rápido ni más lento que 1 fps usando la transmisión. Utilicé 720p y 1080p y solo la calidad de imagen mejora, pero fps no es una diferencia en LAN. Supongo que configuraciones más pequeñas ayudarán con WAN / 3G u otras transmisiones de radio.

raspistill escribe la imagen en un solo archivo. Esto podría ser un cuello de botella. Escribe el archivo, mjpg strreamer lo lee y lo elimina causando un bloqueo de E / S, por lo que raspistill no puede escribir en el archivo.

Lo único que se me ocurre es usar raspivid canalizado en FFmpeg que creará archivos JPEG para nosotros. Necesito probar esto y posiblemente sea mucho más rápido que usar raspistill. Logré obtener 25 fps con una calidad impactante, y se retrasó unos 10 segundos ... Ajustar la configuración me dio unos 3 fps, pero 100% de CPU. No se está utilizando hardware para procesar la transmisión de video ...

raspivid -w 640 -h 480 -fps 25 -vf -t 86400000 -b 1800000 -o -  \
ffmpeg -i - \
    -f image2(?) \
    -c:v mjpeg \
    stream%d.jpg

También estaba leyendo y descubrí que podemos usar %del nombre del archivo de salida de raspistill. Me pregunto si eso aumentará los fps. Además, la codificación JPG es acelerada por hardware en raspistill, por lo que me cuesta mucho entender por qué es tan lenta ...

Obtuve un asombroso 2 FPS usando %del nombre del archivo. Por alguna razón, escribir el archivo JPEG es terriblemente lento desde raspistill. Suspiro.

ppumkin
fuente
gracias por compartir el conocimiento
user566245
10

A partir de 2017 (o tal vez antes) raspividya no es el método preferido, ya que los desarrolladores de Pi recomiendan que las personas usen V4L2.

Entonces, este método le permite transmitir H264 a través de RTP usando V4L2 en lugar de raspivid. Noté que este método produce menos abandonos y permite una tasa de bits más alta:

#!/bin/sh

# Use V4L2 (preferred) instead of raspivid
# exposure_dynamic_framerate=1 (raspivid --fps 0) - reduce framerate/increase exposure in low light
# scene_mode=8 (raspivid --exposure night) - allow framerate reduction to increase exposure
v4l2-ctl -v width=1296,height=972,pixelformat=H264 \
        --set-ctrl=exposure_dynamic_framerate=1 \
        --set-ctrl=video_bitrate=5000000 \
        --set-ctrl=scene_mode=8

exec ffmpeg -f h264 -probesize 32 -r 30 -i /dev/video0 -vcodec copy -an -f rtp_mpegts udp://224.0.1.2:5004

Esta secuencia de comandos multicast el video, y se puede ver en otra máquina en la LAN con un comando como este:

ffplay -sync ext -an -fast -framedrop -probesize 32 -window_title "Raspberry Pi" -an udp://224.0.1.2:5004

-sync exthace que el video se reproduzca lo más rápido posible, por lo que se ejecutará en tiempo real, en lugar de ejecutarse a una velocidad de fotogramas fija y retrasarse si el Pi captura fotogramas más rápido que esto. Todavía hay algún retraso con este método, pero no peor que los otros raspividmétodos.

(Sugerencia: si está enchufado a un enrutador o conmutador que admite IGMP, asegúrese de 224.0.0.0/4que no tenga firewall en su máquina, de lo contrario, cuando el enrutador le pregunte a su PC si desea algún tráfico de multidifusión, la PC nunca responderá y nunca verá ningún vídeo.)

Grabando en disco

Como mencioné la grabación en los comentarios a continuación, ampliaré eso aquí. Puede usar un comando como este para grabar la transmisión de red al disco:

ffmpeg -y -i udp://224.0.1.2:5004 -c copy \
  -f segment -segment_atclocktime 1 -segment_time 900 \
  -reset_timestamps 1
  -strftime 1 /path/to/storage/pi-%wT%H%M.mkv

Busque man strftimelos significados de los %símbolos en el nombre del archivo. Los de este ejemplo usan el número de día (0 = domingo, 1 = lunes, etc.) seguido de ay Tluego la hora. Comienza un nuevo archivo cada 15 minutos.

Para ser claros, este comando de grabación está destinado a ejecutarse en una PC remota (no en el Pi), aunque probablemente también funcione en el Pi (no probado).

Como obtiene un archivo nuevo cada 15 minutos con el día y la hora en el nombre del archivo, significa que después de una semana comenzará a generar nombres de archivos que ya se han utilizado, lo que hará que se sobrescriban los archivos más antiguos. En otras palabras, terminará con un ciclo continuo del material de archivo de la semana anterior. Esto es ideal para una cámara de seguridad donde rara vez necesitará regresar más de una semana.

Como nota al margen, esto produce aproximadamente 500 GB de archivos, por lo que es posible que desee ajustar la tasa de bits, la resolución o sobrescribir los archivos antes (por ejemplo, cada 24 horas) si no desea que ocupen tanto espacio.

Malvinoso
fuente
Genial - Gracias por compartir esto. ¿Puede explicar por qué es necesario el uso de multidifusión aquí? De lo que he aprendido es que la multidifusión rara vez se usa, así que me preguntaba qué aporta aquí. Aún así, el guión se ve muy bien y estoy seguro de que ayudará a muchas personas. Gracias +1
Piotr Kula
1
La multidifusión es opcional (puede sustituir una dirección IP normal si lo desea), pero deberá cambiar el comando para usar ffservero algún otro sistema de servidor si desea que más de una máquina muestre la fuente. Luego, después de unos 2-3 clientes (dependiendo de la tasa de bits de video), el adaptador USB Ethernet de Pi se quedará sin ancho de banda. Con la multidifusión no hay necesidad de ejecutar un servidor (las máquinas cliente solo eligen escuchar el tráfico o ignorarlo) para que pueda tener miles de máquinas mostrando el video sin impacto en el Pi, que solo envía una transmisión de video .
Malvineous
Gracias por explicarlo, pero ¿la multidifusión solo funciona en redes internas? Si un ISP recibe un paquete de multidifusión, generalmente lo eliminan, por lo que no es como si pudieras transmitirlo a todos en Internet. Supongo que si tienes una gran red interna, ¿mulit emitir una transmisión masiva también puede afectar tu red? Pero sí ... solo para que vea una transmisión, simplemente UDP a una IP seleccionada ... pero de todos modos me gusta la opción de multidifusión: D Intentaré hacerlo este fin de semana solo porque nunca lo hice antes. :) Gracias
Piotr Kula
1
Sí, la multidifusión es principalmente para redes internas. Se supone que funciona mejor con IPv6, pero creo que aún necesitará la cooperación del ISP. Lo uso porque significa que no tengo que ejecutar un servidor en el Pi, y puedo ver las transmisiones de dos máquinas diferentes y grabarlo en el disco sin cambiar la configuración de Pi o sobrecargar el ancho de banda de la red de Pi. Si su red interna es grande, entonces probablemente usará conmutadores con capacidad IGMP que están diseñados para enviar solo tráfico de multidifusión donde sea necesario para que el impacto no sea diferente de lo normal.
Malvineous
1
Gracias por explicar ... Ahora puedo ver muchos beneficios de usar la multidifusión con pequeñas advertencias que realmente ni siquiera afectarán a los usuarios domésticos. Definitivamente voy a darle una oportunidad. Son las cosas simples y obvias que a veces deben señalarse para que tengan sentido. Y mirando tu actualización ... ¡el bit de grabación es realmente genial!
Piotr Kula
4

Logré transmitir desde mi Raspberry Pi a un servidor web con el módulo compilado nginx-rtmp .

Para ahorrar molestias ffmpeg, recomiendo una distribución continua como Arch Linux Arm .

raspivid -vf -t 0 -fps 25 -b 2000000 -o - |
ffmpeg -i - -vcodec copy -an -r 25 -f flv rtmp://x220/myapp/mystream

Algunas notas:

Entonces, sobre esta base, creo que la transmisión en vivo desde una Raspberry Pi podría estar bien para una transmisión temporal, pero no para una cámara web siempre encendida, ya que requiere demasiado ancho de banda. No obtendrá audio y si lo hace, será una misión sincronizar.

Puede grabar audio de manera más eficiente por separado al mismo tiempo que graba video. Luego, tal vez envíe la transmisión de audio más tarde y la convierta a WebM y la coloque en su httpd como un archivo estático con una etiqueta de video HTML. El flujo de trabajo es bastante incómodo, aunque es lo mejor que se me ocurre para una transmisión eficiente que funcione sin problemas en todos los navegadores.

hendry
fuente
1
Sin embargo, puede controlar el ancho de banda y la resolución. Si su transmisión local de LAN para uso de CCTV, entonces eso ni siquiera es un problema. La transmisión por internet podría necesitar ser a pedido y / o una resolución mucho menor. Pero es otra forma de hacerlo. Gracias +1
Piotr Kula
¿Y cómo se supone que funciona? no es para mí ... FFMPEG dice "RTMP_Connect0, no se pudo conectar el zócalo. 111 (Conexión rechazada)"
Flash Thunder
2

UV4L ahora admite transmisión de audio y video en vivo con WebRTC y HTML5.

Strunz
fuente
Acabo de leer el enlace de arriba ...
Strunz
Funciona muy bien!
Piotr Kula
¿Cómo? El enlace a su página de ejemplo está roto ...
Cerin
He leído estos tutoriales y puedo confirmar que no funcionan
Quintin Balsdon
Puedo confirmar que funciona como lo he probado .. instructables.com/id/Raspberry-Pi-Video-Streaming
Tia
2

La respuesta de Piotr Kula parece estar en el camino correcto, pero no está actualizada para Raspberry.

Hay instrucciones actualizadas para uv4l en Raspberry stretch en

https://www.linux-projects.org/uv4l/installation/

# switch to superuser mode
sudo -s
# add the repository key for uv4l
curl http://www.linux-projects.org/listing/uv4l_repo/lpkey.asc | sudo apt-key add 
# add the url for the u4vl repository to apt
echo "deb http://www.linux-projects.org/listing/uv4l_repo/raspbian/stretch stretch main" >> /etc/apt/sources.list
apt-get update
apt-get install uv4l uv4l-raspicam
apt-get install uv4l-raspicam-extras
# do not forget to install the server - see what happens if you do
# below
apt-get install uv4l-server
reboot

Puede modificar las opciones de uv4l a través de /etc/uv4l/uv4l-raspicam.conf y luego reiniciar el servicio con

sudo service uv4l_raspicam restart

En mi caso, las cosas no funcionaron de la caja (si olvidó instalar el servidor uv4l ...). Los siguientes comentarios pueden ayudarlo a depurar problemas similares.

Verifiqué que el servidor se está ejecutando con:

pgrep -fla uv4l
995 /usr/bin/uv4l -f -k --sched-fifo --mem-lock --config-file=/etc/uv4l/uv4l-raspicam.conf --driver raspicam --driver-config-file=/etc/uv4l/uv4l-raspicam.conf --server-option=--editable-config-file=/etc/uv4l/uv4l-raspicam.conf

y si escuchó con

sudo netstat -tulpn

pero no había entrada para uv4l en la lista. Esperaba uno para el puerto 8080

Así que probé el comando de ¿Cómo configurar UV4L?

uv4l --sched-rr --mem-lock --driver raspicam \
> --width 960 --height 540 --framerate 30 \
> --encoding mjpeg --vflip --hflip
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct  6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 960x544, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Registering device node /dev/uv4l

Pero aún así el servidor no se inició automáticamente ...

man uv4l

luego me mostró la opción 

--enable-server [=arg(=required)] (=auto)
          enable the streaming server. Possible values are: 'auto' (tenta‐
          tively start the server), 'required' (exit if failing  to  start
          the  server,  only  works if --foreground is enabled), 'off' (no
          server at all).

entonces intenté:

pkill uv4l
sudo uv4l --sched-rr --mem-lock --driver raspicam --encoding mjpeg --enable-server=required
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct  6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 1920x1080, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Registering device node /dev/uv4l

pero aún no hay ningún servidor ejecutándose en el puerto 8080 o en otro lugar. Así que parece que olvidé la opción "--foreground" que la página del manual dice que es necesaria:

sudo uv4l --sched-rr --mem-lock --driver raspicam --encoding mjpeg --enable-server=required --foreground
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct  6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 1920x1080, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Trying to load the the Streaming Server plug-in...
<warning> [core] libserver.so: cannot open shared object file: No such file or directory
<alert> [core] No Streaming Server detected

Ahora que es una pista clara! Parece que todavía no hay servidor, así que instálelo:

sudo apt-get install uv4l-server

e intenta de nuevo:

sudo uv4l --sched-rr --mem-lock --driver raspicam --encoding mjpeg --enable-server=required --foreground
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct  6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 1920x1080, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Trying to load the the Streaming Server plug-in...
<notice> [server] HTTP/HTTPS Streaming & WebRTC Signalling Server v1.1.125 built on Mar  9 2019
<warning> [server] SSL is not enabled for the Streaming Server. Using unsecure HTTP.
<notice> [core] Streaming Server loaded!
<notice> [core] Registering device node /dev/uv4l
<notice> [server] Web Streaming Server listening on port 8080

El servidor ahora está disponible en http: // pi: 8080 (reemplace pi con la IP o el nombre de host de su servidor)

Después de un reinicio funcionó sin ingresar otro comando.

Wolfgang Fahl
fuente
1

UV4L ahora admite la transmisión de audio y video en vivo a Jitsi Meet Rooms a través de la Web. No se requiere una configuración especial. Es tan fácil como escribir su nombre, sala y hacer clic en Iniciar .

prinxis
fuente
¿Qué navegador estás usando? Jitsi solo admite Chrome, Chromium, Opera y Firefox por la noche, de los cuales solo Chromium está disponible en Pi. Pero Chromium me da un webkitRTCPeerConnection is not definederror. Normalmente uso IceWeasel para WebRTC, pero eso no es compatible con Jitsi.
modulitos
1
en el PI no hay ningún navegador que soporte WebRTC, excepto un soporte casi roto en IceWeasel. La forma en que lo uso es: Pi-> Servidor Jitsi en la Nube -> mi PC en otro lugar
prinxis
1
UV4L admite la transmisión en vivo H264 codificada por hardware sin latencia.
prinxis