Посмотрите карты в любом крупном городе их полно. Так же можно заряжаться от любой розетки, как правило владельцы так и поступают. Главный вопрос в пробеге от одной зарядке, особенно зимой.
Так ходите по проверенным сайтам или поставьте антивирус. Это для Windows, перейдите на Linux и вирусов меньше. А вообще сейчас полноценные ПК с Windows за 40 — 80 баксов позволяют решать повседневные задачи. Есть ноутбуки менее 150 баксов. И это все новое. Да, 32 ГБайта мало, но это в полне минимально достаточный объем для офисной работы.
Спасибо, за информацию по перезаписи из оперативной памяти в оперативную память.
Но декодированный кадр после DXVA2 я получаю в uncacheable speculative write combining (USWC). Память USWC очень медленно читается (раз в 20 медленней). ATOM с этой перезаписью плохо справляется (проверено на VLC). Для ускорения используются инструкции SSE4, как написано в статье.
Нет, очень серьезно. Я занимаюсь обработкой в Реал-Тайм. Работа с основной памяти занимает 100-150 тактов машинного времени (я же привел ссылку https://habr.com/ru/company/otus/blog/343566/). А по вашему на тактовой частоте процессора могу считывать и записывать 1 байт информации в основную память? Можете привести пример кода перезаписи 100 МБайт за 31*2 = 62 мс?
В коде, за спойлером (C++ перевод из NV12 в RGB) действительно не освобождался buff, чисто случайно вышло при удалении комментария. И я практически не применяю перевода NV12 в RGB. Этот пример демонстрирует работу с NV12 напрямую.
В кодах и dll утечек памяти нет, проверено на продолжительной работе.
(YUV->RGB, например конвертится в шейдере, бесплатный ресайз, кроп и т.д)
Мне это не нужно. Цель не проигрыватель (их много, можно и VLC использовать, он еще меньше загружает ЦП, чем FFmpeg). Мне нужно получить кадр в памяти, запустить на одно из ядер для обработки алгоритмами компьютерного зрения, согласовать последовательность кадров (так как кадры могут обрабатываться за разное время) и результат отобразить на экране.
ffmpeg_hw и был взят за основу. Но у меня другая задача, мне нужно не просто отобразить кадры на экране, а держать в памяти до 4-х кадров для их обработки. Если бы у меня был 24-ядерный процессор, я бы держал 24 кадра в памяти, и для обработки одного кадра у меня было бы 40мс х 24 = 960 мс. А сейчас мне необходимо обработать 1 кадр за 160 мс.
Отображение кадра у меня это не основное, кстати, а чем плох GDI? Кроме того, что SDL кроссплатформенный, а GDI только под Windows.
1. А зачем переводить NV12 в RGB? В статье я написал почему я этого не делаю, хотя такая возможность имеется.
2. Я пишу на ATOM Z8350, какое там CUDA?
3. На OpenCL можно перевести в RGB, но какой в этом смысл вместо 3 МБайт(NV12), нужно переписать 6 МБайт(RGB)?
Читал, что 5 Мп матрица еще хуже чем 8Мп. Просто смысл, цена такого решения не низкая, если сравнить с ценой камеры IP Atis, то что на фото 50 баксов. Клиенту — это решение сложно поставить.
У меня есть камера Raspberry PI 8MP. Но честно нет идей, как ее можно применить, т.к. она коротко фокусная и ее необходимо приближать к объекту.
Пробовал на основе нее сделать сканер штрих-кода. Но если нет очень хорошего освещения прочитать штрих-код невозможно. Матрица никакая:(
4500 руб это где то 70 баксов (без корпуса)
За 10 баксов можно купить приличную вебку и разница явно не в разы:) А серьезную обработку на Raspberry PI real-time не сделать. Ну это мое мнение.
Ну не в 3-е дешевле это точно. Я купил за 82 бакса с бесплатной доставкой. Распберри стоит 35+доставка+корпус+блок питания+SD-карта+радиатор. Z83II это все имеет + 2Гб оперативной памяти + Windows10 (бесплатная лицензия на 1 пользователя) + 2 кабеля HDMI (длинный и короткий) + крепление к телевизору/монитору. И мой взгляд для компьютерного зрения Raspberry PI слабоват.
Но декодированный кадр после DXVA2 я получаю в uncacheable speculative write combining (USWC). Память USWC очень медленно читается (раз в 20 медленней). ATOM с этой перезаписью плохо справляется (проверено на VLC). Для ускорения используются инструкции SSE4, как написано в статье.
А как Вы побороли задержки по воспроизведению rtsp в ffplay? Я пробовал только вначале на Pentium'е было секунды 3, что на мой взгляд не приемлемо.
Нет, очень серьезно. Я занимаюсь обработкой в Реал-Тайм. Работа с основной памяти занимает 100-150 тактов машинного времени (я же привел ссылку https://habr.com/ru/company/otus/blog/343566/). А по вашему на тактовой частоте процессора могу считывать и записывать 1 байт информации в основную память? Можете привести пример кода перезаписи 100 МБайт за 31*2 = 62 мс?
Считаю 25.6/8=3.2 ГБайт в секунду. А зачем тогда нужен кеш 1,2 и 3 уровня???
P.S. https://habr.com/ru/company/otus/blog/343566/
В кодах и dll утечек памяти нет, проверено на продолжительной работе.
Мне это не нужно. Цель не проигрыватель (их много, можно и VLC использовать, он еще меньше загружает ЦП, чем FFmpeg). Мне нужно получить кадр в памяти, запустить на одно из ядер для обработки алгоритмами компьютерного зрения, согласовать последовательность кадров (так как кадры могут обрабатываться за разное время) и результат отобразить на экране.
Отображение кадра у меня это не основное, кстати, а чем плох GDI? Кроме того, что SDL кроссплатформенный, а GDI только под Windows.
2. Я пишу на ATOM Z8350, какое там CUDA?
3. На OpenCL можно перевести в RGB, но какой в этом смысл вместо 3 МБайт(NV12), нужно переписать 6 МБайт(RGB)?
Пробовал на основе нее сделать сканер штрих-кода. Но если нет очень хорошего освещения прочитать штрих-код невозможно. Матрица никакая:(
За 10 баксов можно купить приличную вебку и разница явно не в разы:) А серьезную обработку на Raspberry PI real-time не сделать. Ну это мое мнение.