NVIDIA provides software API and libraries for programming NVDEC. The software API, hereafter referred to as NVDECODE API lets developers access the video decoding features of NVDEC and interoperate NVDEC with other engines on the GPU.
NVDEC decodes the compressed video streams and copies the resulting YUV frames to video memory. With frames in video memory, video post processing can be done using CUDA. The NVDECODE API also provides CUDA-optimized implementation of commonly used post-processing operations such as scaling, cropping, aspect ratio conversion, de-interlacing and color space conversion to many popular output video formats. The client can choose to use the CUDA-optimized implementations provided by the NVDECODE API for these post-processing steps or choose to implement their own post-processing on the decoded output frames.
Decoded video frames can be presented to the display with graphics interoperability for video playback, passed directly to a dedicated hardware encoder (NVENC) for high-performance video transcoding, used for GPU accelerated inferencing or consumed further by CUDA or CPU-based processing.
Supported Codecs
The codecs supported by NVDECODE API are:
Refer to Chapter 2 for complete details about the video capabilities for various GPUs.
Video Decoder Capabilities
Table 1 shows the codec support and capabilities of the hardware video decoder for each GPU architecture.
Table 1. Hardware Video Decoder Capabilities
GPU Architecture
MPEG-1 & MPEG-2
VC-1 & MPEG-4
H.264/AVCHD
H.265/HEVC
VP8
VP9
AV1
Fermi (GF1xx)
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level 4.1
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Main, Highprofile up to Level4.1
Unsupported
Unsupported
Unsupported
Unsupported
First generation Maxwell (GM10x)
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level5.1
Unsupported
Unsupported
Unsupported
Unsupported
Second generation Maxwell (GM20x, except GM206)
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048 Max bitrate: 60 Mbps
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level5.1
Maximum Resolution: 4096×4096
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level5.1
Maximum Resolution: 4096×2304 Profile: Main profile up to Level5.1 and main10 profile
Maximum Resolution: 4096×4096
Maximum Resolution: 4096×2304 Profile: Profile 0
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level 5.1
Maximum Resolution: 4096×4096 Profile: Main profile up to Level 5.1, main10 and main12 profile
Maximum Resolution: 4096×4096
Maximum Resolution: 4096×4096 Profile: Profile 0
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level 5.1
Maximum Resolution: 8192×8192 Profile: Main profile up to Level 5.1, main10 and main12 profile
Maximum Resolution: 4096×4096 [1]
Maximum Resolution: 8192×8192 [2] Profile: Profile 0, 10-bit and 12-bit decoding
Maximum Resolution: 4080×4080
Maximum Resolution: 2048×1024 & 1024×2048
Maximum Resolution: 4096×4096 Profile: Baseline, Main, High profile up to Level 5.1
Maximum Resolution: 8192×8192 Profile: Main profile up to Level 5.1, main10 and main12 profile
Maximum Resolution: 4096×4096
Maximum Resolution: 8192×8192 Profile: Profile 0, 10-bit and 12-bit decoding
Maximum Resolution: 8192×8192 Profile: Profile 0 upto level 6.0
[1] Supported only on select GP10x GPUs, all Turing GPUs and GA100
[2] VP9 10-bit and 12-bit decoding is supported on select GP10x GPUs, all Turing GPUs and GA100
Video Decoder Pipeline
At a high level the following steps should be followed for decoding any video content using NVDECODEAPI:
The above steps are explained in the rest of the document and demonstrated in the sample application(s) included in the Video Codec SDK package.
Using NVIDIA Video Decoder (NVDECODE API)
The following sections in this chapter explain the flow that should be followed to accelerate decoding using NVDECODE API.
Video Parser
Creating a parser
Parsing the packets
The decoded result gets associated with a picture-index value in the CUVIDPICPARAMS structure, which is also provided by the parser. This picture index is later used to map the decoded frames to CUDA memory.
Destroying parser
The user needs to call cuvidDestroyVideoParser() to destroy the parser object and free up all the allocated resources.
Video Decoder
Querying decode capabilities
The API cuvidGetDecoderCaps() lets users query the capabilities of underlying hardware video decoder.
As illustrated in Table 1, different GPUs have hardware decoders with different capabilities. Therefore, to ensure your application works on all generations of GPU hardware, it is highly recommended that the application queries the hardware capabilities and makes appropriate decision based on presence/absence of the desired capability/functionality.
The API cuvidGetDecoderCaps() lets users query the capabilities of underlying hardware video decoder. Calling thread should have a valid CUDA context associated.
The following pseudo-code illustrates how to query the capabilities of NVDEC.
Returned parameters from API can be interpreted as below to validate if content can be decoded on underlying hardware:
In most situations, bit-depth and chroma subsampling to be used at the decoder output is same as that at the decoder input (i.e. in the content). In certain cases, however, it may be necessary to have the decoder produce output with bit-depth and chroma subsampling different from that used in the input bitstream. In general, it’s always a good idea to first check if the desired output bit-depth and chroma subsampling format is supported before creating the decoder. This can be done in the following way:
The API cuvidGetDecoderCaps() also returns histogram related capabilities of underlying GPU. Histogram data is collected by NVDEC during the decoding process resulting in zero performance penalty. NVDEC computes the histogram data for only the luma component of decoded output, not on post-processed frame(i.e. when scaling, cropping, etc. applied). In case of AV1 when film gain is enabled, histogram data is collected on the decoded frame prior to the application of the flim grain.
Creating a Decoder
Before creating the decoder instance, user needs to have a valid CUDA context which will be used in the entire decoding process.
The cuvidCreateDecoder() call fills CUvideodecoder with the decoder handle which should be retained till the decode session is active. The handle needs to be passed along with other NVDECODE API calls.
The user can also specify the following parameters in the CUVIDDECODECREATEINFO to control the final output:
The following code demonstrates the setup of decoder in case of scaling, cropping, or aspect ratio conversion.
Decoding the frame/field
After de-muxing and parsing, the client can submit the bitstream which contains a frame or field of data to hardware for decoding. To accomplish this the following steps, need to be followed:
Preparing the decoded frame for further processing
The user needs to call cuvidMapVideoFrame() to get the CUDA device pointer and pitch of the output surface that holds the decoded and post-processed frame.
cuvidMapVideoFrame() API takes decode surface index ( nPicIdx ) as input and maps it to one of available output surfaces, post-processes the decoded frame and copy to output surface and returns CUDA device pointer and associated pitch of the output surfaces.
The above operation performed by cuvidMapVideoFrame() is referred to as mapping in this document.
After the user is done with the processing on the frame, cuvidUnmapVideoFrame() must be called to make the output surface available for storing other decoded and post-processed frames.
When using NVIDIA parser from NVDECODE API, the application can implement a producer-consumer queue between decoding thread (as producer) and mapping thread (as consumer). The queue can contain picture indexes (or other unique identifiers) for frames being decoded. Parser can run on decoding thread. Decoding thread can add the picture index to the queue in display callback and return immediately from callback to continue decoding subsequent frames as they become available. On the other side, mapping thread will monitor the queue. If it sees the queue has non-zero length, it will dequeue the entry and call cuvidMapVideoFrame(…) with nPicIdx as the picture index. Decoding thread must ensure to not reuse the corresponding decode picture buffer for storing the decoded output until its entry is consumed and freed by mapping thread.
In multi-instance decoding use-case, NVDEC could be bottleneck so there wouldn’t be significant benefit of calling cuvidMapVideoFrame() and cuvidDecodePicture() on different CPU threads. cuvidDecodePicture() will stall if wait queue on NVDEC inside driver is full. Sample applications in Video Codec SDK are using mapping and decode calls on same CPU thread, for simplicity.
Getting histogram data buffer
Histogram data is collected by NVDEC during the decoding process resulting in zero performance penalty. NVDEC computes the histogram data for only the luma component of decoded output, not on post-processed frame(i.e. when scaling, cropping, etc. applied). In case of AV1 when film gain is enabled, histogram data is collected on the decoded frame prior to the application of the flim grain.
Histogram buffer is mapped to output buffer in driver so cuvidUnmapVideoFrame() does unmap of histogram buffer also along with output surface.
The following code demonstrates how to use cuvidMapVideoFrame() and cuvidUnmapVideoFrame() for accessing histogram buffer.
Querying the decoding status
The NVDECODEAPI currently reports the following statuses:
The API is expected to help in the scenarios where the client needs to take a further decision based on the decoding status of the frame, for e.g. whether to carry out inferencing on the frame or not.
Please note that the NVDEC can detect a limited number of errors depending on the codec. This API is supported for HEVC, H264 and JPEG on Maxwell and above generation GPUs.
Reconfiguring the decoder
Using cuvidReconfigureDecoder() the user can reconfigure the decoder if there is a change in the resolution and/or post processing parameters of the bitstream without having to destroy the ongoing decoder instance, and create a new one thereby saving time (and latency) in the process.
In the earlier SDKs the user had to destroy the existing decoder instance and create a new decoder instance for handling any change in decoder resolution or post processing parameters (like scaling ratio, cropping dimensions etc.).
The API can be used in scenarios where the bitstream undergoes changes in resolution, for e.g. when the encoder (on server side) changes image resolution frequently to adhere to Quality of Service(QoS) constraints.
The API is supported for all codecs supported by NVDECODEAPI.
Destroying the decoder
The user needs to call cuvidDestroyDecoder() to destroy the decoder session and free up all the allocated decoder resources.
Writing an Efficient Decode Application
The NVDEC engine on NVIDIA GPUs is a dedicated hardware block, which decodes the input video bitstream in supported formats. A typical video decode application broadly consists of the following stages:
Of these, de-muxing and parsing are not hardware accelerated and therefore outside the scope of this document. The de-muxing can be performed using third party components such as FFmpeg, which provides support for many multiplexed video formats. The sample applications included in the SDK demonstrate de-muxing using FFmpeg.
Similarly, post-decode or video post-processing (such as scaling, color space conversion, noise reduction, color enhancement etc.) can be effectively performed using user-defined CUDA kernels.
The post-processed frames can then be sent to the display engine for displaying on the screen, if required. Note that this operation is outside the scope of NVDECODE APIs.
An optimized implementation should use independent threads for de-muxing, parsing, bitstream decode and processing etc. as explained below:
The NVDEC driver internally maintains a queue of 4 frames for efficient pipelining of operations. Please note that this pipeline does not imply any decoding delay for decoding. The decoding starts as soon as the first frame is queued, but the application can continue queuing up input frames so long as space is available without stalling. Typically, by the time application has queued 2-3 frames, decoding of the first frame is complete and the pipeline continues. This pipeline ensures that the hardware decoder is utilized to the maximum extent possible.
In the use cases where there is frequent change of decode resolution and/or post processing parameters, it is recommended to use cuvidReconfigureDecoder() instead of destroying the existing decoder instance and recreating a new one.
The following steps should be followed for optimizing video memory usage:
The sample applications included with the Video Codec SDK are written to demonstrate the functionality of various APIs, but they may not be fully optimized. Hence programmers are strongly encouraged to ensure that their application is well-designed, with various stages in the decode-postprocess-display pipeline structured in an efficient manner to achieve desired performance and memory consumption.
Notices
Notice
This document is provided for information purposes only and shall not be regarded as a warranty of a certain functionality, condition, or quality of a product. NVIDIA Corporation (“NVIDIA”) makes no representations or warranties, expressed or implied, as to the accuracy or completeness of the information contained in this document and assumes no responsibility for any errors contained herein. NVIDIA shall have no liability for the consequences or use of such information or for any infringement of patents or other rights of third parties that may result from its use. This document is not a commitment to develop, release, or deliver any Material (defined below), code, or functionality.
NVIDIA reserves the right to make corrections, modifications, enhancements, improvements, and any other changes to this document, at any time without notice.
Customer should obtain the latest relevant information before placing orders and should verify that such information is current and complete.
NVIDIA products are sold subject to the NVIDIA standard terms and conditions of sale supplied at the time of order acknowledgment, unless otherwise agreed in an individual sales agreement signed by authorized representatives of NVIDIA and customer (“Terms of Sale”). NVIDIA hereby expressly objects to applying any customer general terms and conditions with regards to the purchase of the NVIDIA product referenced in this document. No contractual obligations are formed either directly or indirectly by this document.
NVIDIA products are not designed, authorized, or warranted to be suitable for use in medical, military, aircraft, space, or life support equipment, nor in applications where failure or malfunction of the NVIDIA product can reasonably be expected to result in personal injury, death, or property or environmental damage. NVIDIA accepts no liability for inclusion and/or use of NVIDIA products in such equipment or applications and therefore such inclusion and/or use is at customer’s own risk.
NVIDIA makes no representation or warranty that products based on this document will be suitable for any specified use. Testing of all parameters of each product is not necessarily performed by NVIDIA. It is customer’s sole responsibility to evaluate and determine the applicability of any information contained in this document, ensure the product is suitable and fit for the application planned by customer, and perform the necessary testing for the application in order to avoid a default of the application or the product. Weaknesses in customer’s product designs may affect the quality and reliability of the NVIDIA product and may result in additional or different conditions and/or requirements beyond those contained in this document. NVIDIA accepts no liability related to any default, damage, costs, or problem which may be based on or attributable to: (i) the use of the NVIDIA product in any manner that is contrary to this document or (ii) customer product designs.
Trademarks
NVIDIA, the NVIDIA logo, and cuBLAS, CUDA, CUDA Toolkit, cuDNN, DALI, DIGITS, DGX, DGX-1, DGX-2, DGX Station, DLProf, GPU, Jetson, Kepler, Maxwell, NCCL, Nsight Compute, Nsight Systems, NVCaffe, NVIDIA Deep Learning SDK, NVIDIA Developer Program, NVIDIA GPU Cloud, NVLink, NVSHMEM, PerfWorks, Pascal, SDK Manager, Tegra, TensorRT, TensorRT Inference Server, Tesla, TF-TRT, Triton Inference Server, Turing, and Volta are trademarks and/or registered trademarks of NVIDIA Corporation in the United States and other countries. Other company and product names may be trademarks of the respective companies with which they are associated.
Оригинал (английский):https://trac.ffmpeg.org/wiki/HWAccelIntro Многие платформы предоставляют доступ к выделенному оборудованию для выполнения ряда задач, связанных с видео. Использование такого оборудования позволяет выполнять некоторые операции, такие как декодирование, кодирование или фильтрация, быстрее или использовать меньше других ресурсов (особенно ЦП), но может давать другие или плохие результаты или применяться только при использовании программного обеспечения. Дополнительные ограничения, которых в то время не было. На платформах, подобных ПК, видеооборудование обычно интегрировано в графический процессор (от AMD, Intel или NVIDIA), тогда как на мобильных платформах типа SoC это обычно независимое IP-ядро (от многих разных поставщиков).
Аппаратные кодировщики обычно обеспечивают качество вывода, которое значительно ниже, чем программные кодировщики, такие как x264, но они обычно быстрее и имеют низкие ресурсы ЦП. (То есть им нужна более высокая скорость передачи данных, чтобы вывод имел такое же качество восприятия, или они выводят с той же скоростью передачи данных с более низким качеством восприятия.)
Системы с возможностями декодирования и / или кодирования также могут предоставлять доступ к другим соответствующим функциям фильтрации. Обычные вещи, такие как масштабирование и прогрессивная развертка, другая пост-обработка, могут зависеть от системы. Когда аппаратная поверхность доступна, эти фильтры обычно действуют на них вместо обычных кадров в системной памяти.
Доступно множество различных стандартных API состояний. FFmpeg предоставляет доступ ко многим из них и предоставляет различную поддержку.
1. Доступность API платформы
2. Статус реализации API FFmpeg
Использование с инструментом командной строки ffmpeg
3.VDPAU
Обратите внимание, что VDPAU не может использоваться для декодирования кадров в памяти.Сжатый кадр отправляется libavcodec на устройство GPU, поддерживаемое VDPAU, а затем к декодированному изображению можно получить доступ с помощью API VDPAU. Это не выполняется автоматически FFmpeg, но должно выполняться на уровне приложения (проверьте, например, do ffmpeg_vdpau.c, используя файл ffmpeg.c). Также обратите внимание, что декодированный кадр нельзя переместить обратно в ОЗУ с помощью этого API, например, если вам нужно снова закодировать декодированный кадр (например, при перекодировании на сервере).
В настоящее время несколько декодеров поддерживаются VDPAU в libavcodec, особенно H.264, MPEG-1/2/4 и VC-1.
4.VAAPI
Его можно использовать для доступа к оборудованию Quick Sync в графическом процессоре Intel и оборудованию UVD / VCE в графическом процессоре AMD. См. VAAPI.
5.DXVA2
В настоящее время поддерживаются несколько декодеров, особенно H.264, MPEG-2, VC-1 и WMV 3.
Аппаратное ускорение DXVA2 доступно только для Windows. Чтобы создать FFmpeg, поддерживающий DXVA2, вам необходимо установить файл заголовка dxva2api.h. Для MinGW это можно сделать, загрузив заголовок, хранящийся в VLC, и (установив его во включаемом патче, например / usr / include /).
Чтобы включить DXVA2, используйте переключатель конфигурации –enable-dxva2 ffmpeg.
Чтобы проверить декодирование, используйте следующую команду:
6.VideoToolbox
https://developer.apple.com/documentation/videotoolbox VideoToolbox, поддерживается только в MacOS. Декодирование H.264 доступно в FFmpeg / libavcodec.
7.NVENC / NVDEC
NVENC
NVENC можно использовать для кодирования H.264 и HEVC. FFmpeg поддерживает NVENC через кодировщики h264_nvenc и hevc_nvenc. Чтобы включить его в FFmpeg, вам необходимо:
Один поддерживает GPU Драйвер, поддерживающий вашу операционную систему. в SDK кодека NVIDIA
Это означает, что перед компиляцией ffmpeg должно быть достаточно выполнить следующее:
После компиляции вы можете использовать NVENC.
Примечание. Если вы обнаружите ошибку устройства без функции NVENC, убедитесь, что вы используете поддерживаемый формат пикселей для кодирования. См. Приведенную выше информацию о кодировщике.
NVDEC / CUVID
NVDEC предоставляет декодеры для H.264, HEVC, MJPEG, MPEG-1/2/4, VP8 / VP9, VC-1. Кодек поддерживает аппаратные изменения (см. Таблицу совместимости графических процессоров).
Обратите внимание, что FFmpeg предоставляет hwaccel NVDEC и CUVID. То, как они декодируются и пересылаются в кадре, зависит от памяти.
Полный набор кодеков доступен только на оборудовании Pascal, он добавляет поддержку VP9 и 10-бит. Утверждение о том, что в NVENC отсутствует ffnvcodec, также относится к NVDEC.
Используйте NVDEC для демонстрации декодирования:
Используйте CUVID для демонстрации декодирования:
Полное аппаратное перекодирование CUVID и NVENC:
Если ffmpeg скомпилирован и поддерживается libnpp, вы можете использовать его для вставки масштабатора на основе графического процессора в цепочку:
8.libmfx
9.OpenCL
OpenCL может взаимодействовать с другими API-интерфейсами графического процессора, чтобы избежать дублирования копий между графическим процессором и памятью процессора. Поддерживаемые методы:
10.AMD UVD / VCE
AMD UVD можно использовать для декодирования через VDPAU и VAAPI в Mesa в Linux. VCE также имеет некоторую предварительную поддержку кодирования через VAAPI, но ее следует считать экспериментальной.
В Windows к UVD можно получить доступ через стандартный DXVA2 / D3D11VA API, а VCE поддерживается через AMF.
11. Внешние ресурсы
Два, оборудование: VAAPI
1. Поддержка платформы
Intel / i965
AMD / Mesa
Драйвер Mesa VAAPI использует оборудование UVD (Unified Video Decoder) и VCE (Video Encoding Engine) во всех новейших видеокартах AMD и APU.
Все графические процессоры GCN (начиная с Южных островов) поддерживают декодирование H.264, MPEG-2, MPEG-4 Part 2 и VC-1. В GCN 3 (вулканический остров) и H.265 10 бит добавлена поддержка H.265 вместе с GCN 4 (арктические острова). Он может поддерживать или не поддерживать старые графические процессоры.
По умолчанию MPEG-4 Part 2 отключен из-за ограничений VAAPI (основной драйвер Intel никогда не реализовывал его, поэтому он не подвергался особому тестированию). Установите для переменной среды VAAPI_MPEG4_ENABLED значение 1, все равно попробуйте использовать ее.
При кодировании H.264 используется графический процессор GCN, но он еще не завершен. У Mesa пока нет других кодеков, поддерживающих кодирование.
Из-за расположения данных в памяти графического процессора поддержка кодирования и чересстрочной развертки в Mesa несовместима. По умолчанию кадры разделены на поля, и чересстрочное видео поддерживается, но кодирование не поддерживается. Установите для переменной среды VAAPI_DISABLE_INTERLACE значение 1, чтобы иметь возможность использовать кодировщик (но без поддержки чересстрочного видео).
2. Выбор оборудования
Если у вас есть несколько устройств, доступных на одном компьютере (например, интегрированный графический процессор Intel и дискретная графика AMD), вы можете использовать их одновременно для декодирования разных потоков:
(См. Подробнее об этих вариантах).
Такое поведение эквивалентно:
3.Surface Formats
Аппаратный кодек, используемый VAAPI, не может получить доступ к данным кадра в произвольной памяти. Следовательно, перед использованием все данные кадра необходимо выгрузить на аппаратную поверхность, подключенную к соответствующему устройству. Все аппаратные поверхности VAAPI в ffmpeg представлены vaapi pixfmt (но внутренняя структура здесь не видна).
Декодер hwaccel обычно выводит кадры в соответствующем аппаратном формате, но по умолчанию утилита ffmpeg загружает выходные кадры в обычную память перед их передачей следующему компоненту. Это позволяет декодеру быстрее декодировать без каких-либо других опций:
Например, только декодировать и ничего не делать с результатом:
Это можно использовать только для проверки скорости / использования процессора декодером (операции загрузки обычно добавляют много дополнительных накладных расходов).
Например, используя чересстрочный ввод, декодирование, деинтерлейсинг, масштабирование до 720p, загрузку в обычную память и кодирование с помощью libx264:
4. Кодирование
Поэтому, чтобы использовать декодер по умолчанию для некоторых входов, затем загрузите кадр в VAAPI и закодируйте с использованием H.264 и настроек по умолчанию:
Если известно, что ввод можно декодировать аппаратно, мы можем использовать hwaccel:
Наконец, когда ввод может быть или не может быть аппаратно декодируемым, мы можем сделать это:
Это связано с тем, что декодер будет выводить поверхность vaapi (если доступен hwaccel) или программный фрейм (если недоступен). В первом случае он соответствует формату vaapi, а hwupload ничего не делает (не меняется через аппаратный фрейм). Во втором случае он соответствует формату nv12 и преобразует ввод в этот формат, а затем выгружает. Однако в зависимости от выбранного пути производительность может сильно различаться.
кодирование
API
H.262 / MPEG-2, часть 2
mpeg2_vaapi
H.264 / MPEG-4, часть 10 (AVC)
h264_vaapi
H.265 / MPEG-H, часть 2 (HEVC)
hevc_vaapi
MJPEG / JPEG
mjpeg_vaapi
VP8
vp8_vaapi
VP9
vp9_vaapi
Описание параметров кодека см. В 。
5. Параметры отображения из libx264
Нет поддержки двухканального кодирования, и возможно только локальное управление скоростью с прогнозированием. Режим VBR должен довольно хорошо приближаться к общему целевому битрейту, но если сложность изменится, качество в потоке значительно изменится.
Три, аппаратное обеспечение / QuickSync
Оригинал (английский):https://trac.ffmpeg.org/wiki/Hardware/QuickSync Предупреждение. Не устанавливайте Intel Media SDK, если не знаете, что вам нужно, особенно в Linux. Во многих случаях он вам не нужен, и попытка его использовать может сломать другие вещи.
1. Аппаратная поддержка
2. Поддержка API
Доступ к оборудованию можно получить через множество различных API:
DXVA2 / D3D11VA Это стандартные API Windows, реализованные графическим драйвером Intel для поддержки декодирования видео.
libmfx on Linux Это библиотека Intel, которую можно установить как часть Intel Media SDK и которая поддерживает подмножество вариантов кодирования и декодирования.
libmfx on Windows Это библиотека, поставляемая с графическим драйвером Intel и поддерживающая все случаи кодирования и декодирования.
Media Foundation Другой Windows API, поддерживающий некоторые варианты кодирования и декодирования с помощью графического драйвера Intel. ffmpeg не поддерживает.
VAAPI with i965 driver Это основной бесплатный драйвер структуры libva / VAAPI. Большинство дистрибутивов Linux его упаковывают.
VAAPI with iHD driver Серверная часть libmfx в Linux использует модифицированные драйверы libva и VAAPI; это также может использоваться непосредственно пользователем.
3.Linux
Вы можете установить Media Server Studio из двоичного файла https://software.intel.com/en-us/intel-media-server-studio/. Однако Media Server Studio поддерживает только ограниченные HW-платформы и дистрибутивы Linux. Весь медиа-стек с открытым исходным кодом обеспечивает более широкий спектр аппаратных платформ и поддерживаемых дистрибутивов Linux.
Intel open source media stack
Название проекта: Поддерживаемая графика поколения
Open Source Repo
MSDK: gen9 +
https://github.com/Intel-Media-SDK/MediaSDK
Libva: GEN5 +
https://github.com/intel/libva
Драйвер i965: gen5
gen9.5
https://github.com/intel/intel-vaapi-driver
Драйвер iHD: gen9 +
https://github.com/intel/media-driver
VAAPI VS libmfx
По возможности настоятельно рекомендуется использовать VAAPI с драйвером i965. Если ваш вариант использования требует определенного набора функций, используйте только libmfx.
4.Windows
MSDK версии для Windows можно получить изhttps://software.intel.com/media-sdk
5. Беги
VAAPI
libmfx
Библиотека имеет большое количество опций на выбор, а возможные допустимые значения зависят от версии и оборудования. libavcodec пытается разумно сопоставить общие параметры с параметрами libmfx, но отображение грубое и ошибочное, особенно в отношении управления скоростью.
Использование недопустимой комбинации может вызвать сообщение: «Выбранный режим управления скоростью не поддерживается во время выполнения QSV. Выберите другой режим». Обычно это сообщение является точным, но оно также может относиться к другим проблемам, таким как отсутствие доступного оборудования.
6. Установите Media SDK в Linux.
Обратите внимание, что требуются как исправления ядра, так и модифицированные системные библиотеки. Рекомендуется не устанавливать его на машину, которая также используется для других целей, потому что она не использует обычный механизм распространения и может быть случайно повреждена / уничтожена другими программными пакетами.
Целевая машина: Убедитесь, что на целевом компьютере есть поддерживаемый ЦП. Текущая версия поддерживает только графику Gen8 / Gen9 на дорогих процессорах (марки «Xeon» / «Core i»). Те же графические ядра на более дешевых процессорах (марки Pentium / Celeron / Atom) явно отключены, возможно, по коммерческим причинам. получить чистую версию поддерживаемой версии ядра (в настоящее время 4.4: ) и примените предоставленный патч. Сборка и установка. Создайте и установите предоставленные деревья libva и libdrm. Запустите сценарий установки Media SDK, чтобы установить проприетарные компоненты. Перезагрузите.
