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

Увеличить bit rate.

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

Указать 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

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

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

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

А! И gstreamer какой версии? Свежий?

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

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

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

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

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

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

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

gst-launch-0.10 version 0.10.36

GStreamer 0.10.36 (GIT)

еще возможно поможет: я написал разработчику 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.

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

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