Падение частоты кадров веб-камеры на ноутбуке Asus

Мы наблюдаем падение кадровой частоты веб-камеры на ноутбуке Asus с Ubuntu 22.04 в нашем приложении для записи. Когда мы используем qv4l2, чтобы получить системное представление кадровой частоты вне нашего собственного приложения, мы получаем такие отображения:

Эффективная кадровая частота, показанная внизу окна qv4l2, становится произвольно ниже, чем заданная. Это происходит как для встроенной веб-камеры ноутбука, так и для внешних USB-устройств, которые обычно работают с тем же ноутбуком на 30 кадров в секунду при показанном разрешении, как и планировалось, и которые, как известно, работают с этой скоростью при этом разрешении.

Иногда кадровая частота соответствует ожиданиям, а в другие времена она сокращается вдвое и даже хуже, как показано выше. Мы не используем две веб-камеры одновременно, так что не идет речь о конкуренции USB-шины, мы просто часто сталкиваемся с этим, используя каждую из двух веб-камер по отдельности. Мы не знаем, что ноутбук запущен с чем-то другим, что вызывает нагрузку или конкуренцию шины.

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

• Стоит ли проверять данные передачи по USB каким-либо образом?
• Используете ли вы какие-либо команды v4l2 для получения дополнительных полезных диагностик?
• Найдете ли вы журналы производительности системы, чтобы исключить, что прошивка ограничивает процессор или передачу данных, чтобы избежать перегрева?
• Есть ли какие-либо рекомендации о том, на что обратить внимание в огромном выводе sudo turbostat в этом отношении?

P.S. https://arstechnica.com/gadgets/2024/09/real-time-linux-is-officially-part-of-the-kernel-after-decades-of-debate/

—

Правки, касающиеся ожидаемых скоростей передачи данных по USB

Наш код получает MJPG с размером кадра 720×1280 на 30 кадров в секунду. Поскольку (насколько я понимаю) MJPG означает сжатие каждого изображения на стороне камеры, мы можем ожидать, что это будет скорость передачи данных 64.8 Мбит/с, идущая по шине от камеры на USB, не включая накладные расходы протокола связи, если произвольно предположить средний коэффициент сжатия 1:10 на изображение.

Используя usbtop, мы на самом деле видим скорость только 2.3 Мбит/с на практике, на машинах, где проблема с частотой не проявляется, что очень远о от максимальной скорости 480 Мбит/с спецификации USB 2.0, насколько я понимаю, как рекламируемые скорости USB переводятся в скорости передачи данных.

Мы также видим незначительную среднюю скорость USB ~150 Кбит/с от компьютера к камере одновременно, что в общем-то незначительно, однако указывает на то, что некоторые задержки явно обусловлены необходимостью подтверждения данных со стороны принимающей стороны.

Симптомы указывают на несколько потенциальных причин, связанных с потоком данных USB, ограничением процессора или управлением системными ресурсами.

Есть много деталей, которые нужно выяснить, чтобы найти ошибку, но сначала попробуйте следующее, чтобы попытаться выявить причину, чтобы можно было решить проблему:

Используйте dmesg | grep -i usb, чтобы проверить наличие каких-либо проблем, связанных с USB, таких как сбросы или ошибки, которые могут влиять на поток данных веб-камеры.

Также выполните lsusb -t, чтобы просмотреть топологию USB-шины и распределение её пропускной способности, проверьте, чтобы никакие другие устройства не перегружали шину.

Мониторьте производительность системы на наличие ограничения процессора.

Хотя turbostat может генерировать избыточный вывод, обратите внимание на значения “Частота процессора ядра” и “Доля C-State”. Ищите падения частоты процессора, которые могут свидетельствовать об ограничении в связи с мероприятиями управления теплом или питанием.

Также cpupower или cpufreq-info могут помочь определить, регулирует ли генератор частоты процессора динамически частоты так, что это может отрицательно сказываться на реальном времени обработки видео.

Выполнение v4l2-ctl --all может дать общее представление о текущей конфигурации веб-камеры, убедившись, что нет конфликтующих настроек.

Если предыдущие шаги не решили проблему, попробуйте установить фиксированный формат видео с помощью v4l2-ctl --set-fmt-video=width=1280,height=720,pixelformat=MJPG и следите за результатами.

Проверьте /var/log/syslog и /var/log/kern.log на наличие сообщений о тепловом ограничении, изменениях в управлении питанием или ошибках USB, которые соответствуют времени падения кадров.

Также рассмотрите возможность использования usbtop для мониторинга данных о текущих скоростях передачи по USB, что может показать, если веб-камера время от времени испытывает нехватку пропускной способности.

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

Удачи!