We may also move it in the core.

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.

DXVA should use only one thread to feed the frames.

Using a decoder device and a video context.

This will make the next patch more readable.

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.

As found in the Microsoft DXVA AV1 specs
https://www.microsoft.com/en-us/download/details.aspx?id=101577

And some code cleaning.

No functional changes.

If there are some extra data, the chroma should be constant and we can estimate
it so that we create the decoder output with the proper chroma on open.

The VLC chroma contains both the subsampling and the bitdepth.

VLC_CODEC_GREY* is used for monochrome.

hxxx_helper_clean() needs to be called if we don't call CloseDecoder().

The decoder_sys_t needs to be free'd now that we manage it manually.
We must not free the decoder_sys_t twice if no pool was created on error.

Iulian Onofrei authored 4 years ago and Hugo Beauzée-Luyssen committed 4 years ago

The actual function that creates a drop-down widget, `add_dropdown`,
refers to it as "drop-down", so this replaces "drop_down" with the
correct spelling.

Also, the `add_value` actually applies to lists too, so this makes
this clear.

Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

The main configuration line is such a very long line, and has been
growing longer recently, frequently hitting the VLC core limit at
200 kB. This caused readline() to fail to return any data, and stop
parsing of the web page short, preventing playback as the stream URLs
were in that line that was never returned.

Instead this relies on peek() and sized read() calls to parse and
recover that line by hand. This effectively bumps things up to up to
1 MB of usable configuration data.

Fixes #24957

The description field sometimes somehow even contains mixed LF and CRLF.

There is currently a feature doing this in the lua bindings, but it is
problematic for several reasons: it doesn't reject insecure requests,
but only masks their output, while actually still going ahead and
silently honoring them; the web interface still recurses through its
directory and registers all endpoints, and exposes their existence by
answering differently depending on the request URL; the lua bindings are
the wrong level to do this, as it precludes any other lua user of the
HTTPd than the web interface; and it hijacks the response body to inject
its own regardless of the declared content type, potentially resulting
in getting it wrongly displayed.

Instead, this simply loads a single notice handler, and prints helpful
messages, directly from within the web interface module.

The documention outright lies about LibVLC waiting to make this
function safe. There are no ways to use this function safely other than
linking LibVLC statically into the application, which is not
*generally* practical.

The Makefile.am modification caused a reconf that could fail with recent
automake version (>= 1.16.2).

Partial revert of bead358b

vd->cfg is only used in the vout thread so we don't need a local copy. We don't
need to modify it either.

It's always vd->cfg available to the display module.

The passed pointer is always vd->cfg. No need to go through varargs for that.

It's always vd->cfg.

It's always vd->cfg.

It's only used to print the format info before the first picture is
displayed. After that the format is not needed anymore.

It may differ if we change the chroma of the local fmt before it's set on
vd->fmt.

At this stage the only difference betweeen vd->source and vd->fmt is the SAR.
Since this local picture is only use to copy planes, the SAR is never used.

It's possible that the original code is wrong as it doesn't take in account the
"kms-vlc-chroma" forced chroma that the core will assume is used.

No need to depend on the output format.

At this stage fmt is not even filled yet.

This will prevent display modules from modifying it anytime they want.
They can modify the format on open, RESET PICTURES and maybe later when a new
format is pushed.

The storage of the display video_format_t is in vout_display_priv_t.display_fmt.

This will prevent display modules from modifying it.

Only osys->source can be modified and sent to the display.

All the fields we use in this function comes from this structure.

Move the function after the vout_display_priv_t definition.

No functional changes.

Don't always show "Client error" when there's an error.

Don't always return "Client error" as error reason

This follows the same approach as oldhttp, and allows configuring the
web interface to use HTTPS.

Refs #19807

It may also be merged in the core, in vlc_picture_pool.h.

The pool can be reused to manage the lifecycle of a picture pool with (hardware)
surfaces that can be released easily in push.

The pictures coming out of the pool no longer have p_sys filled. They only
carry a video context with the relevant data.