Many graphics chips haven't been optimized for copying data from GPU memory back to CPU memory. The reason for keeping the decoded video inside GPU memory is efficiency. The video renderer must also support DXVA, which give you a bit less freedom of choice in renderers. There can be no processing filter in between. The DXVA decoder must be connected directly to the video renderer. This brings some limitations with regard to playback. With the native type, the decoded video stays in GPU memory until it has been displayed. The internal DXVA decoders in MPC-HC are native implementations, and ffdshow also offers a native implementation. The LAV video decoder that is included in the pack offers both variants. Almost all implementations are of the native type. Has issues with Blu-ray support in MediaPortal 1 (dropped frames on clip boundaries as DXVA requires video decoder to flush few frames).ĭXVA implementations come in two variants: native and copy-back. DXVA2 (native): Can be used by any hardware that supports DXVA2 (Intel might have some issues with VC1 video).Uses more GPU / memory bandwidth since every video texture is copied back to main RAM after decoding (hence the copy-back in name). DXVA2 (copy-back): Can be used by any hardware that supports DXVA2 (Intel might have some issues with VC1 video).Intel QuickSync: Similar to CUVID, but for Intel's GPU:s.Video frames are decoded with the same hardware as with DXVA on GPU, but the video frames are required to be copied back to system RAM.
NVIDIA CUVID: Nvidia's CUDA based decoder.None: The video will be decoded by CPU, possibly burden it to a level that the result is stuttering video.The LAV Video Decoder supports several hardware decoders: Hardware Acceleration is used to let the GPU decode the video to leave the CPU free to do other things. Detailed configuration for LAV Video Video SettingsĪfter clicking on the screwdriver icon next to the LAV Video Decoder, you'll be presented with the following settings screen:
0 kommentar(er)
