Оптимизация кодирования MediaFoundation h264

Question

Я пишу приложение для захвата экрана, использующее UWP Screen Capture API .

В результате я получаю обратный вызов для каждого кадра с ID3D11Texture2D с целевым экраномили изображение приложения, которое я хочу использовать в качестве входных данных для SinkWriter MediaFoundation для создания файла контейнера h264 в mp4.

Есть две проблемы, с которыми я сталкиваюсь:

• Текстура неПроцессор считывается и пытается отобразить его неудачно
• Текстура имеет отступ (шаг изображения> ширина пикселя * размер формата пикселя), я полагаю

Чтобы решить их, мой подход заключается в:

• Используйте ID3D11DeviceContext::CopyResource, чтобы скопировать исходную текстуру в новую, созданную с D3D11_USAGE_STAGING и D3D11_CPU_ACCESS_READ flags
• Поскольку эта текстура тоже имеетзаполнение, создайте буфер IMFMediaBuffer, оборачивая его MFCreateDXGISurfaceBuffer, приведите его к IMF2DBuffer и используйте IMF2DBuffer::ContiguousCopyTo к другому IMFMediaBuffer, который я создаю с MFCreateMemoryBuffer

Так что я в основном копирую каждый кадр два раза, один разe GPU и один раз на CPU, который работает, но кажется неэффективным.

Как лучше это сделать?Является ли MediaFoundation достаточно умным, чтобы справляться с входными кадрами, которые имеют отступы?

Answer 1

Неэффективность возникает из-за вашей попытки Map вместо того, чтобы использовать текстуру в качестве входного видеокодера.Кодер MF H.264, который в большинстве случаев является аппаратным кодером, может воспринимать текстуры, поддерживаемые видеопамятью, в качестве прямого ввода, и это именно то, что вы хотите сделать (соответственно настройте кодер - см. Диспетчеры устройств D3D / DXGI).

Заполнение не относится к текстурным фреймам.В случае заполнения в кадрах с традиционными данными системной памяти примитивы Media Foundation обычно способны обрабатывать данные с заполнением: Image Stride и MF_MT_DEFAULT_STRIDE и другие атрибуты формата видео.