This change removes convoluted core thread extraction through dispatch
added in 500ce69a06.
Currently we fully control this thread, create it and join, there is no
reason not to keep the handle of it in the player context.
As a bonus to code simplification this also fixes thread handle leak on
Windows.
Fixes: #14472
This test:
- Checks if libmpv can be loaded dynamically.
- Checks for leaks after mpv context destroy.
- Checks if libmpv can be reloads after dlclose()
Window classes are global per process, but they are associated with the
module that registered them. Documentation is clear that it is the DLL's
responsibility to unregister its own classes:
No window classes registered by a DLL are unregistered when the DLL is
unloaded. A DLL must explicitly unregister its classes when it is
unloaded.
See: https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-registerclassw
Using a window class after the DLL is unloaded would result in access
violation errors. This is not that important for libmpv, where it is
unlikely someone would use the "mpv" window class externally. The real
issue comes from the fact that reloading libmpv would fail to register
the class (as it still exists) and consequently fail to create a window.
This commit fixes the operability of libmpv after reloading it.
Fixes: #11638
Client side cursors have always had some issues with fractional scaling.
However since we changed to using viewporter for cursor scaling, most
(or all?) of the problems can be fixed. Unfortunately, a scaling factor
was being truncated to int instead of kept as a double. This matched the
old behavior with buffer_scale, but it's better to use double so the
viewport is actually set to the correct size. Of course, none of this is
relevant if the compositor is using cursor shape.
Fixes f0a6578259Fixes#14001
When you type something in select mode and then delete it, table.sort
changes how selectable items are sorted. Restore the order specified by
the mp.input caller in this case.
- Remove the opts comments because they are already in console.rst and
will become outdated if not updated in both places
- Reuse last_pos in truncate_utf8() instead of recalculating the
previous character's position
- Clear the OSD earlier when the console is not active
The previous commit to avoid refresh seeking video streams has an edge
case when enabling tracks when loading files. Since the streams are
initially unselected and then multiple streams are enabled, the detection
only works reliably when video tracks are enabled first.
This makes sure that loading file enables tracks in a predictable order.
940854c86f added this logic, but when the
demuxer contains a selected video stream, it causes a seek for the video
stream. This is unnecessary since the problems that commit fixed are only
relevant for external audio streams. For a demuxer with a video stream
selected, the synchronization is done by the demuxer implementation.
Add a check to prevent this.
This follows up 96e1f1dfa5 which converted --gpu-context, and has the
same advantages as listed there.
Unlike with --gpu-context auto can be used anywhere in the list, e.g.
--gpu-api=d3d11,auto works.
I wanted to use the list of GPU contexts as the description in
get_type_desc(), but there is no talloc context to allocate it to, so I
set a print_help_list to print them. The APIs go before the contexts so
that etc/_mpv.zsh doesn't try to complete the contexts.
This function is used to reject invalid context names early, and without
it the context fails to create and only audio is played, but it doesn't
need to check for known entries again.
We wrap the default Lua allocator to allow used memory tracking. This
works well, except that we never destroy the default allocator or notify
it that we are closing. Since we override it for the current Lua state,
it is reasonable that the Lua engine does not expect it to be used. We
get and pass through a free call, but in the case of LuaJIT, the
internal allocator has additional state and is freed differently. So, in
fact, it is a LuaJIT leak because once we replace the allocator with our
custom one, they should clean its internal state. I guess the assumption
is to override allocator only before any allocation happen. To work
around this issue, restore the default allocator, the one that we use,
before closing the state. This way, everything is cleared as expected.
Note that the current solution of wrapping the default allocator works
only because none of the supported Lua engines actually invalidate the
allocator on the lua_setallocf() call. However, they could, so keep in
mind that we are currently depending on an implementation detail.
Thanks to @Dudemanguy for help with finding the changes that introduced
the leak.
Fixes: a67bda2840Fixes: #14451
Mainly for debugging. It might be handy to disable presentation feedback
on wayland to make sure something isn't going wrong with the
calculations somewhere.
Before a7158ceec0, string comparision was
done with strcmp, which does unsigned comparison. The natural sort
implementation instead compares on char values.
This causes implementation-defined behavior in comparison, depending on
the signedness of char type.
Fix this by using unsigned comparison instead.
Adding base path make sense only if it is a real directory or url
location. In case of protocols like memory adding base path to playlist
entry in facts adds the whole playlist to that entry.
For example `mpv $'memory://#EXTM3U\na/b'` produces infinite loop,
expanding playlist, adding more to it.
open_file adds the dirname to support relative playlist enties, however,
the dirname is invalid when the name doesn't represent a path, such as
with memory://..., so avoid taking the dirname with such protocols.
Found by OSS-Fuzz.
`:` were not escaped correctly. Also while at it clear other external
file lists, as we don't want to load any. Subtitle fuzzer will be added
in the future.
It is surprisingly hard to clear the list with C API. That needs whole
mpv_node_list with 0 elements, to make it clear it.
Similar to the previous commit but the other way around. If you start
mpv as idle, load up a playlist without immediately hitting play and
then try to go to the next item, nothing happens. Naturally, you would
expect this to go to the first item. Fix this detecting if the playlist
has not started yet, the direction, and going to the first item in the
list.
Previously, playlist-prev didn't work if you played a playlist to
completion using --idle and tried to go back. Naturally, one would
expect this to bring up the last item in the playlist, but nothing
happens. This is just because playlist_get_next is stupid and doesn't
take this into account since pl->current is NULL and thus returns NULL.
Fix this by considering the direction, checking if the playlist was
played to completion and grabbing the last entry in the index.
Kacper Michajłow
llyyr
holdingsllc
Dudemanguy
verygoodlee
Guido Cella
nanahi
bashonly
der richter