Вопрос или проблема
Я пишу библиотеку на Python под названием linuxpy, которая поддерживает V4L2. Одна из возможностей – это возможность открыть устройство V4L2 в неблокирующем режиме (O_NONBLOCK), чтобы быть совместимым с Python async/await.
Я попробовал с несколькими реальными камерами, и всё, похоже, работает правильно. Но когда я тестирую устройство v4l2loopback, оно блокируется, ожидая первого кадра, если я открываю устройство v4l2loopback с O_NONBLOCK.
Кто-нибудь знает, поддерживает ли v4l2loopback O_NONBLOCK?
Это ошибка в v4l2loopback, где poll (всегда) будет блокироваться, если первый вызов poll произошел, когда устройство находилось в состоянии ‘читаемости’.
В реализации v4l2loopback метода poll не вызывался poll_wait, если устройство находилось в состоянии читаемости. Это имеет побочный эффект: если устройство было читаемым при первом вызове poll, последующие вызовы poll_wait в таблице становятся бесполезными; и, следовательно, poll будет блокироваться. См.: https://github.com/torvalds/linux/commit/726daf6 для аналогичного примера.
Ответ или решение
При разработке библиотеки для работы с V4L2, такой как linuxpy, одним из ключевых аспектов является возможность открывать устройства V4L2 в неблокирующем режиме с флагом O_NONBLOCK. Это необходимо для обеспечения совместимости с асинхронным программированием на Python, использующим ключевые слова async и await.
Проблема с v4l2loopback в неблокирующем режиме
Как вы упомянули, большинство реальных камер работает без проблем при открытии устройства в неблокирующем режиме. Однако, когда вы применяете эту настройку к устройству v4l2loopback, возникает блокировка при ожидании первого кадра. Это может быть фрустрирующим, так как критично важно поддерживать асинхронную работу при записи и обработке видеопотоков.
Поддержка O_NONBLOCK в v4l2loopback
Существуют известные проблемы с реализацией функции poll в v4l2loopback. В текущей версии драйвера v4l2loopback, функция poll не вызывает poll_wait, если устройство уже находится в состоянии, когда его можно читать. Это создает зависимость: если poll будет вызван, когда устройство находится в "читаемом" состоянии, дальнейшие вызовы poll_wait становятся неэффективными (no-ops). Таким образом, функция poll начинает блокировать выполнение, создавая задержки в асинхронной обработке.
Решение проблемы
-
Патчинг v4l2loopback: Если у вас есть возможность модифицировать драйвер, рассмотрите шанс исправить этот аспект реализацией функции poll, чтобы она корректно вызывала poll_wait даже в читаемом состоянии. Обратите внимание на аналогичные изменения, сделанные в других драйверах, таких как те, что упомянуты в коммите 726daf6.
-
Проверка версии: Убедитесь, что используемая версия v4l2loopback является актуальной. Возможно, патчи, касающиеся данного поведения, уже были внесены в более поздние версии.
-
Отладка: Используйте инструменты отладки для мониторинга состояния и вызовов функций на этапе выполнения программы. Это поможет выявить, когда и почему происходит блокировка.
-
Параметры конфигурации: Проверьте настройки конфигурации v4l2loopback. Некоторые параметры управления могут значительно влиять на поведение устройства.
Заключение
Проблема с поддержкой O_NONBLOCK в v4l2loopback обусловлена особенностями реализации функции poll. Поэтому для достижения оптимального поведения необходимо рассмотреть возможность модификации драйвера, а также следить за обновлениями, которые могут решить данную проблему в будущем. Это позволит вашей библиотеке linuxpy стать более универсальной и надежной для использования с непрерывным видеопотоком в асинхронных приложениях.