Obtenez une latence de type webrtc avec ffmpeg?

J'utilise ceci entre Chrome et mon téléphone:

http://www.webrtc.org/demo

Et la latence est vraiment bonne - moins d'une seconde.

J'ai essayé de reproduire cela sur mon ordinateur sans succès.

ffmpeg -f video4linux2 -i /dev/video0  -s 320x200 -r 50 -deadline realtime -vcodec libvpx -f webm -fflags nobuffer udp://10.0.0.55:9002

Et puis en utilisant ffplay de l'autre côté.

Il y a encore quelques secondes de retard.

Finalement, j'aimerais diffuser de mon ordinateur vers le téléphone Android, mais la latence doit être bonne.

Modifier - cela fonctionne beaucoup mieux. Si je pouvais me raser un peu, je serais heureux:

ffmpeg -vcodec rawvideo -f video4linux2 -i /dev/video0  -s 320x200 -r 25 -vcodec libvpx -f rtp -deadline realtime rtp://10.0.0.55:9002

ffmpeg video-streaming

— David N. Welton
source

Le lien est mort. Fondamentalement, vous souhaitez convertir la vidéo et la diffuser sur votre téléphone? Sur wifi ou externe?

— jiggunjer

Ce que je veux faire, c'est diffuser à partir d'une caméra connectée à un appareil et l'afficher sur une tablette Android (Nexus 10) connectée via USB.

— David N. Welton

Je ne connais pas grand-chose à ces codecs, mais avez-vous vérifié qu'ils sont accélérés au niveau matériel si possible? Ce serait ma conjecture quant à la raison pour laquelle vous voyez plus de 1 seconde de latence.

— snoopen

vpx va être difficile à fermer en temps réel, je sais que x264 a une mélodie "faible latence" ou quelque chose comme ça FWIW

— rogerdpack

Le problème vient principalement du fait que vous utilisez le transcodage logiciel , au lieu du transcodage matériel .

En règle générale, si la conversion utilise l'accélération matérielle, la latence sera d'un ordre inférieur à une seconde (généralement des millisecondes). Si cela se fait dans un logiciel, la latence sera alors de plus d'une seconde.

FFmpeg prend en charge l'accélération matérielle, mais il est généralement difficile de la faire fonctionner pour vous.

https://trac.ffmpeg.org/wiki/HWAccelIntro

D'autre part, Google Chrome prend en charge l'encodage / décodage matériel VP8 et H264 (lorsqu'il est disponible), à la fois sur votre ordinateur et votre téléphone Android:

http://code.google.com/p/chromium/issues/detail?id=428223

— Ho1
source

Il ne s'agit pas seulement d'accélération matérielle ... La configuration du codec joue un rôle beaucoup plus important dans la latence. Le codec doit être réglé pour maintenir une latence faible, au détriment de la qualité et de la bande passante. Cela peut être fait que vous utilisiez ou non des codecs à accélération matérielle.

— Brad

Ce lien indique spécifiquement que Chrome ne prend pas en charge l'encodage matériel sur le bureau, UNIQUEMENT sur Android.

— davr

Désolé mais Brad a raison, la réponse est totalement fausse: tant que vous définissez les mêmes paramètres de codec, il n'y a aucune différence si vous effectuez un encodage matériel ou logiciel (tant que vous avez suffisamment de puissance CPU pour effectuer un encodage en temps réel avec votre paramètres du codec). Il est vrai qu'il ne s'agit pas seulement des paramètres du codec vidéo, mais surtout du type de transport et du comportement de mise en mémoire tampon du décodeur. WebRTC fonctionne car il est réglé pour une faible latence. Le décodeur Webm typique n'est pas destiné à faire de la faible latence

— Harry