- Mar 18, 2022
-
-
Steve Lhomme authored
Tested on NVIDIA 3090 GPU and Intel Iris Xe Graphics on 8-bit sources. The DXVA decoding is only enabled if the decoder device is set to D3D11VA or DXVA2. If the hardware decoder is not found, we fallback to software decoding. The profile needs to be known on open to use hardware decoding as it requires using a single frame thread, so fallback to software after the open would have impact on performance. It's using an "nvdec_pool" for hardware buffer pools, directly from the nvdec folder. Some code could be shared (in a library) with the other DXVA modules.
-
Steve Lhomme authored
Tested on NVIDIA 3090 GPU and Intel Iris Xe Graphics on 8-bit sources. The DXVA decoding is only enabled if the decoder device is set to D3D11VA or DXVA2. If the hardware decoder is not found, we fallback to software decoding. The profile needs to be known on open to use hardware decoding as it requires using a single frame thread, so fallback to software after the open would have impact on performance. It's using an "nvdec_pool" for hardware buffer pools, directly from the nvdec folder. Some code could be shared (in a library) with the other DXVA modules.
-
Steve Lhomme authored
-
Steve Lhomme authored
Use in the next patches. Co-authored-by:Matt Wozniak <mwozniak@microsoft.com>
-
Steve Lhomme authored
Using a decoder device and a video context. The hardware decoders are loaded as modules (as does libavcodec) so it can be coded in various languages (C++). The modules will be added to the configuration with the dav1d package but will still need finer tests to enable them or not.
-
Steve Lhomme authored
Based on (unmerged) code from Matthew Wozniak https://code.videolan.org/mwozniak/dav1d/-/tree/dxva If the AV1 structures are found in dxva.h, dav1d is compiled with DXVA support. The code is only enabled on Windows build. The host app is responsible for feeding the DXVA API(s). This DXVA only layer bypasses the software rendering in CPU buffers and fills the DVXA structures instead. When the host app provides DXVA callbacks, only one frame thread is used, since DXVA doesn't like to be fed from multiple threads.
-
Steve Lhomme authored
-
Steve Lhomme authored
DXVA should use only one thread to feed the frames.
-
Steve Lhomme authored
We may also move it in the core.
-
- Mar 17, 2022
-
-
Even though they don't use WRL or IID_PPV_ARGS yet. Better safe than sorry.
-
It's using IID_PPV_ARGS.
-
It's using WRL.
-
It's using WRL.
-
It's using WRL for the DXGI capture.
-
It's not using LIBCOM when linking but uses WRL with COM objects coming from DWriteCreateFactory called indirectly. We could later clean the code with WRL.
-
It's using IID_PPV_ARGS and WRL.
-
It's using IID_PPV_ARGS and WRL.
-
It's using WRL.
-
This avoids potential compiler optimizations when casting to void** when using IID_PPV_ARGS or WRL. If the option is not supported we fail the configure as many important C++ modules may not work as expected due to pointer aliasing. In practice this should never happen as GCC for mingw-w64 and Clang support this correctly.
-
It should probably have been a LIBADD anyway
-
The statement is useless and misplaced. It was added in ee8376da.
-
-
-
-
-
Every involved modules other than FFmpeg's assume little endian (e.g. VA, which derives from DRM which uses little endian always), or only works on little endian systems at all.
-
The first entry indicated it, but it was missing beyond that.
-
-
Our previous implementation couldn't handle a random insert in the middle of the model.
-
-
They are all internal now, it's ok to require unused arguments for a given type.
-
Rename it to input_type, expose it via input_internal.h (usable by input.c / es_out.c), and pass it to es_out in order to avoid fetching input_thread_t private data.
-
- Mar 16, 2022
-
-
-
-
-
Fixes returning INVALID timestamp when mapping to 0.
-
-
-
-
otherwise it is delayed until first data/pcr
-
