Pull to refresh

Comments 32

Ох, а почему бы не посмотреть в сторону gstreamer? Я как раз с ним работаю. Там такие вещи гораздо проще делаются. Делаете AppSink и принимаете уже готовые декодированные фоеймы прямо с потока. В добавок есть шина сообщений от всех элементов. В общем — рекомендую попробовать.
Основная причина использования FFmpeg — это аппаратное декодирование. О нем я напишу в следующей статье. Декодирование dxva2 на Intel Atom Z8350 + возвращение каждого кадра в оперативную память + вывод на экран средствами WinApi занимает около 15%. Что на мой взгляд не плохо.
gstreamer — имеет поддержку dxva2? Позволяет он малыми ресурсами переписывать кадр в оперативную память средствами SSE4?
Я начинал с VLC, он позволяет сделать видеопроигрыватель буквально в 10 строк кода. Загрузка процессора около 5%. Но возврат кадров в оперативную память загружает процессор под 50%. Тогда программный декодер FFmpeg в среднем загружает процессор меньше.
Причина кадр FullHD в NV12 занимает почти 3 МБайта, т.е. 75 МБайт в секунду нужно переписывать.
А почему на Cherry Trail HD Graphics не qsv, а dxva2? Камень, вроде, позволяет. У меня малинка спокойно RTSP 1920p 25fps декодит по mmal льет и на диск и в текстуру.
И avcodec_decode_video2 давно deprecated и av_dict_set(&videoOptions, «threads», «auto», 0) хорошо бы на многоядерном камне
Хотел qsv, но ждало — разочарование. QSV Intel поддерживает только с i3 (не ниже 8 gen). Все что ниже Pentium, Celeron и тем более ATOM программно выключено.
В подтверждение своих слов ссылка: https://trac.ffmpeg.org/wiki/Hardware/QuickSync
Там вы найдете фразу: Ensure the target machine has a supported CPU. Current versions only support gen8/gen9 graphics on expensive CPUs («Xeon»/«Core i» branding). The same graphics cores on cheaper CPUs («Pentium»/«Celeron»/«Atom» branding) are explicitly disabled, presumably for commercial reasons.
Т.е. в ATOM отключено по коммерческим причинам.
P.S. После применения Z83II, у меня, интерес к Raspberry PI пропал. Разница в цене не принципиальна, размеры не на много больше, ток потребления аналогичен, но вычислительные возможности намного выше.
Аппаратная камера и возможность лить прямо в EGL текстуру на малинке рулят. Под интеловскую графику в линукс я так и не смог получить EGLый контекст, а необходимость memcpy в текстуру, несмотря, даже на dma через PBO сводят разницу в производительности CPU к нулю, что и подтверждает автор
Intel — это тоже позволяет. VLC — это хороший пример этого. Загрузка около 5% для Intel ATOM. Т.е. получение потока RTSP + декодирование DXVA2 + вывод на экран.
понятно, что позволяет. Вопрос в том, что и решение втрое дешевле позволяет добиться аналогичных результатов. Наличие аппаратной камеры на интел я как-то проглядел. Не подскажете, что к чему?
Ну не в 3-е дешевле это точно. Я купил за 82 бакса с бесплатной доставкой. Распберри стоит 35+доставка+корпус+блок питания+SD-карта+радиатор. Z83II это все имеет + 2Гб оперативной памяти + Windows10 (бесплатная лицензия на 1 пользователя) + 2 кабеля HDMI (длинный и короткий) + крепление к телевизору/монитору. И мой взгляд для компьютерного зрения Raspberry PI слабоват.
Ну так камера тоже денег стоит. Я имел ввиду, что на основе малинки можно сделать камеру, которая будет решать часть поставленных задач. Цена вопроса 4.5 тр без корпуса
4500 руб это где то 70 баксов (без корпуса)
За 10 баксов можно купить приличную вебку и разница явно не в разы:) А серьезную обработку на Raspberry PI real-time не сделать. Ну это мое мнение.
У меня есть камера Raspberry PI 8MP. Но честно нет идей, как ее можно применить, т.к. она коротко фокусная и ее необходимо приближать к объекту.
Пробовал на основе нее сделать сканер штрих-кода. Но если нет очень хорошего освещения прочитать штрих-код невозможно. Матрица никакая:(
у меня с трансфокатором и ик подсветкой. Трансфокатор, правда ручной. Делал домой IP камеру на ее основе + малина. Льет по RTSP, пишет на SMB шару по движению. 1920p/25. Реалтайм на любой RTSP смотрелке VLС/FFMPEG/на телефоне tinyCam. Архив — на чем угодно по DLNA хоть на телевизоре, хоть на утюге))
Читал, что 5 Мп матрица еще хуже чем 8Мп. Просто смысл, цена такого решения не низкая, если сравнить с ценой камеры IP Atis, то что на фото 50 баксов. Клиенту — это решение сложно поставить.
Смысл в гибкости. У меня, например, она кидает в телегу, когда дверь открыта. Возможность независимо управлять 2-мя потоками с камеры. Например 1-ый в 1920 отдает в h264 Annex-b непосредственно для RTP, а второй в 640x480 YUV для детектирования движеня ну или, допустим, предварительной обработки для расп. номеров, а потом уже в кодер и, допустим на экран. Все это хозяйство не надо malloc/memcpy, поскольку используются одни и те же буферы. Наличие полноценного EGL, а значит Qt eglfs, без необходимости грузить иксы. Загрузка меньше 4сек.

Разве? На G4560 аппаратное кодирование через quick sync нормально работает, декодирование должно тоже работать. Правда я проверял через handbrake на Windows, не знаю, что он использует.

Графика Intel? Какой драйвер стоит?
Да, может, если есть нативные кодеки, то будет их использовать.
не будет. Надо руками avcodec_find_decoder_by_name(«h264_qsv»)
Подтверждаю надо руками:)
Мы точно про gstreamer?! Кстати там есть и нативный avdec_h264.
Я говорил про gstreamer в самом начале этой ветки.

Задача учебная или реальная? Просто если реальная, то это вроде можно сделать командой-однострочником:


ffmpeg -i 'rtsp://user:passwd@192.168.1.168' -vf "select=not(mod(n\,25))" -vsync vfr -f image2 image%03d.ppm

(здесь же можно поиграться с фильтрами и аппаратным декодированием, но мне сейчас лень)


А ещё я обычно дописываю -rtsp_transport tcp, потому что udp у меня работает нестабильно даже по локальной сети

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

Лично я просто подаю stdout из этой команды-однострочника в stdin другой программе для обработки — тоже через оперативную память (вывод в файлы отключаем) и тоже реал-тайм) Впрочем, для более сложных задач это уже не очень подойдёт

Вам надо декодировать только i-frames. Это требует просто мизерных ресурсов, особенно по сравнению с полным декодированием потока и дает устойчивость к потерям P кадров.
Например, так:
ffmpeg -ss <start_time> -i video.mp4 -t <duration> -q:v 2 -vf select="eq(pict_type\,PICT_TYPE_I)" -vsync 0 frame%03d.jpg

P.S. Естественно, в настройках камеры логично поставить, чтобы I кадры шли каждую секунду.
P.P.S. Еще логичнее сказать камере сохранять jpeg snapshots каждую секунду и не мучать себе мозг.
Мне нужно декодировать каждый кадр, обновлять background, появился большой объект и если да искать номерную пластину с номером. Здесь же учебный пример: видно где получен кадр и можно сделать более серьезный обработчик.
P.S. автомобиль со скоростью 60 км/ч за секунду проезжает 16,7 м. Если обрабатывать кадр в секунду, то большая часть автомобилей будет проезжать не замеченной.
Мы получили достаточно хорошие результаты в определении российских номеров на статической картинке (до 97%) с неплохим быстродействием без применения нейронных сетей

Можно поподробней на этом моменте? Какие алгоритмы и библиотеки использовали?

Мне казалось что обычно используют OpenCV под подобные цели.

OpenCV для работы с RTSP потоком использует FFmpeg. К тому же встроенный в OpenCV FFmpeg без аппаратного ускорения.
Sign up to leave a comment.

Articles