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

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

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

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

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

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

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

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

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


h.264 video-encoding ms-media-foundation screen-capture direct3d11
person Alberto    schedule 10.07.2019    source источник
comment
Вы можете проверить этот вопрос и ответы (c #, но, тем не менее, хорошее объяснение) для получения подробной информации о том, как реализовать аппаратное кодирование h264, которое будет напрямую использовать вашу текстуру в качестве входных данных (как предложил Роман): stackoverflow.com/questions/44402898/   -  person VuVirt    schedule 17.07.2019

Ответы (1)


arrow_upward
0
arrow_downward

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

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

person Roman R.    schedule 10.07.2019