FFmpeg практика аппаратного декодирования DXVA2

1. А зачем переводить NV12 в RGB? В статье я написал почему я этого не делаю, хотя такая возможность имеется.
2. Я пишу на ATOM Z8350, какое там CUDA?
3. На OpenCL можно перевести в RGB, но какой в этом смысл вместо 3 МБайт(NV12), нужно переписать 6 МБайт(RGB)?

ffmpeg_hw и был взят за основу. Но у меня другая задача, мне нужно не просто отобразить кадры на экране, а держать в памяти до 4-х кадров для их обработки. Если бы у меня был 24-ядерный процессор, я бы держал 24 кадра в памяти, и для обработки одного кадра у меня было бы 40мс х 24 = 960 мс. А сейчас мне необходимо обработать 1 кадр за 160 мс.
Отображение кадра у меня это не основное, кстати, а чем плох GDI? Кроме того, что SDL кроссплатформенный, а GDI только под Windows.

А еще лучше ffplay

А как Вы побороли задержки по воспроизведению rtsp в ffplay? Я пробовал только вначале на Pentium'е было секунды 3, что на мой взгляд не приемлемо.

В коде, за спойлером (C++ перевод из NV12 в RGB) действительно не освобождался buff, чисто случайно вышло при удалении комментария. И я практически не применяю перевода NV12 в RGB. Этот пример демонстрирует работу с NV12 напрямую.
В кодах и dll утечек памяти нет, проверено на продолжительной работе.

Про swscale я писал в предыдущей статье, там есть пример. Но чем плохо работать с NV12 напрямую? Я делаю так для минимизации загрузки процессора.

Обработка ошибок в коде dll сделана.

Итого 25.6 Гб/с

Считаю 25.6/8=3.2 ГБайт в секунду. А зачем тогда нужен кеш 1,2 и 3 уровня???
P.S. https://habr.com/ru/company/otus/blog/343566/

А по вашему на тактовой частоте процессора могу считывать и записывать 1 байт информации в основную память? Можете привести пример кода перезаписи 100 МБайт за 31*2 = 62 мс?

Не понял вашу мысль. Сильно упрощённо, процесс чтения из памяти происходит так:
У процессора есть инструкция чтения из памяти. Грубо говоря, ReadWord. Принимает указатель, кладёт содержимое памяти в регистр.
Есть контроллер DMA, который:

1. принимает череду таких команд ReadWord
2. преобразует их в набор запросов на чтение согласно спеки интерфейса шины памяти

При этом используются оптимизационные техники, такие как address coalescing (множество мелких чтений преобразуются в один длинных запрос DMA) и прочие.

Этот процесс, как правило, асинхронный (пока приходят новые данные, процессор делает вычисления над тем, что уже прочёл). Такая техника (latency hiding) лежит в основе высокой производительности GPU, например. Если процесс асинхронный, то частота процессора влияет только на то, как много запросов в единицу времени он генерирует.

Таким образом, процесс чтения и записи в память можно рассматривать как схему «производитель — потребитель», где производителем является процессор (генерирует запросы ReadWord), а потребителем — контроллер памяти, который эти запросы читает, оптимизирует и выполняет.

В реальной жизни всё сложнее, контроллеры DMA могут выполнять много всякой разной работы — например, транспонировать маленькие матрицы на лету, чтобы процессор читал столбцы кусочков изображений в векторные регистры. Могут преобразовывать цветовые пространства и ещё много чего.

Можете привести пример кода перезаписи 100 МБайт за 31*2 = 62 мс?

#include <iostream>
#include <algorithm>
#include <chrono>
#include <vector>

using namespace std;
using namespace chrono;

// 1024 * 1024 elements;
static const size_t numElems = 1048576UL;

int main()
{
	vector<int> src(numElems), dst(numElems);
	vector<double> bandwidth;
	const size_t vectorSize = src.size() * sizeof(src.front());

	for (int numLaps = 0; numLaps < 1024; numLaps++) {
		void* const source = src.data();
		void* destination = dst.data();
		auto start = system_clock::now();
		memcpy(destination, source, vectorSize);
		auto end = system_clock::now();
		auto time = duration_cast<microseconds>(end - start).count();
		auto bw = double(vectorSize) / double(time);
		
		cout << bw << " megabytes / s" << endl;
		bandwidth.push_back(bw);
	}

	double acc = 0;
	for (auto bw : bandwidth) {
		acc += bw;
	}

	acc = acc / bandwidth.size();
	cout << "Avg bandwidth: " << acc << " megabytes / s" << endl;

	return 0;
}

Выдаёт чуть меньше 7 Гбайт/с на моей машине. Это примерно те 75Мб/с, умноженные на 100, о которых я говорил в первом комментарии. Машина вот такая: VS 2019, Core i7-7770, DDR4 (не знаю частоту, скорее всего 2133). У вас на Atom'е будет меньше. Но не на порядок.

Весь смысл в HW-acceleration'е декодирования видео — в том, чтобы не гонять декодированный кадр обратно в RAM, а держать в памяти GPU для последующего показа.

Как только вы пытаетесь скачать его обратно — начинаются проблемы. Задержка на получение кадра и его передачу обратно в RAM в принципе может убить весь выигрыш по скорости. Если вы делаете пост-обработку кадра после декодирования, делайте её на шейдерах / OpenCL.

На вашем месте, я бы начал с замера производительности декодирования Н.264 на одном ядре Atom'а на свежей сборке libx264 из исходников со всеми оптимизациями. Есть немалый шанс, что декодирование не будет bottleneck'ом.

ATOM с этой перезаписью плохо справляется (проверено на VLC). Для ускорения используются инструкции SSE4, как написано в статье.

У вас система с общей памятью. Никаких перезаписей вообще делать не нужно, только выделение на стороне GPU с последующим отображением в память CPU. Посмотрите в сторону habr.com/ru/post/215359