Comments 6
А причём тут реверс инженерия, если Вы с исходными кодами работали?
Не уверен, что использование пропатченой вами OpenCV, причём далеко не лучшим образом чем некоторое усложение программы асинхронность. Тем более, что в современном C++ есть все необходимые стандартные инст рументы — async, promise, future, packaged_task…
Я бы может вам и посовтовал бы отправить пулл реквест в OpenCV с вашими изменениями ( концептуально то они правильные), но его ведь не приймут, так как это действительно грязные хак.
В общем, вы уж извините, но именно из-за такого обилия грязных хаков в нашей сфере и нежелания некоторых личностей операционки кишал программами, которые нормально не работаютпосле обновления ОС, после замены библиотек, при любых нестандартных условиях выполнения, при не ожидаемом поведении пользователя… И тут должна быть ссылка про программисто ви самолёт. В общем грустно, что Вам в голову пришло такое решение и проблемы, но мало того, Вы решили ещё его распространить, чтоб в мире стало больше хаоса.
Я бы может вам и посовтовал бы отправить пулл реквест в OpenCV с вашими изменениями ( концептуально то они правильные), но его ведь не приймут, так как это действительно грязные хак.
В общем, вы уж извините, но именно из-за такого обилия грязных хаков в нашей сфере и нежелания некоторых личностей операционки кишал программами, которые нормально не работаютпосле обновления ОС, после замены библиотек, при любых нестандартных условиях выполнения, при не ожидаемом поведении пользователя… И тут должна быть ссылка про программисто ви самолёт. В общем грустно, что Вам в голову пришло такое решение и проблемы, но мало того, Вы решили ещё его распространить, чтоб в мире стало больше хаоса.
Клавиатура сломалась? :)
По теме, конечно, Вы правы — решения подобного рода создают некоторые проблемы. Конечно, в случае простого воспроизведения видео перечисленные стандартные инструменты достаточно просто решают эту проблему. В конкретно этом случае, помимо воспроизведения на это видео была наложена достаточно сложная обработка в трех различных потоках, и освобождение всех ресурсов(хотя бы для того, чтобы вернуться в состояние «мы ничего не воспроизводим и не обрабатываем, можем подключаться к другой камере») было возможным только после завершения таймаута — т.к. потоки должны завершить работу, а один из них висит в блокирующем вызове и держит пару других в блокировках — ждут следующего кадра. Можно было перейти на сигналы/слоты Qt, другие способы асинхронной передачи, только вот для того, чтобы прийти в вышеупомянутое состояние, так или иначе работу всего включенного нужно завершить. Если задача не в том, чтобы "написать красиво, идеально, по всем стандартам", а "сделать так, чтобы успеть по графику, получить простой в обращении и модифицируемый код" — а именно так обычно и нужно в продакшене — порой проще сделать некорректно.
Конечно, ситуацию можно назвать ошибкой проектирования, или некорректным выбором способа захвата видеопотока, или же отсутствием опыта программистов, ответственных за задачу, безусловно, но статья не несет в себе цели принести этот способ в массы — скорее, обратить внимание на проблему. Что, фактически, мешает разработчикам добавить в класс VideoCapture пару методов вроде setOpenTimeout/setReadTimeout? Гвоздями забитые #define TIMEOUT 30000? Мы за такое у себя на работе морду бьем. Пытался связаться с разрабами — безрезультатно. Вот и статья.
По теме, конечно, Вы правы — решения подобного рода создают некоторые проблемы. Конечно, в случае простого воспроизведения видео перечисленные стандартные инструменты достаточно просто решают эту проблему. В конкретно этом случае, помимо воспроизведения на это видео была наложена достаточно сложная обработка в трех различных потоках, и освобождение всех ресурсов(хотя бы для того, чтобы вернуться в состояние «мы ничего не воспроизводим и не обрабатываем, можем подключаться к другой камере») было возможным только после завершения таймаута — т.к. потоки должны завершить работу, а один из них висит в блокирующем вызове и держит пару других в блокировках — ждут следующего кадра. Можно было перейти на сигналы/слоты Qt, другие способы асинхронной передачи, только вот для того, чтобы прийти в вышеупомянутое состояние, так или иначе работу всего включенного нужно завершить. Если задача не в том, чтобы "написать красиво, идеально, по всем стандартам", а "сделать так, чтобы успеть по графику, получить простой в обращении и модифицируемый код" — а именно так обычно и нужно в продакшене — порой проще сделать некорректно.
Конечно, ситуацию можно назвать ошибкой проектирования, или некорректным выбором способа захвата видеопотока, или же отсутствием опыта программистов, ответственных за задачу, безусловно, но статья не несет в себе цели принести этот способ в массы — скорее, обратить внимание на проблему. Что, фактически, мешает разработчикам добавить в класс VideoCapture пару методов вроде setOpenTimeout/setReadTimeout? Гвоздями забитые #define TIMEOUT 30000? Мы за такое у себя на работе морду бьем. Пытался связаться с разрабами — безрезультатно. Вот и статья.
Всё-таки OpenCV предназначена в первую очередь для разработки алгоритмов компьютерного зрения. Создание единого интерфейса для чтения видео сюда не очень вписывается. VideoCapture предоставляет лишь базовые возможности, если вам нужно что-то особенное, то лучше использовать библиотеку ffmpeg напрямую.
Кстати, скрипты для сборки opencv_ffmpeg.dll можно найти в этом репозитории.
Кстати, скрипты для сборки opencv_ffmpeg.dll можно найти в этом репозитории.
Sign up to leave a comment.
OpenCV: установка таймаута на ожидание кадра в классе VideoCapture