Working with video
Visual Studio
Comments 32
0
Ох, а почему бы не посмотреть в сторону gstreamer? Я как раз с ним работаю. Там такие вещи гораздо проще делаются. Делаете AppSink и принимаете уже готовые декодированные фоеймы прямо с потока. В добавок есть шина сообщений от всех элементов. В общем — рекомендую попробовать.
+1
Основная причина использования FFmpeg — это аппаратное декодирование. О нем я напишу в следующей статье. Декодирование dxva2 на Intel Atom Z8350 + возвращение каждого кадра в оперативную память + вывод на экран средствами WinApi занимает около 15%. Что на мой взгляд не плохо.
gstreamer — имеет поддержку dxva2? Позволяет он малыми ресурсами переписывать кадр в оперативную память средствами SSE4?
Я начинал с VLC, он позволяет сделать видеопроигрыватель буквально в 10 строк кода. Загрузка процессора около 5%. Но возврат кадров в оперативную память загружает процессор под 50%. Тогда программный декодер FFmpeg в среднем загружает процессор меньше.
Причина кадр FullHD в NV12 занимает почти 3 МБайта, т.е. 75 МБайт в секунду нужно переписывать.
0
А почему на Cherry Trail HD Graphics не qsv, а dxva2? Камень, вроде, позволяет. У меня малинка спокойно RTSP 1920p 25fps декодит по mmal льет и на диск и в текстуру.
И avcodec_decode_video2 давно deprecated и av_dict_set(&videoOptions, «threads», «auto», 0) хорошо бы на многоядерном камне
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 пропал. Разница в цене не принципиальна, размеры не на много больше, ток потребления аналогичен, но вычислительные возможности намного выше.
0
Аппаратная камера и возможность лить прямо в EGL текстуру на малинке рулят. Под интеловскую графику в линукс я так и не смог получить EGLый контекст, а необходимость memcpy в текстуру, несмотря, даже на dma через PBO сводят разницу в производительности CPU к нулю, что и подтверждает автор
0
Intel — это тоже позволяет. VLC — это хороший пример этого. Загрузка около 5% для Intel ATOM. Т.е. получение потока RTSP + декодирование DXVA2 + вывод на экран.
0
понятно, что позволяет. Вопрос в том, что и решение втрое дешевле позволяет добиться аналогичных результатов. Наличие аппаратной камеры на интел я как-то проглядел. Не подскажете, что к чему?
0
Ну не в 3-е дешевле это точно. Я купил за 82 бакса с бесплатной доставкой. Распберри стоит 35+доставка+корпус+блок питания+SD-карта+радиатор. Z83II это все имеет + 2Гб оперативной памяти + Windows10 (бесплатная лицензия на 1 пользователя) + 2 кабеля HDMI (длинный и короткий) + крепление к телевизору/монитору. И мой взгляд для компьютерного зрения Raspberry PI слабоват.
0
Ну так камера тоже денег стоит. Я имел ввиду, что на основе малинки можно сделать камеру, которая будет решать часть поставленных задач. Цена вопроса 4.5 тр без корпуса
0
4500 руб это где то 70 баксов (без корпуса)
За 10 баксов можно купить приличную вебку и разница явно не в разы:) А серьезную обработку на Raspberry PI real-time не сделать. Ну это мое мнение.
0
У меня есть камера Raspberry PI 8MP. Но честно нет идей, как ее можно применить, т.к. она коротко фокусная и ее необходимо приближать к объекту.
Пробовал на основе нее сделать сканер штрих-кода. Но если нет очень хорошего освещения прочитать штрих-код невозможно. Матрица никакая:(
0
у меня с трансфокатором и ик подсветкой. Трансфокатор, правда ручной. Делал домой IP камеру на ее основе + малина. Льет по RTSP, пишет на SMB шару по движению. 1920p/25. Реалтайм на любой RTSP смотрелке VLС/FFMPEG/на телефоне tinyCam. Архив — на чем угодно по DLNA хоть на телевизоре, хоть на утюге))
0
Читал, что 5 Мп матрица еще хуже чем 8Мп. Просто смысл, цена такого решения не низкая, если сравнить с ценой камеры IP Atis, то что на фото 50 баксов. Клиенту — это решение сложно поставить.
0
Смысл в гибкости. У меня, например, она кидает в телегу, когда дверь открыта. Возможность независимо управлять 2-мя потоками с камеры. Например 1-ый в 1920 отдает в h264 Annex-b непосредственно для RTP, а второй в 640x480 YUV для детектирования движеня ну или, допустим, предварительной обработки для расп. номеров, а потом уже в кодер и, допустим на экран. Все это хозяйство не надо malloc/memcpy, поскольку используются одни и те же буферы. Наличие полноценного EGL, а значит Qt eglfs, без необходимости грузить иксы. Загрузка меньше 4сек.
0

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

0
Да, может, если есть нативные кодеки, то будет их использовать.
0

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


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 у меня работает нестабильно даже по локальной сети

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

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

0
Вам надо декодировать только 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 каждую секунду и не мучать себе мозг.
0
Мне нужно декодировать каждый кадр, обновлять background, появился большой объект и если да искать номерную пластину с номером. Здесь же учебный пример: видно где получен кадр и можно сделать более серьезный обработчик.
P.S. автомобиль со скоростью 60 км/ч за секунду проезжает 16,7 м. Если обрабатывать кадр в секунду, то большая часть автомобилей будет проезжать не замеченной.
0
Мы получили достаточно хорошие результаты в определении российских номеров на статической картинке (до 97%) с неплохим быстродействием без применения нейронных сетей

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

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

0
OpenCV для работы с RTSP потоком использует FFmpeg. К тому же встроенный в OpenCV FFmpeg без аппаратного ускорения.
Only those users with full accounts are able to leave comments. , please.