rtpvp8depay + rtpvp8pay, похоже, вводит артефакты на Janus Gateway

Поток VP8 поступает из плагина Janus Videoroom с локальным перенаправлением на 10002/10004. Оттуда он подбирается с помощью следующего конвейера gstreamer:

gst-launch-1.0 -v udpsrc \
caps="application/x-rtp,media=(string)video,encoding-name=(string)VP8,payload=100" \
address=127.0.0.1 port=10004 ! \
rtpvp8depay ! rtpvp8pay  ! \
udpsink host=127.0.0.1 port=5004

и отправлено в плагин Streaming. Как видите, здесь никакого транскодирования, только депайлоад и пейлоад. в результате видео разбивается на артефакты на некоторых ключевых кадрах, примерно один раз из 10 ключевых кадров, и фиксируется только на следующем ключевом кадре.

если я удалю депай и оплату, просто переадресовав на уровне rtp, чтобы получить это

gst-launch-1.0 -v udpsrc \
caps="application/x-rtp,media=(string)video,encoding-name=(string)VP8,payload=100" \
address=127.0.0.1 port=10004 ! \
udpsink host=127.0.0.1 port=5004

этого никогда не бывает.

Я понимаю, что это не проблема Януса, а проблема gstreamer. а может у кого есть идеи в чем может быть проблема? это было очень надежно проверено, проблема легко воспроизводится в первом случае и никогда не возникает во втором.

Конечно, целью того, что я делаю, является перекодирование, и в настройке и конвейере было гораздо больше, прежде чем я довел его до этого уровня. Воспроизведено на Janus, установленном на свежей машине Ubuntu 18.04 со всеми готовыми настройками.

Обновить:

export GST_DEBUG="rtp*:4";

обнаружил это сообщение об ошибке, которое выпадает каждый раз, когда появляются артефакты:

rtpbasedepayload gstrtpbasedepayload.c:473:gst_rtp_base_depayload_handle_buffer:
<rtpvp8depay0> 12 <= 100, dropping old packet

при этом число, равное «12», обычно колеблется от 5 до 12.


person Alexander Novikov    schedule 21.09.2019    source источник
comment
Помня об этом заголовке stackoverflow.com/questions/56788387/, я попытался установить mtu = 1200 в параметрах rtpvp8pay (по умолчанию 1400, что немного страшно), но это не помогло.   -  person Alexander Novikov    schedule 21.09.2019


Ответы (1)


Это было исправление:

Задержка rtpjitterbuffer = 50!

перед rtpvp8depay.

Логически порядок пакетов к этому моменту такой же, как и тот, который прошел через Интернет между отправляющим браузером и Janus. Если мы не откладываем + платим, он идет тем же путем к принимающему браузеру, который подключен к плагину Streaming, и у него есть собственный буфер джиттера, поэтому он может исправлять порядок, но если мы делаем здесь депай + оплата, буфера нет таким образом, эти пакеты отбрасываются, в результате чего появляются битые кадры.

И да, мне вернули перекодирование и все остальное в моем конвейере, и все другие навороты, которые были вокруг, и он по-прежнему работает нормально.

person Alexander Novikov    schedule 21.09.2019
comment
Также значение задержки не сильно влияет на вещи, находящиеся между 50 и 200. Поэтому я оставил его только на rtpjitterbuffer без каких-либо параметров в конце, если задержка от конца до конца выше, чем в случае с 50, то только на очень незначительное значение. 0..40 мс. - person Alexander Novikov; 21.09.2019
comment
задержка кажется верхним пределом. при очень плохом подключении к Интернету артефакты воспроизводились, но исчезли, когда я установил задержку на 1000. Фактическая сквозная задержка увеличилась до 270 мс с начальных 200, хотя в лучшем Интернете она по-прежнему составляет 200. - person Alexander Novikov; 21.09.2019