Как я могу визуализировать кадры, декодированные FFmpeg, с использованием аппаратного декодирования с помощью D3D11?

Здесь невозможно дать полный ответ на этот вопрос, но исходный код проигрывателя VLC для Windows с открытым исходным кодом покажет, как это сделать.

Чтобы ответить на ваши вопросы на более высоком уровне:

Какова эквивалентная концепция декодированного кадра в D3D11? Это текстура?

Если использовать полное аппаратное декодирование, то всегда да. Если нет, то это зависит от того, хотите ли вы использовать графический процессор только для преобразования из NV12 в BGRA, что должно произойти на каком-то этапе процесса. Давайте рассмотрим различные сценарии:

Полное аппаратное ускорение

Сначала у вас будет одна текстура графического процессора для текущего выходного кадра в формате пикселей NV12. Каждый декодированный кадр копируется в эту единственную выходную текстуру. Вы накладываете эту выходную текстуру на простой прямоугольник, служащий вашим «экраном», с направленной прямо на него камерой, а также визуализируете и переворачиваете свою цепочку обмена после копирования каждого кадра.

Для преобразования NV12 в BGRA – что необходимо, поскольку AFAIK ваш конечный вывод в окно должен быть цепочкой обмена BGRA – вам затем необходимо применить аппаратный шейдер к выходной текстуре для преобразования из NV12 в BGRA, иначе цвета будут полностью изменены. неправильный. У VLC он есть, но он распространяется под лицензией GPL, поэтому у вас могут возникнуть проблемы, если вы используете его в своем собственном проекте. Однако фактический алгоритм таков, каков он есть, поэтому, если вы можете написать свой собственный шейдер с помощью HSL, вы сможете скопировать математические вычисления, не копируя код. (Изменить - похоже, что в проекте github есть шейдер от Microsoft, лицензированный MIT, поэтому его можно использовать).

Вдобавок ко всему, настройка всей системы декодирования с использованием libav, если вы еще этого не сделали, является кошмаром, и для разрешения менее 4K на современных ПК нет необходимости. Но если вы его используете, вы бы выделили массив текстур, используя CreateTexture2D с DXGI_FORMAT_NV12 форматом пикселей и без доступа к процессору. Выделите несколько десятков (зависит от того, сколько видеопамяти вы хотите сказать вашему плееру). Вы будете хранить эти текстуры и передавать их в декодер через AVD3D11VAContext::surface, и декодер будет декодировать непосредственно в эти текстуры. Затем у вас есть чистые текстуры VRAM в формате NV12, которые вы постоянно копируете в единую выходную текстуру посредством простого копирования текстур VRAM-VRAM, а затем немедленно помещаете обратно в очередь для повторного использования декодером. Обратите внимание, что это работает только с определенными кодеками libav.

Таким образом, при использовании этого метода все все время остается в VRAM, и это, безусловно, самый эффективный способ декодирования видео с помощью libav и D3D11. Но это чрезвычайно сложно и требует очень глубокого погружения в декодирование видео и, в частности, в libav. Любой, кто пытается дать вам здесь совет, кто не заходил в эту конкретную кроличью нору, скорее всего, не знает, о чем говорит.

Нет аппаратного ускорения

Вы говорите, что используете аппаратное декодирование, но я не уверен, что так оно и есть, поэтому я все же хочу потратить секунду на обсуждение альтернативы, поскольку она намного проще. Кадры, предоставленные вам libav, уже находятся в оперативной памяти процессора, хотя все еще в формате NV12, поэтому вам все равно придется в какой-то момент конвертировать их в BGRA. И здесь у вас есть два варианта:

1. Вы можете продолжать использовать выходную текстуру D3D NV12, преобразованную в прямоугольник, как указано выше, используя аппаратный шейдер для преобразования из NV12. Затем для каждого кадра вам придется копировать текстуру кадра в выходную текстуру, что означает копирование из RAM во VRAM, что, как вы, вероятно, знаете, происходит очень медленно.

2. Вы можете делать все, что связано с ЦП/ОЗУ, используя sws_getCachedContext и sws_scale для получения пикселей BGRA. Если вы сделаете это таким образом, вам вообще не понадобится использовать D3D; на этом этапе у вас будут просто необработанные данные BGRA, которые вы сможете скопировать в окно с помощью D2D или даже GDI+.

Поскольку копирование из RAM в VRAM происходит очень медленно, я не могу сказать вам, быстрее ли (1) или (2). Другими словами, преимущества использования графического процессора для преобразования NV12 в BGRA могут быть легко нивелированы медлительностью копирования данных NV12 во VRAM. Так что здесь вам просто придется поэкспериментировать.

Я видел много решений, конвертирующих данные NV12 в RGB, но похоже, что DX11 больше не требует этого преобразования.

Хм. Не уверен, что вы имеете в виду. Да, D3D11 может обрабатывать текстуру NV12 в VRAM или RAM, но конечная выходная поверхность или цепочка обмена всегда должна быть BGRA в Windows AFAIK, поэтому вам придется конвертировать в какой-то момент процесса. Самый эффективный способ сделать это — применить шейдер к выходной текстуре NV12.

Я просто хочу отобразить этот кадр, и, поскольку мой кадр находится на графическом процессоре, есть ли более удобный способ рендеринга непосредственно на графическом процессоре без копирования?

Да, для этого потребуется пойти по пути ускорения. Если ваш кадр находится на графическом процессоре, значит, вы уже используете HA, и если да, то у вас уже должен быть доступ к текстурам DXGI, на которые выводит декодер.

Редактировать: Я просмотрел проект github, на который вы ссылались, и он не использует ffmpeg/libav для декодирования. Текстуры, которые он считывает с диска, уже являются кадрами NV12. Так что это не пример аппаратного декодирования.

Для настоящего аппаратного декодирования снова посмотрите VLC и то, как он использует libav (базовую библиотеку, лежащую в основе ffmpeg) для прямого декодирования в текстуры DXGI.

Проект Github ДЕЙСТВИТЕЛЬНО демонстрирует, как использовать шейдер на текстурах NV12 после их декодирования, включая настройку области просмотра, шейдера и т. д., и это все, что вам также придется сделать. Так что, конечно, это хороший ресурс, но это еще не полдела, когда дело доходит до создания полноценного игрока.