Flux audio en direct à l'aide de FFMPEG

13

J'essaie de diffuser de l'audio en direct à l'aide ffmpegd'un microphone USB externe. J'ai suivi ce tutoriel presque

J'ai dû adapter certaines étapes mais finalement, j'ai réussi à recevoir le flux de mon ordinateur portable en utilisant cette commande: 

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

Le CPU est proche de 100%, j'ai un mauvais son pendant deux secondes et après rien ... Je vois dans Wireshark que la carte envoie des trames en continu.

Quelqu'un a-t-il des idées pour réduire l'utilisation du processeur?

usb audio hotips
la source
Vous voudrez peut-être examiner l'overclocking et une répartition de mémoire différente. Si vous avez le choix du codec, vous pourrez peut-être obtenir des améliorations en changeant. Vous pouvez également étudier la compression du flux - bien que cela puisse être un gain nul - tout ce que vous gagnez en temps de transfert peut être perdu lors de la compression.
Steve Robillard
Avez-vous d'abord essayé d'écrire dans un fichier local? J'essaierais d'aller étape par étape: 1) enregistrement en temps réel sur un fichier wave, 2) enregistrement en temps réel sur un fichier mp3 3) streaming de trucs sur le réseau
pixelistik
pas pour le moment. semble être compliqué de faire toutes ces étapes manuellement au lieu de ffmpeg entièrement automatique ;-)
hotips
Qu'enregistrez-vous?
Alex Chamberlain
1
J'essaye

Réponses:

7

Pour répondre à votre question spécifique, vous pouvez réduire le processeur en canalisant un enregistrement dans 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

Vous devrez remplacer plughw: 1,0 par votre carte son spécifique. Voir arecord -l pour plus d'informations. Sur mon Rasp Pi, il est passé de ~ 95% CPU à ~ 35%.

kumar303
la source
6

Entrée ALSA

Une alternative est de passer par ALSA. Une commande similaire à celle ci-dessus serait

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

Je ne sais pas comment cela affectera l'utilisation du processeur.

Alex Chamberlain
la source
J'ai essayé: ffmpeg -ac 1 -f alsa -i hw: 1,0 -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp: //192.168.1.116: 1234 Mais ffmpeg se bloque après quelques secondes: [alsa @ 0x7a1510] Xrun du tampon ALSA. D'autres idées?
hotips
J'ai testé ffmpeg -f oss -i / dev / dsp1 -ab 32k -ac 1 -re -f rtp rtp: //192.168.28.116: 1234 mais le son est très mauvais ... le décalage est d'environ 6 secondes. Une idée pour avoir une meilleure solution?
hotips
1
@ si2w Je pense que 32k pour mp3 est un peu une blague. Soit ça, soit essayez un autre codec. Peut-être l'une des séries G2xx conçues pour les téléphones
Alex Chamberlain
3

Cela fonctionne et réduit l'utilisation du processeur:

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

Assurez-vous de remplacer la valeur par défaut: CARD = U0x46d0x819 avec votre ID de microphone (obtenu à partir de arecord -l) ou vous pouvez spécifier -i hw:0,0(ou quel que soit le périphérique).

J'ai eu un problème similaire - l'encodage mp3 a pris plus de 90% de la puissance du processeur et ne pouvait tout simplement pas suivre le son - alors je l'ai changé en encodage mp2. Cela a utilisé environ 15 à 18% du CPU (vi mesuré top) et est diffusé en douceur vers VLC sur mon LAN. Cela ferait un babyphone parfait, ou autre chose. Il y a juste une seconde ou deux délais, qui est la mise en mémoire tampon à la fin de VLC.

Remarque: l' adresse IP est une adresse de multidiffusion ([224-239] .xyz). Vous n'avez pas à le viser sur un périphérique réseau particulier de votre réseau local et votre routeur à large bande gardera le trafic local (par défaut).

Tim
la source
2

Vous pouvez réduire considérablement la charge du processeur en réduisant la fréquence d'échantillonnage audio du périphérique d'entrée ( -ar 8000 avant -f alsa ) et en définissant le débit binaire audio du codec sur 128k ( -b:a 128k). Ironiquement, la réduction du nombre de canaux ( -ac 1) semblait augmenter la charge du processeur, j'ai donc trouvé que cette commande s'exécute sur un processeur assez faible:

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

Bien que l'on doive se rappeler que cela dépend aussi des capacités du matériel de capture que l'on essaie d'utiliser et des versions de ffmpeg / avconv.

Pierz
la source