LINUX.ORG.RU

артефакты при передаче видео через gstreamer по сети

 , ,


2

1

Здравствуйте, уже которую неделю усиленно бьюсь над передачей видеопотока с веб-камеры Logitech C920 подключенной к RaPi через локальную сеть используя сжатие h264. Почти добился своего, но на последнем пути у меня вылезли артефакты на видео, я был бы очень признателен если бы кто нибудь помог с этим. Параметры запуска Сервера на Raspberry Pi: gst-launch-0.10 -v -e uvch264_src device=/dev/video0 name=src auto-start=true src.vidsrc ! queue ! 'video/x-h264,width=960,height=720,framerate=30/1,bit-rate=1024' ! h264parse ! rtph264pay ! udpsink host=10.254.254.105 port=5000 sync=true

параметры запуска клиента на ноутбуке: gst-launch -e udpsrc port=5000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! ffdec_h264 ! xvimagesink sync=false

А вот какое видео у меня получается передать: http://www.youtube.com/watch?edit=vd&v=g5-6QpfQHv4

Ответ на: комментарий от bioniwulf

Указать initial-bitrate у источника uvch264_src:

gst-launch-0.10 -v -e uvch264_src device=/dev/video0  
  initial-bitrate=5000000 name=src auto-start=true src.vidsrc 
  ! queue 
  ! 'video/x-h264,width=960,height=720,framerate=30/1 
  ! h264parse ! rtph264pay 
  ! udpsink host=10.254.254.105 port=5000 sync=true
и сто тыщ мало.

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

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

bioniwulf ()

Т к вы используете udp для передачи видео возможна перезапись буфера приема на принимающем хосте. Проверьте netstat -s (на предмет overrun пакетов), Т е нужно увеличить размер буфера приема на ноутбуке. В BSD системах он обычно по умолчанию 41920, на linux - 131071. Увеличте по максимуму - должно помочь

andyl ()
Ответ на: комментарий от bioniwulf

Какой максимальный битрейт пробовал? Убери вообще битрейт, пусть будет по умолчанию.

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

Поставил более высокое значение (командой sudo sysctl -w net.core.rmem_max=104857600) и ничего так и не изменилось, по листенингу нетстата, как я понял, отброшенных пакетов не особенно много.

Листинг netstat, то что касается UDP:

Udp: пакетов принято: 117275

принято пакетов на неизвестный порт: 27968

ошибок приема пакетов: 669

пакетов послано: 689

bioniwulf ()
Ответ на: комментарий от fopen

попробовал убрать - та же история. Gstreamer свежий, сам собирал с репозитория.

gst-launch-0.10 version 0.10.36

GStreamer 0.10.36 (GIT)

bioniwulf ()
Ответ на: комментарий от andyl

еще возможно поможет: я написал разработчику uvch264_src по поводу этой проблемы, но в виду слабого знания английского и gstreamera я, честно говоря, не особенно понял его ответ. Может у вас лучше получится.

вот его ответ в оригинале: Hi,

Those artifacts look like missing frames, I would suggest you use rtpbin instead of rtph264depay, since it will take care of reordering packets if they arrive in the wrong order (UDP does not keep packet ordering). It would be even better for your application to use farstream directly since it will take care of the whole pipeline setup for you and will send RTCP notification to the other side if a frame is lost (since UDP is not reliable) to request a new keyframe from the encoder. Make sure your bitrate is also low enough to go through your bandwidth, if it's too high (default value is pretty high), it might use up all your bandwidth and cause packets to be dropped.

bioniwulf ()
Ответ на: комментарий от bioniwulf

Написать смог, а прочесть - нет? Ну, ладно... Автор пишет:

Эти артефакты похожи на потерю кадров. Я советую использовать rtpbin вместо rtph264depay, т. к. он переупорядочивает пакеты (при передаче по UDP может измениться порядок пакетов). А еще лучше использовать сразу farstream, который позаботится обо всех аспектах протокола и при потере кадра уведомит об этом кодировщика и попросит новый ключевой кадр. Убедись, что пропускной способности достаточно для твоего битрейта, если он очень большой (а по умолчанию он таки великоват), он может занять всю пропускную способность, что приведет к потере пакетов.

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