Кажется правдоподобным, эта цифра фигурирует в ряде публикаций, но если посмотреть источники к инфографике, то эта цифра восходит к статье отраслевого https://www.nycaviation.com/2011/09/fun-facts-revealed-at-boeings-787-technical-panel Там они пишут о fly by wire system. А для авто подсчеты сделаны с учетом той же мультимедийной системы, которая к управлению автомобилем отношения не имеет. Хабровчане, кто из вас имел дело с ПО самолетов? Как много дополнительных вспомогательных электронных систем кроме нее есть на борту? Кроме того, тут могут быть и другие нюансы, так как и ПО и авионику наверняка обновляют, а те подсчеты относятся к боингам образца 2011 года, сразу после введения в эксплуатацию.
Мы тоже рады видеть схожие подходы у другой команды. Так победим!) Видимо в чем-то у нас были схожие предпосылки и получилась эдакая параллельная эволюция. Пожалуй, это аргумент в пользу жизнеспособности наших подходов.
Кстати, если взять срез по научным статьям, то там тоже прослеживается такая закономерность. Возможно это разновидность ошибки выжившего. Мы вот чаще работаем по Agile и все эти проблемы очень знакомые, а болячки Waterfall не такие натоптанные. Так и в литературе - в последние годы все носятся с гибкими методологиями, а тема каскадной остается недораскрыта.
Что касается Cuda, продублирую ссылку из ответа выше. Cuda в нашем случае помогает компиляции ffpmeg, а сама оптимизация позволяет задействовать на этом фреймворке половину вычислительных процессов. С++ использовать тоже не обязательно, но процесс уже был запущен — питоновская версия была переписана на Golang, а он нам не подходил. Видеоридер, переписанный на С++ требовал сборки ffmpeg, работающей на GPU с подключением OpenCV. Таким образом, проблема питоновской версии была в отсутствии многопоточности и в том, что на этапе подключения нашей команды, этой версии уже не существовало. Логично предположить, что текущую версию видеоридера можно пересобрать на питоне, с учетом новых моментов и подключения gstreamer.
С этой точки зрения все верно, OpenCV действительно можно было бы не использовать, как и бекэнд ffpmeg. У нас в этом была «историческая нужда» и ограничение по срокам, не было задачи все переделать. Вместо OpenCV можно было бы попробовать общаться напрямую с библиотеками, такой вариант более удобен и оптимизирован. По поводу использования gstreamer`а — да, есть вероятность, что в будущей версии мы так и поступим, снова пересобрав видеоридер на Python. Сама статья написана скорее в контексте рассказа о том, с какими ошибками нам пришлось столкнуться, и какое решение было реализовано.
"для работы с GPU", а не на GPU. Тут речь о том, чтобы: 1. собирать ffmpeg оптимизированный под gpu: https://docs.nvidia.com/video-technologies/video-codec-sdk/12.0/ffmpeg-with-nvidia-gpu/index.html 2. Собрать OpenCV с включенным ffmpeg-ом в конфигурациях сборки. Если в системе несколько версий ffmpeg-а, то указать конкретно нашу в конфигурациях. Если в дальнейшем предполагается работа на питоне, то конфигурировать сборку питон версии.
Это скорее статья про ошибки, которые могут наделать новички, они часто используют OpenCV на питоне. Если глубоко разбираться в видеонаблюдении можно сделать красивее. У нас такой задачи не было, на этом этапе просто нужен был более менее оптимальный ридер, который не убивает CPU, GPU и оперативку.
В основе ffmpeg-а лежит libavcodec, и с ним можно работать напрямую. Мы об этом думали, но не хватало опыта конкретно в этом аспекте, опять же, все уперлось в сроки.
Насчет буфера, мы действительно туда ничего не кладем, ffmpeg это делает сам. Кто конкретно создает пакеты (ffmpeg или libavcodec) в буфер с ходу не скажу, так как мы работаем с этими библиотеками не напрямую, а через OpenCV. Но буфер там есть, и его нужно прокручивать, так это реализовано в OpenCV.
В определенный момент косились в его сторону, но время серьезно поджимало и экспериментировать не стали. Сделали выбор в пользу знакомого стека. Решили, что иначе можем нарваться на новые, непонятные подводные камни.
Еще немного поясню, не очень понятно написал. Тут есть два этапа, сначала детекция плашки с номером, а потом распознавание того, что написано на ней. Что касается детекции, то yolo неплохо умеет находить мелкие объекты, и если дообучить - делает вполне надежно. Она детектирует номерной знак, мы его отслеживаем и выбираем такой кадр, где он будет достаточно хорошо виден чтобы распознать надпись на нем. Вырезаем из кадра знак, решейпим до 480х480 и дальше работаем уже с такой, подготовленной картинкой.
У камеры FullHD разрешение, 2440 на 2040, поэтому у автомобилей в части кадра (обычно в половине кадра, зависит от того, как разместить камеру) достаточно крупный номерной знак для распознавания символов. В итоге у нас за трек набирается много распознаваний, мы выбираем те, где лучше видно, и оттуда берем номер.
У нас джетсон тянул 20 fps с 2к разрешением, но это именно получение через aravis. Такой fps был выставлен заказчиком на камере. Других экспериментов не проводили
Вы правы в том, что неправильная работа такой системы может принести много неприятностей. Особенно с учетом того, что процедура обжалования штрафов оставляет желать лучшего. Именно поэтому мы изначально дизайним все так, чтобы она не совершала подобных ошибок и постарались рассказать об этом в статье. Вероятность, что наше средство измерений покажет скорость некого автомобиля 100500 км/час нулевая, поскольку машина с такой скоростью не может появиться в ограниченном поле зрения камеры более одного раза, а трек не может состоять из одной точки. Безусловно, расчет погрешности проводился, она состоит из нескольких факторов, таких как погрешность определения рамки ТС детектором, ошибка преобразования координат между изображением и реальным миром, неточности, допущенные при процедуре разметки и т д. Если какие-то из этих ошибок значительно влияют на работоспособность системы (например, серьезная ошибка при разметке), это выявляется внутренними средствами программного комплекса, которые подадут сигнал, что система не готова к эксплуатации. Некоторые же компоненты просто не могут нанести подобный ущерб, например, если нейронная сеть (которая на самом деле обучена к распознаванию в разных погодных условиях) будет значительно ошибаться в детекциях, это будет моментально замечено трекером. А в нормальной, рабочей ситуации, когда подготовительная работа к установке комплекса выполнена корректно, ошибка не превышает указанных в статье значений. И, разумеется, прежде чем появиться на дорогах, комплекс должен пройти экспертизу в соответствующих органах. Что до "нейросети принято переобучать", все вопросы с обучением нейросети решаются до выхода в прод.
Датасет, который мы в итоге заказали, как раз таки во многом основан на видео с ютуба. Наверное, в статье стоило по подробнее осветить этот момент. Не то, чтобы в сети совсем не было примеров аварий, проблема скорее в том, что эти данные очень "грязные", их невозможно быстро взять и использовать как есть. Нужно очень многое фильтровать - те же записи с ютуб очень разные - вперемешку видео с регистраторов и дорожных камер, от лица попавших в аварию и со стороны, часто встречаются вотермарки, разный масштаб, нестандартные ракурсы. В то время у нас не было ресурсов для сбора и очистки датасета (это довольно дорогое удовольствие и по времени, и по трудозатратам) и мы до последнего пытались обойтись без него. Ретроспективно можно сказать, что было не самое оптимальное решение, но в любом случае мы получили ценный опыт, и в итоге заказчик остался доволен.
Смотря, что иметь в виду под областью применения. Если говорить о процессах, то это в первую очередь оповещение экстренных служб. Пока подразумевается, что у оператора загорится условная лампочка, он посмотрит на камеру и решит, какая помощь требуется на месте аварии. В перспективе на основе этих данных можно включать выключать светофоры, перенаправлять транспортные потоки + сбор статистики, выявление проблемных перекрестков и развязок и т. д. Применений может быть много.
Если же говорить, о том, где это будет развернуто, то под присмотром Минтранса в ряде регионов уже идут пилотные программы с длинными путанными названиями. Собственно все гифки и записи статей - с тестирования на реальных городских улицах. К сожалению, не уверен, что могу назвать город, для которого мы делаем этот проект. Кажется, они еще не делали официальных объявлений.
Кажется правдоподобным, эта цифра фигурирует в ряде публикаций, но если посмотреть источники к инфографике, то эта цифра восходит к статье отраслевого https://www.nycaviation.com/2011/09/fun-facts-revealed-at-boeings-787-technical-panel Там они пишут о fly by wire system. А для авто подсчеты сделаны с учетом той же мультимедийной системы, которая к управлению автомобилем отношения не имеет.
Хабровчане, кто из вас имел дело с ПО самолетов? Как много дополнительных вспомогательных электронных систем кроме нее есть на борту?
Кроме того, тут могут быть и другие нюансы, так как и ПО и авионику наверняка обновляют, а те подсчеты относятся к боингам образца 2011 года, сразу после введения в эксплуатацию.
О, это отдельная тема для разговора - немного порассуждали о ней в другой статье.
Мы тоже рады видеть схожие подходы у другой команды. Так победим!) Видимо в чем-то у нас были схожие предпосылки и получилась эдакая параллельная эволюция. Пожалуй, это аргумент в пользу жизнеспособности наших подходов.
Кстати, если взять срез по научным статьям, то там тоже прослеживается такая закономерность. Возможно это разновидность ошибки выжившего. Мы вот чаще работаем по Agile и все эти проблемы очень знакомые, а болячки Waterfall не такие натоптанные. Так и в литературе - в последние годы все носятся с гибкими методологиями, а тема каскадной остается недораскрыта.
Интересно, а как вы пришли к этой конструкции, и из каких предпосылок она сформировалась?
Это применяется так редко, что просто забываешь, что он есть xD
Что касается Cuda, продублирую ссылку из ответа выше. Cuda в нашем случае помогает компиляции ffpmeg, а сама оптимизация позволяет задействовать на этом фреймворке половину вычислительных процессов. С++ использовать тоже не обязательно, но процесс уже был запущен — питоновская версия была переписана на Golang, а он нам не подходил. Видеоридер, переписанный на С++ требовал сборки ffmpeg, работающей на GPU с подключением OpenCV. Таким образом, проблема питоновской версии была в отсутствии многопоточности и в том, что на этапе подключения нашей команды, этой версии уже не существовало. Логично предположить, что текущую версию видеоридера можно пересобрать на питоне, с учетом новых моментов и подключения gstreamer.
С этой точки зрения все верно, OpenCV действительно можно было бы не использовать, как и бекэнд ffpmeg. У нас в этом была «историческая нужда» и ограничение по срокам, не было задачи все переделать. Вместо OpenCV можно было бы попробовать общаться напрямую с библиотеками, такой вариант более удобен и оптимизирован. По поводу использования gstreamer`а — да, есть вероятность, что в будущей версии мы так и поступим, снова пересобрав видеоридер на Python. Сама статья написана скорее в контексте рассказа о том, с какими ошибками нам пришлось столкнуться, и какое решение было реализовано.
На входе кодек H264. Для дальнейшей оптимизации действительно планируем работу уже через gstreamer.
"для работы с GPU", а не на GPU.
Тут речь о том, чтобы:
1. собирать ffmpeg оптимизированный под gpu: https://docs.nvidia.com/video-technologies/video-codec-sdk/12.0/ffmpeg-with-nvidia-gpu/index.html
2. Собрать OpenCV с включенным ffmpeg-ом в конфигурациях сборки. Если в системе несколько версий ffmpeg-а, то указать конкретно нашу в конфигурациях. Если в дальнейшем предполагается работа на питоне, то конфигурировать сборку питон версии.
Это скорее статья про ошибки, которые могут наделать новички, они часто используют OpenCV на питоне. Если глубоко разбираться в видеонаблюдении можно сделать красивее. У нас такой задачи не было, на этом этапе просто нужен был более менее оптимальный ридер, который не убивает CPU, GPU и оперативку.
В основе ffmpeg-а лежит libavcodec, и с ним можно работать напрямую. Мы об этом думали, но не хватало опыта конкретно в этом аспекте, опять же, все уперлось в сроки.
Насчет буфера, мы действительно туда ничего не кладем, ffmpeg это делает сам. Кто конкретно создает пакеты (ffmpeg или libavcodec) в буфер с ходу не скажу, так как мы работаем с этими библиотеками не напрямую, а через OpenCV. Но буфер там есть, и его нужно прокручивать, так это реализовано в OpenCV.
В определенный момент косились в его сторону, но время серьезно поджимало и экспериментировать не стали. Сделали выбор в пользу знакомого стека. Решили, что иначе можем нарваться на новые, непонятные подводные камни.
Еще немного поясню, не очень понятно написал. Тут есть два этапа, сначала детекция плашки с номером, а потом распознавание того, что написано на ней. Что касается детекции, то yolo неплохо умеет находить мелкие объекты, и если дообучить - делает вполне надежно. Она детектирует номерной знак, мы его отслеживаем и выбираем такой кадр, где он будет достаточно хорошо виден чтобы распознать надпись на нем. Вырезаем из кадра знак, решейпим до 480х480 и дальше работаем уже с такой, подготовленной картинкой.
У камеры FullHD разрешение, 2440 на 2040, поэтому у автомобилей в части кадра (обычно в половине кадра, зависит от того, как разместить камеру) достаточно крупный номерной знак для распознавания символов. В итоге у нас за трек набирается много распознаваний, мы выбираем те, где лучше видно, и оттуда берем номер.
У нас джетсон тянул 20 fps с 2к разрешением, но это именно получение через aravis. Такой fps был выставлен заказчиком на камере. Других экспериментов не проводили
Мы использовали для работы с api камеры Aravis. Через него работали с камерой. Конечно, если я правильно понял вопрос.
Вы правы в том, что неправильная работа такой системы может принести много неприятностей. Особенно с учетом того, что процедура обжалования штрафов оставляет желать лучшего. Именно поэтому мы изначально дизайним все так, чтобы она не совершала подобных ошибок и постарались рассказать об этом в статье.
Вероятность, что наше средство измерений покажет скорость некого автомобиля 100500 км/час нулевая, поскольку машина с такой скоростью не может появиться в ограниченном поле зрения камеры более одного раза, а трек не может состоять из одной точки. Безусловно, расчет погрешности проводился, она состоит из нескольких факторов, таких как погрешность определения рамки ТС детектором, ошибка преобразования координат между изображением и реальным миром, неточности, допущенные при процедуре разметки и т д.
Если какие-то из этих ошибок значительно влияют на работоспособность системы (например, серьезная ошибка при разметке), это выявляется внутренними средствами программного комплекса, которые подадут сигнал, что система не готова к эксплуатации. Некоторые же компоненты просто не могут нанести подобный ущерб, например, если нейронная сеть (которая на самом деле обучена к распознаванию в разных погодных условиях) будет значительно ошибаться в детекциях, это будет моментально замечено трекером. А в нормальной, рабочей ситуации, когда подготовительная работа к установке комплекса выполнена корректно, ошибка не превышает указанных в статье значений. И, разумеется, прежде чем появиться на дорогах, комплекс должен пройти экспертизу в соответствующих органах. Что до "нейросети принято переобучать", все вопросы с обучением нейросети решаются до выхода в прод.
Увы, кажется, эта проблема уже не в плоскости машинного обучения :(
Датасет, который мы в итоге заказали, как раз таки во многом основан на видео с ютуба. Наверное, в статье стоило по подробнее осветить этот момент. Не то, чтобы в сети совсем не было примеров аварий, проблема скорее в том, что эти данные очень "грязные", их невозможно быстро взять и использовать как есть. Нужно очень многое фильтровать - те же записи с ютуб очень разные - вперемешку видео с регистраторов и дорожных камер, от лица попавших в аварию и со стороны, часто встречаются вотермарки, разный масштаб, нестандартные ракурсы. В то время у нас не было ресурсов для сбора и очистки датасета (это довольно дорогое удовольствие и по времени, и по трудозатратам) и мы до последнего пытались обойтись без него. Ретроспективно можно сказать, что было не самое оптимальное решение, но в любом случае мы получили ценный опыт, и в итоге заказчик остался доволен.
Смотря, что иметь в виду под областью применения. Если говорить о процессах, то это в первую очередь оповещение экстренных служб. Пока подразумевается, что у оператора загорится условная лампочка, он посмотрит на камеру и решит, какая помощь требуется на месте аварии. В перспективе на основе этих данных можно включать выключать светофоры, перенаправлять транспортные потоки + сбор статистики, выявление проблемных перекрестков и развязок и т. д. Применений может быть много.
Если же говорить, о том, где это будет развернуто, то под присмотром Минтранса в ряде регионов уже идут пилотные программы с длинными путанными названиями. Собственно все гифки и записи статей - с тестирования на реальных городских улицах. К сожалению, не уверен, что могу назвать город, для которого мы делаем этот проект. Кажется, они еще не делали официальных объявлений.