Блог

Главная - Вопросы по программированию - Потоковое видео GStreamer низкая производительность

Потоковое видео GStreamer низкая производительность

#gstreamer

#gstreamer

Вопрос:

Я транслирую Gstreamer’s videotestsrc с raspberry pi. Поток должен быть TCP.

Мой серверный конвейер:

 gst-launch-1.0 videotestsrc horizontal-speed=5 ! x264enc tune="zerolatency" threads=1 ! mpegtsmux ! tcpserversink host=10.0.0.7 port=3344

Мой клиентский конвейер:

 gst-launch-1.0 tcpclientsrc port=3344 host=10.0.0.7 ! tsdemux ! h264parse ! avdec_h264 ! autovideosink

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

  1. Raspberry pi требует большой мощности процессора, около 60%.

  2. Качество очень плохое. Я постоянно получаю некоторые поврежденные области, например, прямоугольники неправильного цвета, и видео иногда застревает на короткое время.

  3. Я получаю подобные ошибки в клиентском терминале: ошибка при декодировании 5 МБ 13, байтовый поток 2817

Я использовал https://github.com/silvanmelchior/RPi_Cam_Web_Interface раньше (конечно, используя камеру raspberry pi вместо videotestsrc). У него очень низкая задержка, хорошее качество и почти нет мощности процессора. Но оно написано на PHP, и я хотел бы реализовать поток в приложении на c . Мне кажется, что GStreamer — хороший выбор для меня, поскольку именно для этих заданий он и был создан. Я также отлично использую GStreamer для потоковой передачи аудио.

Мои вопросы:

  1. Почему GStreamer требует такой большой мощности процессора, в то время как RPi_Cam_Web_Interface почти ничего не требует? Это проблема с videotestsrc (потому что он создается в реальном времени)?

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

  3. Что я могу сделать, чтобы повысить эффективность и качество моей настройки?

Комментарии:

1. videotestsrc действительно создает сэмплы настолько быстро, насколько это возможно. Вы можете имитировать источник в реальном времени, передав is-live=true для videotestsrc . Также RPi поддерживает аппаратное кодирование H.264 (я думаю). x264enc работает в программном обеспечении, что имеет большое значение. Проверьте, как использовать аппаратный кодировщик RPi через GStreamer.

2. Спасибо. Действительно, проблема заключалась в videotestsrc. Я записал videotestsrc в файл, а затем воспроизвел файл на tcpserversink. Все проблемы устранены.

Ответ №1:

Вы можете снизить нагрузку на процессор, используя decodebin вместо avdec_h264. Я также пытаюсь повысить производительность, если кто-нибудь знает, пожалуйста, помогите

Комментарии:

1. Привет, я решил свои проблемы, и теперь я неплохо разбираюсь в gstreamer. Если вы попытаетесь сделать то, что я сделал, я рекомендую вам записать ваш videostestsrc на файловый канал, а затем воспроизвести файл. По-видимому, это также работает с добавлением live = true в videotestsrc, я не пробовал. Проблема в том, что videotestsrc создает как можно больше изображений, что приводит к большой загрузке процессора.

Ответ №2:

  • Вы используете один и тот же raspberry pi для серверного и клиентского конвейеров, поэтому они используют одинаковые ресурсы soc, чем больше потребляет мощность процессора и выделяет тепла, тем лучше подключить радиатор к raspberry pi.
  • Если у вас есть другой компьютер или raspberry pi, вы можете использовать его для отладки, чтобы выяснить, что плохое качество возникает при работе на стороне сервера или клиента или при смешивании сервер-клиент в предыдущем сценарии.
  • Вы можете попробовать разные частоты кадров, используя caps внутри ваших конвейеров, затем изменить частоту кадров и увидеть различия в качестве выходного видео. и попробуйте v4l2src для серверного конвейера и измените разрешения и проверьте различия в выходных сценариях. Вот шаги, которым я следовал, чтобы оптимизировать свои потоковые конвейеры