Отримати затримку, схожу на webrtc, за допомогою ffmpeg?

Я використовую це між Chrome і телефоном:

http://www.webrtc.org/demo

А затримка справді хороша - менше 1 секунди.

Я намагався повторити це на своєму комп’ютері без успіху.

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

А потім за допомогою ffplay з іншого боку.

На це все ще є відставання на пару секунд.

Врешті-решт, я хотів би передати з комп’ютера на телефон Android, але затримка повинна бути хорошою.

Редагувати - це працює значно краще. Якби я міг трохи відголитись від цього, я був би радий:

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

— Девід Н. Уелтон
джерело

Посилання мертва. В основному ви хочете перетворити відео та передати його на свій телефон? На wifi чи зовнішній?

— jiggunjer

Я хочу зробити це передавання з камери, приєднаної до пристрою, і відображення його на планшеті Android (Nexus 10), який підключений через USB.

— Девід Н. Уелтон

Я не знаю багато про ці кодеки, але ви перевірили, чи є апаратне прискорення там, де це можливо? Це міг би припустити, чому ви бачите затримку більше 1 секунди.

— занести

vpx буде складно закрити до реального часу, я знаю, що x264 має мелодію "низької затримки" або щось подібне FWIW

— rogerdpack

Проблема здебільшого полягає в тому, що ви використовуєте програмне перекодування замість апаратного перекодування .

Як правило, якщо конверсія використовує апаратне прискорення, затримка буде меншою за секунду (як правило, мілісекунд). Якщо це робиться в програмному забезпеченні, то затримка буде більше, ніж за секунду.

FFmpeg підтримує апаратне прискорення, але, як правило, складно зробити це для вас.

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

З іншого боку, Google Chrome підтримує кодування / декодування апаратних засобів кодування / декодування VP8 та H264 (де вони доступні), як на вашому комп’ютері, так і на телефоні Android:

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

— Ho1
джерело

Справа не тільки в апаратному прискоренні, але ... конфігурація кодека відіграє набагато більшу роль у затримці. Кодек повинен бути налаштований на підтримку низької затримки за рахунок якості та пропускної здатності. Це можна зробити, використовуєте ви апаратні прискорені кодеки чи ні.

— Бред

Це посилання спеціально говорить, що Chrome НЕ підтримує апаратне кодування на робочому столі, ТІЛЬКИ на android.

— дав

Вибачте, але Бред має рацію, відповідь абсолютно невірна: якщо ви встановлюєте ті самі параметри кодека, немає різниці, якщо ви робите апаратне чи програмне кодування (доки у вас є достатня потужність процесора для кодування в режимі реального часу з вашим налаштування кодека). Правильно, що мова йде не лише про налаштування відеокодека, але переважно про тип транспорту та буферну поведінку декодера. WebRTC працює, оскільки він налаштований на низьку затримку. Типовий декодер Webm не призначений для низької затримки

— Гаррі