Transmisión de audio en vivo usando FFMPEG


13

Intento transmitir audio en vivo usando ffmpegun micrófono USB externo. Seguí este casi tutorial

Tuve que adaptar algunos pasos pero finalmente logré recibir la transmisión de mi computadora portátil usando este comando:

ffmpeg -f oss -i /dev/dsp1 -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://192.168.28.116:1234

La CPU está cerca del 100%, tengo un sonido malo durante dos segundos y después de nada ... Veo en Wireshark que la placa está enviando cuadros continuamente.

¿Alguien tiene ideas para reducir el uso de la CPU?


Es posible que desee considerar el overclocking y una división de memoria diferente. Si tiene la opción de códec, puede lograr alguna mejora al cambiar. También es posible que desee investigar la compresión de la transmisión, aunque esto puede ser un poco de ganancia, cualquier cosa que gane en el tiempo de transferencia puede perderse en la compresión.
Steve Robillard

¿Intentaste escribir en un archivo local primero? Intentaría ir paso a paso: 1) grabación en tiempo real en un archivo wave, 2) grabación en tiempo real en un archivo mp3 3) transmisión de cosas por la red
pixelistik

no en este momento. parece ser complicado hacer todos estos pasos manualmente en lugar de ffmpeg completamente automático ;-)
hotips

Que estas grabando
Alex Chamberlain el

1
Estoy tratando de hacer un babyphone ethernet
hotips

Respuestas:


7

Para responder a su pregunta específica, puede reducir la CPU colocando un registro en ffmpeg:

arecord -f cd -D plughw:1,0 | ffmpeg -i - -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://234.5.5.5:1234

Tendrá que reemplazar plughw: 1,0 con su tarjeta de sonido específica. Ver arecord -l para más información. En mi Rasp Pi pasó de ~ 95% de CPU a ~ 35%.


6

Entrada ALSA

Una alternativa es ir a través de ALSA. Un comando similar al anterior sería

ffmpeg -ac 1 -f alsa -i hw:0,0 -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://localhost:1234

No estoy seguro de cómo esto afectará el uso de la CPU.


Intenté: ffmpeg -ac 1 -f alsa -i hw: 1,0 -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp: //192.168.1.116: 1234 Pero ffmpeg se bloquea después de unos segundos: [alsa @ 0x7a1510] ALSA buffer xrun. ¿Alguna otra idea?
hotips

Probé ffmpeg -f oss -i / dev / dsp1 -ab 32k -ac 1 -re -f rtp rtp: //192.168.28.116: 1234 pero el sonido es muy malo ... en el retraso es de alrededor de 6 segundos. ¿Alguna idea para tener una mejor solución?
hotips

1
@ si2w Creo que 32k para mp3 es una broma. O sube eso, o prueba con un códec diferente. Tal vez una de la serie G2xx diseñada para teléfonos
Alex Chamberlain

3

Esto funciona y reduce el uso de la CPU:

ffmpeg -f alsa -i default:CARD=U0x46d0x819 -acodec mp2 -ac 1 -re -f rtp rtp://234.5.5.5:1234 2> /tmp/mylog.log &

Asegúrese de reemplazar el valor predeterminado: CARD = U0x46d0x819 con su ID de micrófono, (obtenido de arecord -l) o puede especificarlo -i hw:0,0(o el dispositivo que sea).

Tuve un problema similar: la codificación de mp3 ocupaba más del 90% de la potencia de la CPU y simplemente no podía seguir el ritmo del audio, así que lo cambié a codificación mp2. Esto usó alrededor del 15-18% de la CPU (medida vi top) y se transmite sin problemas a VLC en mi LAN. Sería un monitor de bebé perfecto, o lo que sea. Solo hay un segundo retraso, que es el almacenamiento en búfer en el extremo VLC.

Nota: La dirección IP es una dirección de multidifusión ([224-239] .xyz). No tiene que apuntar a un dispositivo de red en particular en su LAN, y su enrutador de banda ancha mantendrá el tráfico local (por defecto).


2

Puede reducir significativamente la carga de la CPU reduciendo la frecuencia de muestreo de audio del dispositivo de entrada ( -ar 8000 antes -f alsa ) y configurando la frecuencia de bits de audio del códec a 128k ( -b:a 128k). Irónicamente, la reducción de la cantidad de canales ( -ac 1) parecía aumentar la carga de la CPU, por lo que he encontrado que este comando se ejecuta en una CPU bastante baja:

ffmpeg -ar 8000 -f alsa -i hw:0 -acodec mp2 -b:a 128k -f rtp rtp://other:4444

Aunque uno debe recordar que también depende de las capacidades del hardware de captura que uno está tratando de usar, y las versiones de ffmpeg / avconv.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.