1a70de259d added some sanity checking to
these values to avoid throwing a protocol error (which are fatal) since
the wayland protocol is very strict about the ranges of these values.
Let's tighten up the checks just a little bit to be on the safe side. If
the min_luma is not less than max_luma, consider this a hard error. We
won't set any hdr metadata at all if this happens. For max_fall and
max_cll, we leave mostly the same as before where the value gets set to
0 if it doesn't pass the wayland protocol specification. For the case
where max_fall is greater than max_cll, consider this invalid and set
both values to 0.
0ab3184526 introduced most of the stuff
being removed here. The idea is that when doing encoding the core should
wait until everything is initialized. This is true, but the old
implementation is overly complicated and confusing. What we need is for
both the AO to be initialized and the VO to be reconfigured for encoding
to start. Because of the way initialization works, the VO reconfig
always happens first. Changing the order in playloop would of course
break this assumption, but we can trust that nobody would arbitrarily do
that. So all that needs to be done here is that write_video should wait
until the AO is up before pushing frames. And that only applies in
encoding mode and if there is a selected audio stream in the first
place. This is a simple check.
With that in place, all of this extra junk can be dropped. We don't need
special booleans or events for the simple task of making sure the AO and
VO are both up.
Upgrade tablet input to first class citizen similar like
touch input, but more simple since use case for now is
mouse emulation only.
Keep state for coordinates and in-proximity.
Introduce property for disabling tablet input.
Introduce Client-API property `tablet-pos`.
This ensures that tablet pad objects that belong to a group,
thus rings and strips, are all properly destroyed on removal
or shutdown.
Note that event listeners for ring a strip are not added
since we are not (yet) interested in them and they are not
needed for proper destroy.
Tablets require their own tablet manager and tablet
seats since multiple tablets/pens can be connected to
a single seat. So this is unfortunately a lot of
wiring.
The tablet protocol is supported in the current winimum
wayland-protocols version, so we can always build this.
Note that this is still the unstable version, once the
minimum required wayland-protocol version is 1.35, the
stable version of protocol can be included.
fd4e3af740 originally started installing
it, and we've been doing it ever since then. The value of having all of
these encoding profiles predefined by default is pretty dubious since a
lot of them are pretty old ('MP4 for Nokia N900' being a shining
example) and mpv is not really a good encoding tool anyways. Let's treat
it like the other conf files in etc and install it in the data directory
for reference. If someone really uses these, they can copy the file over
locally to their mpv config directory and it'll still work fine.
We wait for timeout and stop fuzzing, but if there are events spammed
this timeout never fire, so instead limit the number of events after
playback reset.
This is raw option passed to lavf and can be used to inject complex
filters and so on, avoid this for fuzzing as it more fuzzing ffmpeg side
anyway and causes issues with timeouts for some big processing.
Useful for demux_edl where it is possible to have huge nested tree of
demuxers and they are added recursively, which causes stack overflow in
some cases.
Found by OSS-Fuzz.
Also cache last dxgi output, to avoid enumerating outputs, this is done
on every frame and we want to minimize impact of it.
While at it refactor and split loading libraries.
Instead of using IDXGISwapChain::GetContainingOutput create new DXGI
interface on each query. This may not be as efficient, but it solves the
issue where metadata is not updated after changing display settings.
DXGI caches parameters on swapchain creation and never updates it.
Also refactor it so it can be used from other contexts.
Note that DXGI is not D3D11, it's mixed in mpv code, may be cleaned in
the future.
Reword this paragraph making it clear that as long as a and a-b are not
bound, the a-b-c binding works even if b is bound.
The 4-key limit for sequences was raised to 16 by a5dbf34094, because
MP_MAX_KEY_DOWN is used for both the number of keys that can be held
down and for the key history size. Just remove the related sentence
since you're never going to need sequences longer than 16 keys.
If color space hint is enabled respect configured parameters of
swapchain. When color space hint is disabled, override output freely.
This fixes possible fallback or other decisions about output made during
the swapchain color space negotiation.
When targeting SDR on display with enabled HDR, compositor will have to
convert SDR to HDR transfer before sending this to display. Resulting in
most certainly wrong output.
To avoid this always convert SDR to target transfer function when
hinting, this way, we do the conversion in mpv and not defer it down the
pipeline.
Unfortunately it's not very portable to detect if we have HDR display
output and "guess" if what we send to display will be correctly
interpreted or not. But we do this when we can.
Also don't force target_peak value from auto detection, use value from
libplacebo.
This commit is based on incorrect information, see previous commit.
It also deletes the correct information the prefetch starts when the
current file is fully load.
The commit also misunderstood the comment about m3u8 urls. It refers to
the prefetching of file data inside the m3u8 stream manifest data, which
has nothing to do with mpv playlists when the m3u8 urls are opened as one
stream by ffmpeg.
The original comment was not very clear about this, so add more details
about this.
This reverts commit d4bf179e78.
The decision was based on incorrect assumption that this option
"only opens a connection to the next file, and the cache of the next
video starts empty", a prequisite of the assumption that this option
has no major drawbacks, including incurring unwanted network traffic.
The assumption can be proven incorrect by testing with networked files
in playlist. With log level set to debug, the following lines are shown
after the next file is prefetched, while monitoring of network traffic
shows constant network traffic after the currect file cache reading
reaches EOF, which triggers prefetching:
[cplayer] Opening done: <url to prefetched file>
[lavf] select track 0
[lavf] select track 1
[lavf] EOF reached.
[ffmpeg] AVIOContext: Statistics: 37139315 bytes read, 0 seeks
It is clear that saying "there is nothing to prefetch after the first
frame" is a complete lie: in fact, it fetches the whole file to the
demuxer cache, according to the demuxer cache settings. And when the next
file plays, it also starts with full cache rather than "an empty cache".
In fact, what this option really does is written in
556e204a11: --prefetch-playlist calls
demux_start_prefetch() which does the same thing as the
--demuxer-cache-wait option:
"Before starting playback, read data until either the end of the file was
reached, or the demuxer cache has reached maximum capacity."
This is exactly what is happening with the testing. This option will indeed
cause large amount of unwanted network traffic - a concern raised in the
discussion concerning this option.
Revert this commit since it's based on incorrect assumption, and subsequent
incorrect conclusions derived from it in the subsequent discussions.
This reverts commit 978b219889.
Dudemanguy