Uzyskaj opóźnienie podobne do webrtc dzięki ffmpeg?

Używam tego między Chrome a moim telefonem:

http://www.webrtc.org/demo

Opóźnienie jest naprawdę dobre - mniej niż 1 sekunda.

Próbowałem powielić to na moim komputerze bez powodzenia.

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

A potem za pomocą ffplay po drugiej stronie.

Nadal ma kilka sekund opóźnienia.

W końcu chciałbym przesyłać strumieniowo z mojego komputera na telefon z Androidem, ale opóźnienie musi być dobre.

Edytuj - działa znacznie lepiej. Gdybym mógł się trochę tego ogolić, byłbym szczęśliwy:

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
źródło

Link jest martwy. Zasadniczo chcesz przekonwertować wideo i przesyłać strumieniowo do telefonu? W sieci Wi-Fi czy zewnętrznej?

— jiggunjer

Chcę przesyłać strumieniowo z kamery podłączonej do urządzenia i wyświetlać ją na tablecie z Androidem (Nexus 10) podłączonym przez USB.

— David N. Welton

Nie wiem dużo o tych kodekach, ale czy sprawdziłeś, czy są one przyspieszane sprzętowo tam, gdzie to możliwe? To jest moje przypuszczenie, dlaczego widzisz opóźnienie dłuższe niż 1 sekunda.

— snoopen

vpx będzie trudne do zamknięcia w czasie rzeczywistym, wiem, że x264 ma melodię „małe opóźnienie” lub coś w tym rodzaju FWIW

— rogerdpack

Problem wynika głównie z faktu, że używasz transkodowania programowego zamiast transkodowania sprzętowego .

Zasadniczo, jeśli konwersja wykorzystuje przyspieszenie sprzętowe, opóźnienie będzie mniejsze niż sekunda (zwykle milisekundy). Jeśli odbywa się to w oprogramowaniu, opóźnienie będzie rzędu ponad jednej sekundy.

FFmpeg obsługuje przyspieszenie sprzętowe, ale zwykle jest trudne, aby działało dla Ciebie.

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

Z drugiej strony Google Chrome obsługuje kodowanie / dekodowanie sprzętowe VP8 i H264 (tam, gdzie jest dostępne) zarówno na komputerze, jak i telefonie z Androidem:

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

— Ho1
źródło

Nie chodzi tylko o przyspieszenie sprzętowe ... konfiguracja kodeka odgrywa znacznie większą rolę w opóźnieniu. Kodek należy dostroić, aby opóźnienie było niskie, kosztem jakości i przepustowości. Można to zrobić niezależnie od tego, czy korzystasz z kodeków przyspieszanych sprzętowo, czy nie.

— Brad

Ten link wyraźnie mówi, że Chrome NIE obsługuje kodowania sprzętowego na komputerze, TYLKO na Androidzie.

— David

Przepraszam, ale Brad ma rację, odpowiedź jest całkowicie błędna: dopóki ustawisz te same ustawienia kodeków, nie ma żadnej różnicy, jeśli wykonujesz kodowanie sprzętowe lub programowe (o ile masz wystarczającą moc procesora do kodowania w czasie rzeczywistym z twoim ustawienia kodeków). Prawidłowe jest to, że nie chodzi tylko o ustawienia kodeków wideo, ale przede wszystkim o rodzaj transportu i zachowanie bufora dekodera. WebRTC działa, ponieważ jest dostrojony pod kątem małych opóźnień. Typowy dekoder Webm nie jest przeznaczony do opóźnień

— Harry