| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code here did not handle passing a frames context when
ffmpeg itself did not know about the device it came from (for example,
because it was created by device derivation inside a filter graph), which
would break encoders requiring that input. Fix that by checking for HW
frames and device context methods independently, and prefer to use a
frames context method if possible. At the same time, revert the encoding
additions to the device matching function because the additional
complexity was not relevant to decoding.
Also fixes #8637, which is the same case but with the device creation
hidden in the ad-hoc libmfx setup code.
|
| |
|
|
|
|
|
| |
This can support encoders which want frames and/or device contexts. For
the device case, it currently picks the first initialised device of the
desired type to give to the encoder - a new option would be needed if it
were necessary to choose between multiple devices of the same type.
|
| |
|
|
| |
Also move it into a dedicated function in the hardware file.
|
| |
|
|
|
|
|
| |
The implementation will use some default in this case. The empty string
is not a meaningful device for any existing hardware type, and indeed
OpenCL treats it identically to no device already to work around the lack
of this setting on the command line.
|
| | |
|
| |
|
|
|
| |
Removes specific support for all hwaccels supported by the generic code
(DXVA2, D3D11VA, NVDEC, VAAPI and VDPAU).
|
|
|
* commit 'c95169f0ec68bdeeabc5fde8aa4076f406242524':
build: Move cli tool sources to a separate subdirectory
Merged-by: James Almer <jamrial@gmail.com>
|
