To create the vout and decoder device we don't need to know the DPB.

For now the display still holds the picture pool so the display still needs the
DBP size.

So we can create the display separately, when the video context will be created.

The first call creates/gets the vout and the decoder device. The other call
creates/gets the display module.

We should not call vout_Cancel on vout that was never added/started.
(more on that in coming patches)

The first part is to create the decoder device.
The second part is to create the display module (or other depending on the
decoder owner).

Turn decoder_UpdateVideoFormat() is calling the two new functions.

The decoder device is kept in the decoder for now (in further patches it will
come with the video context).

Use the one from the vout thread if it exists. We create one unconditionally
for now not to break the current VAAPI implementation.

Later the video context will come from the decoder (if any).

NULL for now, it will turn into a video context once we pass it from the decoder.

We want to make sure when the display module is created it has a chance to use
the same decoder device the decoder used to be created.

vout_GetDevice doesn't need to check the DPB, it only needs to get a decoder
device from a usable window. Only the display needs to DPB size (for now, since
it creates the decoder pool from it).

Only stop the current display if a new one is going to be created (otherwise
the current one is fine or there is none because there's no window).

In vout_GetDevice we don't care about the current display. So we don't need to
use sys->original, we use a locally cleaned video format instead to match what will
be used in the following call to vout_Request.

Try to enable the window before checking if the original format matches. If the
window is not enabled, the sys->original doesn't making sense anyway.

This will be needed when the GetDevice call will create a window without setting
the sys->original which is only related to the display module.

Only a few decoders will request it.

A decoder device can only be created if the vout has an enabled window.

The caller receives a reference to the decoder device or NULL.

It's already read when we setup the decoder.

If this option is enabled, libdsm will be probed before libsmb2. Use at your
own risk, this option should be always disabled by default and specifically
requested by the user.

This fixes credential dialogs that were not shown when browsing share from UIs.

and fix recursive inclusion of track delay on jitter overshoot

Right now we fallback to 8 bits 4:2:0 for any source format. This is wrong if
we even receive 4:2:2, 4:4:4, 12 bits, 16 bits, etc.

Similar to what is done for VAAPI and VDPAU.

Mathieu Velten authored 5 years ago and Steve Lhomme committed 5 years ago

Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>

Query credentials only if the nt_status is NT_STATUS_ACCESS_DENIED.

This prevents to ask for credentials when the file/dir/share doesn't exist.

allows local playback without use-access flag

because streamurl can handle files

- return early on error (and avoid a big indented block)
- use a local variable to fill the vout_configuration_t

No functional changes

To create the vout and decoder device we don't need to know the DPB.

For now the display still holds the picture pool so the display still needs the
DBP size.

vout_Stop does a vout_StopDisplay + vout_DisableWindow

When we failed to start the thread we shouldn't stop it (by calling vout_StopDisplay)
So just call vout_ReleaseDisplay + vout_DisableWindow

No need to stop the vout (thread, display) when failing to enable the window.
If there wasn't an enabled window, there wasn't any of them.

vout_Stop already cleans sys->original, so no need to do it again.

Some samples don't work properly with --vout=dummy otherwise

Plus one frame to decode

See https://www.webmproject.org/vp9/levels/

The media library module may raise blocking VLC core question dialogs, which will lead to a deadlock when the primary dispatch is performed on the main thread.

For data consistency, objc data reflections are handled on the MT only.