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

11

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
David N. Welton
źródło
1
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
1
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

Odpowiedzi:

1

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
2
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