Usb uvc что это
Как UVC драйверы изменили рынок видеозахвата, и что это значит для потребителя
Часто случается, что технологические изменения, которые сначала кажутся весьма незначительными или слишком медленными, в дальнейшем оказывают очень глубокое воздействие на ряд продуктов и соответствующие рынки сбыта.
Внедрение UVC драйверов в крупнейшие операционные системы (Windows, MacOS, Linux и Chrome) как раз относится к одному из таких изменений, которое существенным образом повлияло на рынок видео-граберов.
1. Мобильность
До появления технологии UVC, чтобы начать работу с видео-грабером, необходимо было скачать подходящие драйверы на компьютер и произвести ряд настроек. Это в свою очередь ограничивало возможность подключения других граберов к данному компьютеру или другим системам с аналогичными настройками.
С внедрением UVC драйверов в основные операционные системы UVC-совместимые граберы больше не требуют установки дополнительного программного обеспечения и последующей настройки и будут корректно работать сразу после включения. Благодаря этому видео-грабер может быть не только дополнением к вашему компьютеру, но и одним из самостоятельных аксессуаров к любому из видео-устройств (например, к видео-камере, планшету, HDTV). Такое отделение видео-грабера от компьютера предоставляет подлинную мобильность в сфере видеозахвата.
2. Универсальность и снижение стоимости.
Для многих пользователей отсутствие драйверов – весьма относительный плюс, в то время как для других – это существенное преимущество в работе. Например, на некоторых рабочих местах есть ограничения по загрузке программного обеспечения или запрещено менять конфигурацию системы.
Многие оригинальные приложения видеозахвата, которые уже встроены в популярные операционные системы (например, Windows Camera), тоже являются UVC-совместимыми, и это значит, что пользователю не нужно загружать дополнительные драйверы или устанавливать сторонние приложения. Такая универсальность расширяет рынок сбыта видео-граберов и позволяет поставщикам снизить стоимость продукта.
3. Скорость обновления ОС.
До появления UVC драйверов производителям нужно было разрабатывать соответствующие драйверы для всех своих продуктов и для ведущих операционных систем и постоянно следить за их работоспособностью. Каждый раз требовались обновления под новые версии систем (например, Windows XP, Windows 95, Windows 7, Windows 8.1, Windows 10), которые необходимо было протестировать и максимально адаптировать. Это был очень трудоемкий процесс, затрагивающий в том числе и пользователей, которые сталкивались с проблемами при попытке обновить операционную систему.
Благодаря UVC драйверам эффективность работы значительно повысилась. Например, Microsoft выпускает обновления (включая UVC) с каждой последующей версией Windows. Производителям всё еще нужно тестировать своё оборудование, чтобы убедиться в его совместимости с обновленными UVC драйверами, но теперь эта процедура значительно упростилась и стала менее трудозатратой. Конечным результатом этих изменений стало то, что пользователь, обновивший свою операционную систему, практически больше не столкнется с проблемами в работе подключенных к компьютеру периферийных устройств. В итоге довольны обе стороны: и пользователи, потому что теперь все обновления проходят очень гладко, и производители, потому что им больше не нужно постоянно дорабатывать собственные драйверы.
Такая централизованная разработка, тестирование и поддержка драйверов поставщиками ОС значительно более эффективна для отрасли видеозахвата, и это будет сказываться на стоимости UVC-совместимых устройств. Чем ниже затраты на разработку аппаратного обеспечения, тем ниже стоимость конечного продукта.
4. Конкуренция, инновации и новые разработки.
Ликвидация частных программных разработок также снижает барьер для входа на рынок многим производителям оборудования. Больше не нужно содержать целый штат опытных разработчиков, компании могут позволить себе стать меньше и нацелиться на аппаратные разработки.
Это тоже дает некоторые преимущества пользователям:
- Новые компании несут новые идеи и создают продукты, которых до этого не было на рынке.
- Новые продукты часто весьма успешно конкурируют с существующими продуктами, а это влияет на снижение стоимости для конечного потребителя.
- Устранение необходимости разработки драйверов ускоряет темпы развития продукта и сказывается на расширении ассортимента для потребителя.
5. Еще больше приложений
Так как на рынке растет количество и разнообразие UVC-устройств, соответственно, увеличивается и количество UVC-совместимых сторонних приложений. Видеозахват по мере распространения становится более доступным, и появляются новые программные инструменты для всех сегментов рынка (образование, здравоохранение, промышленность и т.п.). Это также снижает нагрузку на производителей, потому что теперь они могут воспользоваться сторонними приложениями, а не разрабатывать их самостоятельно. Затраты на разработку сокращаются, это привлекает новых участников рынка видеозахвата, усиливает конкуренцию и способствует снижению стоимости продукта.
6. Новые продукты
Другой значительный эффект от фокусировки на аппаратные разработки (в отличие от разработки программного обеспечения, как это было ранее) – необходимость дифференцировать свой продукт. Пользователь больше не выбирает тот продукт, который лучше работает с тем или иным драйвером под той или иной операционной системой. Теперь влияние имеют другие факторы, как например, технические характеристики, производительность, техническая поддержка, наличие документации и т.п.
И что же? Появляется всё больше специализированных продуктов для видеозахвата, созданных специально, чтобы удовлетворить индивидуальные требования потребителя. Так как теперь поставщики прилагают больше усилий, чтобы дифференцировать свои продукты, не имея возможности сделать это посредством разработки драйверов, пользователь снова оказывается в выигрыше, получая более специализированную продукцию с более высокой производительностью и лучшими характеристиками, а также более полную документацию и качественную техническую поддержку.
Подводя итоги.
Внедрение UVC драйверов в большинство операционных систем стало новым этапом в развитии индустрии видеозахвата и принесло значительную пользу потребителю. Теперь при наличии драйверов, поставляемых вместе с ОС, рынок устройств видеозахвата заметно расширился, затраты на разработку сократились, и увеличилась конкуренция, стимулирующая расширение ассортимента и способствующая большей дифференциации продуктов.
Все эти эффекты в совокупности предоставляют потребителю возможность выбора продукта лучшего качества по низкой цене, отличающегося мобильностью, и легко адаптируемого к новым версиям ОС.
Современные гаджеты обладают достаточно широким функционалом, который не только упрощает их эксплуатацию, но и приносит много пользы. В качестве примера можно назвать функцию UVC на смартфоне. Чаще всего она используется как расширение для Video Grabber или Веб-камеры.
Что это такое
Функция UVC Receiver служит для того, чтобы конвертировать аналоговое видео с любых устройств, подключенных к смартфону, и выводить их на телефонный дисплей. Спряжение между гаджетом и вторичным устройством (квадрокоптер, веб-камера, VR-устройства и т. д.) по умолчанию осуществляется через порт типа OTG. Но при использовании дополнительных утилит можно установить спряжение по типу USB.
Проще говоря, Функция UVC Receiver позволяет использовать смартфон в качестве монитора для записывающих устройств, не имеющих встроенного дисплея. До ее создания аналогичную роль выполняло приложение FPViewer, требующее дополнительной оптимизации.Особенности функции
Функция UVC Receiver может использоваться для конвертации аналогового видео с устройств, поддерживающих протоколы UTV-007 HTV-600 и HTV-800. При этом воспроизводимое на экране смартфона видео не будет иметь аудиодорожки, так как данная опция не предусматривает поддержку аудиовыхода.
При смене типа спряжения с базового OTG на более универсальный USB качество трансляции будет потеряно. Ведь максимально допустимое разрешение для Video Grabber при использовании функции UVC составляет всего 640х480 пикселей.
Помимо трансляции опция UVC предусматривает и запись видеофайлов на внутреннюю память смартфона. На выходе пользователь получит видео в формате МР4 без звуковой дорожки. Но использовать эту функцию могут только владельцы операционной системы Андроид 4.3 и выше (утилита работает в фоновом режиме, не блокируя текстовые уведомления и звонки, поступающие на телефон).Как проверить
Опция UVC зачастую входит в базовый функционал современных смартфонов. Но для того чтобы проверить, есть ли она на вашем устройстве, достаточно выполнить следующие простые действия:
Критерием выбора эндоскопа были — недлинный кабель, с подсветка и его толщина.
На кабеле камеры — регулировка яркости подсветки, кнопка для сохранения изображения и разъем микро USB.
1. Переходник с микро USB.
2. Диск с программами.
3. Накручивающееся на камеру зеркало.
4. Фиксатор на камеру для магнита и крючка.
5. Крючок.
6. Магнит.
Правда ничего крупного крючком и магнитом не достанешь…
Тестирование.
С моим сотовым к сожалению не заработал, правда я знал это заранее. Первый признак, что не будет работать — не работает подсветка камеры.
Сотовый должен по USB поддерживать OTG и UVC функции. Проверяли на сотовом брата, у него поддерживаются эти функции. По QR коду на упаковке нашли и установили программу на сотовый, и все заработало. Единственное надо сначала подключить эндоскоп, а затем запустить программу.
Задела строка в инструкции — поддержка на ПК разрешения 1280*720, хотя особо не верилось.
Пробовал программы (под Windows) на диске, и последнюю версию из инета — нет такого разрешения.
Под Windows 10 программа запустилась, но изображения с эндоскопа не получил. Разбираться не стал, все заработало под Windows XP.
На самом деле недолюбливаю Windows, сижу по Linux, потому и не стал ковырялся с Windows 10. Из сборок Linux мне больше всего нравится Xubuntu, под ней и тестировал качество эндоскопа.
Проверял при разной освещенности — в темноте (плюс свет от дисплея ноутбука) и нормальном освещении комнаты.
В чистом виде (без аксессуаров) результаты были не плохие. При нормальной освещенности получилась большая дальность (до метра) и хорошее качество. В темноте дальность
4 см и качество изображения слабое.
Вот зеркало меня разочаровало, вещь — то нужная. То что оно сразу отклеилось не смертельно, а вот дальность и качество изображения…
В чистом виде эндоскоп оправдал мои ожидания, вот только с зеркалом надо будет попытать счастья — может, что и получится.
Я не собирался искать решение, которое работает всегда и везде. Следующие ограничения меня вполне устраивали:
- Хороший WiFi сигнал.
- Ограниченное число подключений, приоритет отдавался случаю, когда есть всего один клиент.
- Камера поддерживает режим MJPG.
HW и SW
Предварительный анализ
Интересная находка
Изучая mjpg-streamer я выяснил, что захват видео на Linux делается с помощью библиотеки v4l2 и для захвата используется очередь буферов. Отлаживая инициализацию этих буферов в mjpg-streamer, я обнаружил, что даже для режима MJPG их размер очень большой и неожиданно совпадает с размером несжатого кадра. Так я стал подозревать, что придется залезть в код драйвера UVC, который отвечает за поддержку камер.
Анализ кода драйвера и первый успех
Изучая код я пришел к выводу, что размер буфера спрашивается у камеры и моя камера возвращала размер несжатого кадра. Наверное это самое безопасное решение с точки зрения разработчиков камеры. Но оно же самое не оптимальное. Я решил, что для своего случая можно скорректировать необходимый размер буфера, используя экспериментальный коэффициент минимального сжатия. Я выбрал k=5. С таким значением у меня был запас порядка 20%.
Строго говоря есть камеры, которые позволяют задать уровень сжатия JPG. Наверное это более правильный способ для определения минимального коэффициента сжатия. Но моя камера не поддерживала эту опцию, и я был вынужден опираться на экспериментальные значения.Код UVC драйвера оказался готов к добавлению различного рода “специальных” решений, и я легко нашел место, где надо скорректировать размер буфера (функция uvc_fixup_video_ctrl()). Более того, драйвер поддерживает набор quirks, которые позволяют поддерживать камеры с разного рода отклонениями от стандарта UVC. В общем, разработчики драйвера сделали лучшее, что возможно для поддержки зоопарка камер.
Добавив коррекцию размера буфера, я получил стабильную работу в режиме 1280х720 и даже в режиме 1920х1080. Ура! Половина задачи решена!
В поисках новых приключений
В mjpg-streamer мне не понравилось использование нескольких потоков и копирование буферов. Это определило архитектуру решения: 1 поток и никакого копирования. Используя non-blocking IO, это делается достаточно просто: захватываем кадр и без копирования отсылаем его клиенту. Есть небольшая проблема: пока мы отсылаем данные из буфера, мы не можем вернуть буфер обратно в очередь. А пока буфер не в очереди, драйвер не может положить в него новый кадр. Но если размер очереди > 1, то это становится возможным. Число буферов определяет максимальное количество подключений, которое можно гарантированно обслуживать. Т.е., если я хочу гарантированно поддерживать 1 клиента, то 3-х буферов достаточно (в один буфер пишет драйвер, из второго отсылаем данные, третий в запасе, чтобы избежать конкуренции с драйвером за буфер при попытке получить новый кадр).
Неожиданная проблема
Все было замечательно: приложение работало и в разрешении 1280х720 выдавало 20+ кадров/сек. Я делал косметические изменения в коде. После очередной порции изменений я замерил частоту кадров. Результат был удручающий — меньше 15 кадров. Я бросился искать, что же привело к деградации. Я потратил, наверное, 2 часа в течение которых частота уменьшалась с каждым замером до значения 7 кадров/сек. В голову лезли разные мысли о деградации из-за долгой работы роутера, из-за его перегрева. Это было что-то непонятное. В какой-то момент я отключил стримминг и увидел, что просто один захват (без стримминга) давал те же 7 кадров. Я даже начал подозревать проблемы с камерой. В общем какая-то чушь. Дело было вечером и камера, повернутая в окно, показывала что-то серое. Дабы сменить мрачное изображение я повернул камеру внутрь комнаты. И, о чудо! Частота кадров увеличилась до 15 и я все понял. Камера автоматически подстраивала время экспозиции и в какой-то момент это время стало больше длительности кадра при заданной частоте. За эти два часа случилось следующее: сначала плавно темнело (это был вечер), а потом я повернул камеру внутрь освещенной комнаты. Направив камеру на люстру я получил 20+ кадров/сек. Ура.
Другие проблемы и нюансы использования
- Автофокус может раздражать. Я задал фиксированный фокус и значение подобрал чтобы было хорошо видно в диапазоне 1-1.5 метра.
- Разные камеры поддерживают разные опции. Чтобы понять, что поддерживает ваша камера, можно воспользоваться утилитой qv4l2, подобрать нужные вам параметры и затем добавить настройку в утилиту. Но бывают сюрпризы: одни и те же настройки могут работать по-разному на разных платформах. В моем случае я столкнулся с разным поведением при одном и том же значении времени экспозиции.
- Питание. Камера питается через USB порт роутера и если напряжение не стабильное, (как например при питании от аккумуляторов) то камера может отключаться (особенно если включен автофокус). Мне помог простой USB хаб (без внешнего питания).
- На роутере очень мало памяти и дискового пространства. По этой причине я отказался от OR-WRT и собрал свой образ OpenWRT, убрав из него все лишнее.
Результаты
Фото получившегося танка (получилось что-то вроде цыганской телеги):
Использование
Исходники находятся здесь. Для использования на PC Linux надо всего лишь собрать (при условии что вы не хотите патчить драйвер UVC). Утилита собирается с помощью CMake стандартным способом. Если же надо использовать в OpenWRT, то надо сделать дополнительные шаги:
Что дальше
Решение состоит из двух частей: патч драйвера и другой алгоритм стримминга. Патч драйвера можно было бы включить в новую версию ядра линукса, но это спорное решение, так как оно основано на предположении о минимальном коэффициенте сжатия. Утилита же, на мой взгляд, хорошо подходит для использования на слабых системах (игрушках, домашних системах видеонаблюдения), и ее можно немного улучшить, добавив возможность задавать настройки камеры через параметры.
Алгоритм стримминга можно улучшить так как есть запас по загрузке CPU и по ширине канала (я легко получал с роутера 50+ MBit подключая десяток клиентов). Также можно добавить поддержку звука.
Я не собирался искать решение, которое работает всегда и везде. Следующие ограничения меня вполне устраивали:
- Хороший WiFi сигнал.
- Ограниченное число подключений, приоритет отдавался случаю, когда есть всего один клиент.
- Камера поддерживает режим MJPG.
HW и SW
Предварительный анализ
Интересная находка
Изучая mjpg-streamer я выяснил, что захват видео на Linux делается с помощью библиотеки v4l2 и для захвата используется очередь буферов. Отлаживая инициализацию этих буферов в mjpg-streamer, я обнаружил, что даже для режима MJPG их размер очень большой и неожиданно совпадает с размером несжатого кадра. Так я стал подозревать, что придется залезть в код драйвера UVC, который отвечает за поддержку камер.
Анализ кода драйвера и первый успех
Изучая код я пришел к выводу, что размер буфера спрашивается у камеры и моя камера возвращала размер несжатого кадра. Наверное это самое безопасное решение с точки зрения разработчиков камеры. Но оно же самое не оптимальное. Я решил, что для своего случая можно скорректировать необходимый размер буфера, используя экспериментальный коэффициент минимального сжатия. Я выбрал k=5. С таким значением у меня был запас порядка 20%.
Строго говоря есть камеры, которые позволяют задать уровень сжатия JPG. Наверное это более правильный способ для определения минимального коэффициента сжатия. Но моя камера не поддерживала эту опцию, и я был вынужден опираться на экспериментальные значения.Код UVC драйвера оказался готов к добавлению различного рода “специальных” решений, и я легко нашел место, где надо скорректировать размер буфера (функция uvc_fixup_video_ctrl()). Более того, драйвер поддерживает набор quirks, которые позволяют поддерживать камеры с разного рода отклонениями от стандарта UVC. В общем, разработчики драйвера сделали лучшее, что возможно для поддержки зоопарка камер.
Добавив коррекцию размера буфера, я получил стабильную работу в режиме 1280х720 и даже в режиме 1920х1080. Ура! Половина задачи решена!
В поисках новых приключений
В mjpg-streamer мне не понравилось использование нескольких потоков и копирование буферов. Это определило архитектуру решения: 1 поток и никакого копирования. Используя non-blocking IO, это делается достаточно просто: захватываем кадр и без копирования отсылаем его клиенту. Есть небольшая проблема: пока мы отсылаем данные из буфера, мы не можем вернуть буфер обратно в очередь. А пока буфер не в очереди, драйвер не может положить в него новый кадр. Но если размер очереди > 1, то это становится возможным. Число буферов определяет максимальное количество подключений, которое можно гарантированно обслуживать. Т.е., если я хочу гарантированно поддерживать 1 клиента, то 3-х буферов достаточно (в один буфер пишет драйвер, из второго отсылаем данные, третий в запасе, чтобы избежать конкуренции с драйвером за буфер при попытке получить новый кадр).
Неожиданная проблема
Все было замечательно: приложение работало и в разрешении 1280х720 выдавало 20+ кадров/сек. Я делал косметические изменения в коде. После очередной порции изменений я замерил частоту кадров. Результат был удручающий — меньше 15 кадров. Я бросился искать, что же привело к деградации. Я потратил, наверное, 2 часа в течение которых частота уменьшалась с каждым замером до значения 7 кадров/сек. В голову лезли разные мысли о деградации из-за долгой работы роутера, из-за его перегрева. Это было что-то непонятное. В какой-то момент я отключил стримминг и увидел, что просто один захват (без стримминга) давал те же 7 кадров. Я даже начал подозревать проблемы с камерой. В общем какая-то чушь. Дело было вечером и камера, повернутая в окно, показывала что-то серое. Дабы сменить мрачное изображение я повернул камеру внутрь комнаты. И, о чудо! Частота кадров увеличилась до 15 и я все понял. Камера автоматически подстраивала время экспозиции и в какой-то момент это время стало больше длительности кадра при заданной частоте. За эти два часа случилось следующее: сначала плавно темнело (это был вечер), а потом я повернул камеру внутрь освещенной комнаты. Направив камеру на люстру я получил 20+ кадров/сек. Ура.
Другие проблемы и нюансы использования
- Автофокус может раздражать. Я задал фиксированный фокус и значение подобрал чтобы было хорошо видно в диапазоне 1-1.5 метра.
- Разные камеры поддерживают разные опции. Чтобы понять, что поддерживает ваша камера, можно воспользоваться утилитой qv4l2, подобрать нужные вам параметры и затем добавить настройку в утилиту. Но бывают сюрпризы: одни и те же настройки могут работать по-разному на разных платформах. В моем случае я столкнулся с разным поведением при одном и том же значении времени экспозиции.
- Питание. Камера питается через USB порт роутера и если напряжение не стабильное, (как например при питании от аккумуляторов) то камера может отключаться (особенно если включен автофокус). Мне помог простой USB хаб (без внешнего питания).
- На роутере очень мало памяти и дискового пространства. По этой причине я отказался от OR-WRT и собрал свой образ OpenWRT, убрав из него все лишнее.
Результаты
Фото получившегося танка (получилось что-то вроде цыганской телеги):
Использование
Исходники находятся здесь. Для использования на PC Linux надо всего лишь собрать (при условии что вы не хотите патчить драйвер UVC). Утилита собирается с помощью CMake стандартным способом. Если же надо использовать в OpenWRT, то надо сделать дополнительные шаги:
Что дальше
Решение состоит из двух частей: патч драйвера и другой алгоритм стримминга. Патч драйвера можно было бы включить в новую версию ядра линукса, но это спорное решение, так как оно основано на предположении о минимальном коэффициенте сжатия. Утилита же, на мой взгляд, хорошо подходит для использования на слабых системах (игрушках, домашних системах видеонаблюдения), и ее можно немного улучшить, добавив возможность задавать настройки камеры через параметры.
Алгоритм стримминга можно улучшить так как есть запас по загрузке CPU и по ширине канала (я легко получал с роутера 50+ MBit подключая десяток клиентов). Также можно добавить поддержку звука.
Читайте также: