Page tree


Search

  Wiki Navigation

    Loading...


 Recently Updated


 Latest Releases

 MediaPortal 1.23 
            Releasenews | Download
 MediaPortal 2.2.2
            Releasenews | Download

Table of Contents

Overview

Detailed configuration for LAV Video

Video Settings

After clicking on the screwdriver icon next to the LAV Video Decoder, you'll be presented with the following settings screen:

Hardware Acceleration

Hardware Acceleration is used to let the GPU decode the video to leave the CPU free to do other things. The LAV Video Decoder supports several hardware decoders:

  • None: The video will be decoded by CPU, possibly burden it to a level that the result is stuttering video.
  • NVIDIA CUVID: Nvidia's CUDA based decoder. 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.
  • Intel QuickSync: Similar to CUVID, but for Intel's GPU:s.
  • DXVA2 (copy-back): 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 (native): Can be used by any hardware that supports DXVA2 (Intel might have some issues with VC1 video). Has issues with Blu-ray support in MediaPortal 1 (dropped frames on clip boundaries as DXVA requires video decoder to flush few frames).

DXVA2 (native) versus DXVA2 (copy-back)

DXVA implementations come in two variants: native and copy-back. Almost all implementations are of the native type. The LAV video decoder that is included in the pack offers both variants. The internal DXVA decoders in MPC-HC are native implementations, and ffdshow also offers a native implementation.

With the native type, the decoded video stays in GPU memory until it has been displayed. This brings some limitations with regard to playback. The DXVA decoder must be connected directly to the video renderer. There can be no processing filter in between. The video renderer must also support DXVA, which give you a bit less freedom of choice in renderers. The reason for keeping the decoded video inside GPU memory is efficiency. Many graphics chips haven't been optimized for copying data from GPU memory back to CPU memory. They are too slow for smooth playback. They can only copy data fast in the other direction. This is the case for old AMD/ATI and old Intel chips.

DXVA implementations of the copy-back type will, as the name already suggests, copy the decoded video from GPU memory back to CPU memory. Such implementations don't have the limitations mentioned above and act similar to a normal software decoder. DXVA copy-back only works properly if the GPU can copy the data fast enough. Otherwise it will give stuttering video playback. GPU:s that should be fast enough are:

  • NVIDIA: All models of the past few years
  • Intel: Intel HD Graphics 2000 and newer
  • AMD/ATI: Radeon HD 6xxx and newer

Formats

Related

   

 

This page has no comments.