LINUX.ORG.RU

Откуда берется задержка при стриминге видео?

 ,


0

2

Ситуация такая: - Есть комп с линуксом, на нем запущен gstreamer (v4l2src device=/dev/video0 ! video/x-raw,width=320,height=240,framerate=30/1 ! jpegenc quality=85 ! rtpjpegpay ! udpsink host=x.x.x.x port=xxxx). - Есть комп-приемник с виндой, на нем запущен vlc c опцией :network-caching=0. - Оба компа подключены к одной wifi точке доступа и находятся на расстоянии нескольких метров от нее.

Проблема: через некоторое время появляется задержка в видео и через некоторое время достигает совершенно неприемлемых ~20 секунд. На первый взгляд, задержка появляется совершенно рандомно.

Рабочее предположение - пропускной способности канала в какой-то момент перестает хватать и видео начинает буферизоваться где-то.

Вопрос: как от этой задержки избавиться?

Что я пробовал: ставил границы в /proc/sys/net/ipv4/udp_mem поменьше (особой разницы не увидел), добавлял в пайплайн sync=false (безрезультатно)

пропускной способности канала в какой-то момент перестает хватать и видео начинает буферизоваться где-то.

Не тот случай. UDP просто дрищет пакетами и не обращает внимания, если они тут же дропаются.

Допускаю, что не хватает мощи на кодировании JPEG, и вот там оно накапливается.

Andrey_Utkin ★★ ()

Сначала надо определить где задержка на сурсе или на синке. Под виндой попробовать что-то отличное от vlc и убедиться, что это не он буферизирует.
Если это gstreamer, то стоит посмтреть опции каждого плагина в пайпе gst-inspect udpsink/rtpjpegpay/whatever возможно у кого-то в опциях есть (максимальный) размер буфера или опция дропа фреймов.
Вряд ли это пропускная способность канала, но можно ж попробовать битрейт пониже и посмотреть что получится (может станет лучше, может хуже, если хуже, может кодер не справляется).

elijah_sd ()
Последнее исправление: elijah_sd (всего исправлений: 1)

Плюсую вышеотписавшегося оратора. Попробуй смотреть стрим утилитой ffplay с опцией nobuffer, чтобы убедиться, что задержка не вызвана буферизацией на стороне плеера.

kravich ★★★★ ()

шел 2016 год

jpegenc

Но зачем?

mix_mix ★★★★★ ()
Ответ на: комментарий от Andrey_Utkin

Допускаю, что не хватает мощи на кодировании JPEG, и вот там оно накапливается.

htop показывает загрузку проца в районе 25-30%. Вроде должно хватать.

шел 2016 год

jpegenc

Но зачем?

Если коротко - потому что на других кодеках один пропущенный пакет вызывает мазню, цифровой шум и тому подобное; пока ключевой кадр не придет. Плюс конкретно этот комп довольно дохлый и кроме jpeg'a он мало что потянет.

Я попробовал попринимать видео gstreamer'ом на линуксе - задержка меньше секунды и не растет. ffplay даже с nobuffer создает задержку примерно в секунду, но она не растет.

Под виндой ffplay и vlc принимают с задержкой в несколько секунд; ffplay при этом постоянно жалуется, что

[sdp @ 00000000005010c0] RTP: missed 1 packets [sdp @ 00000000005010c0] Missing packets; dropping frame. Last message repeated 3 times [sdp @ 00000000005010c0] max delay reached. need to consume packet [sdp @ 00000000005010c0] RTP: missed 11 packets [sdp @ 00000000005010c0] RTP timestamps don't match. [sdp @ 00000000005010c0] max delay reached. need to consume packet

Судя по всему, дело в винде.. только вот где именно?

poganoe_lamerishe ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.