| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OSD is passed to VOs via struct sub_bitmaps, which has a change_id
field. This field is incremented whenever there is a (potential) change
to the other struct contents. If not, the VO can rely on it not having
changed. This must include for example sub_bitmap.x and sub_bitmap.dw.
If these two fields (and y equivalents) change, change_id must change,
even if the subtitle bitmap data might still be the same.
sd_lavc.c stopped respecting this at some unknown point. It could
sometimes cause problems, though usually only with bad and old VOs which
somehow relied on this more than vo_gpu. (I've actually encountered this
before with sd_lavc subtitle scaling, as indicated by a nasty comment,
though probably didn't track this down, since said old VOs can die in a
fire.)
Fix this by maintaining the change_id explicitly. Unfortunately adds
even more code. Instead of comparing the result we could track property
changes, but I think this is better. The number of parts is always very
low with this subtitle decoder, so there's no actual performance issue
to worry about.
This could be triggered by scaling changes (video-zoom etc.), but
probably also changing bitmap subtitle position or scaling.
|
| |
|
|
|
|
|
|
| |
Should be somewhat helpful. (All VOs are full of code trying to
compensate for this, more or less, and this will allow simplifying
some code later. Maybe.)
The screen size is mostly for robustness checks.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
glibc/gcc make certain math functions set errno by default. This is not
required by the standard, and makes everything complexer and slower
(well done glibc). It typically prevents inlining certain math functions
too, where the compiler can turn a function call to a single
instruction, such as observed with lrint().
So this has possibly some minor performance advantages, and no
disadvantages.
|
| |
|
|
|
|
|
|
|
|
| |
Fallback to drmModeAddFB2 if drmModeAddFB2WithModifiers fails. I've
observed it failing on a pinebook pro running manjaro. We also got "0"
as modifiers from FFmpeg anyway, which might or might not have
something to do with this.
Instead of trying to find the source of the problem, just add this
fallback.
|
| |
|
|
|
|
| |
Untested (I don't have a platform that requires modifiers to work
here). Might break something, or might fix something. At least this
looks more intuitive to me.
|
| |
|
|
| |
It is interesting to know why drmModeAddFB2WithModifiers failed.
|
| |
|
|
|
| |
For applications that are DPI aware WM_DPICHANGED message contains
suggested size and position of window
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The current implementation of presentation feedback was designed to be
used with flip model presentation. With the bitblt model,
GetFrameStatistics returns totally different values and it's not clear
if we can use them at all. Previously, this wasn't a problem because
with the bitblt model, GetFrameStatistics only worked in exclusive
fullscreen. Now that mpv supports exclusive fullscreen, we should
explicitly check for a flip model swapchain before using presentation
feedback.
|
| | |
|
| |
|
|
|
|
|
| |
In theory an incompatible change, but I think it's for the better.
Impact should be relatively low. I hope.
Fixes: #7676
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is really basic for planar image data access; not sure why there
weren't such helpers before.
They also handle trickier formats that use bit-packing, or they would be
mich simpler. (This affects only BGR4/BGR4/MONOW/MONOH, I hope whoever
invented them is proud of triggering so many special cases for so little
gain.)
|
| |
|
|
|
|
|
|
|
| |
These were still mapped to MP errors during probing, but they also get
triggered when instance creation fails due to lack of support for e.g.
wayland. Since waylandvk is probed above x11vk, we should probably
suppress these by default.
Closes #7626
|
| | |
|
| |
|
|
|
|
| |
This brings the displayed percentage closer to the exact number and
allows mpv to more frequently display 100% when it finishes playing a
typical video or audio file.
|
| |
|
|
|
|
|
| |
I have to say this in PR reviews all the time, so maybe I should make i
explicit. In too many words of course, many, many, too many words which
nobody will read, I get it, now shut up. Sneak in some subtle or not so
subtle comments about how I think that github is ruining code quality.
|
| |
|
|
|
|
|
|
|
|
| |
mp.set_osd_ass() (which was undocumented, or in other words, was not
supposed to be used by external scripts) used to do change detection in
the mpv C code. If the resolution or payload did not change, it was not
re-rendered on the lower levels.
Apparently this made some people sad, so fix it. (But only after I told
them to fuck off.) (Well I didn't put it this way, but still.)
|
| |
|
|
|
| |
It's not available on Windows because MinGW is fucking horrible and
Microsoft are fucking assholes.
|
| |
|
|
|
|
|
|
|
|
| |
For some reason this was never done? Looking through the code, it was
never the case that the frame cache was hit for still frames. I have no
idea why not. It makes a lot of sense to do so.
Notably, this massively improves the performance of updating the OSC
when viewing e.g. large still images, or while paused. (Tested on a
4000x8000 image, the OSC now responds smoothly to user input)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header probing hacks were previously all broken. They only worked
the first time the archive file was open. Since subsequent opens (on
seek) occured in the middle of the source stream rather than at the
beginning, the stream_read_peek calls meant to retrieve the headers were
instead returning random bytes in the middle of the file.
Perhaps the worst manifestation of this was when seeking within a
multi-volume .rar archive with the "legacy" file naming pattern. If the
seek required a reopen, the fact that the archive was multi-volume would
be forgotten and the file would appear truncated terminating playback.
To solve this, only perform the header probling the first time the
archive is opened. Save the results and reuse them on subsequent
reopens. Put this in a wrapper so this is transparent to
demux_libarchive.
|
| |
|
|
|
|
|
|
| |
I couldn't find any reason for this message to be so far dispalced from
where it's necessity was determined. That necessity is not however in
question.
Also improve the wording and line breaking.
|
| | |
|
| |
|
|
| |
Sometimes useful for debugging. Also fix a random typo elsewhere.
|
| |
|
|
|
| |
TA_MEMORY_DEBUGGING always defined. But allow defining it from the
compiler command line (-D), because maybe that's useful for someone?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Making OSD/subtitle bitmaps refcounted was planend a longer time ago,
e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap
data) was added in 2016. But nothing benefited much from it, because
struct sub_bitmaps was usually stack allocated, and there was this weird
callback stuff through osd_draw().
Make it possible to get actually refcounted subtitle bitmaps on the OSD
API level. For this, we just copy all subtitle data other than the
bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy
refcount shit, but when that was a big mess and hard to debug and just
boiled to emulating malloc(), I made it a full allocation+copy. This
affects mostly the parts array. With crazy ASS subtitles, this parts
array can get pretty big (thousands of elements or more), in which case
the extra alloc/copy could become performance relevant. But then again
this is just pure bullshit, and I see no need to care. In practice, this
extra work most likely gets drowned out by libass murdering a single
core (while mpv is waiting for it) anyway. So fuck it.
I just wanted this so draw_bmp.c requires only a single call to render
everything. VOs also can benefit from this, because the weird callback
shit isn't necessary anymore (simpler code), but I haven't done anything
about it yet. In general I'd hope this will work towards simplifying the
OSD layer, which is prerequisite for making actual further improvements.
I haven't tested some cases such as the "overlay-add" command. Maybe it
crashes now? Who knows, who cares.
In addition, it might be worthwhile to reduce the code duplication
between all the things that output subtitle bitmaps (with repacking,
image allocation, etc.), but that's orthogonal.
|
| |
|
|
|
|
|
|
|
| |
Only _writes_ are aligned, so the assumption doesn't work for reads. But
it's easy to fix by rounding down x0 to the next byte boundary. Writing
pixels outside of the read area is allowed, and we don't go out of
buffer bounds.
Patch by anon32, permission to do anything with it.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is mostly for testing. It adds passing through the metadata through
the video chain. The metadata can be manipulated with vf_format. Support
for zimg alpha conversion (if built with zimg after it gained alpha
support) is implemented. Support premultiplied input in vo_gpu.
Some things still seem to be buggy.
|
| |
|
|
|
|
|
| |
Used to be used by vo_x11, and some other situations where software
conversion was employed. Haven't seen anyone complain about how software
brightness controls went away (originating from mplayer), so whatever,
it won't be needed again.
|
| |
|
|
|
|
|
|
| |
This fixes two issues with invalid value after 38/48:
- It was not detected correctly and ended up skipping 4 instead of 0.
- The intent was to skip 0, but it's better to skip the rest.
Behavior with valid 2/5 after 38/48 was correct and is unaffected.
|
| |
|
|
|
| |
terminal_get_size also works on windows. This is useful because now
tct also works on Windows with native VT console.
|
| |
|
|
|
| |
The narrower-by-1 width is not required with a native VT console
because the wrapping behavior is the same as on *nix on such case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the wayland code, the left mouse click is treated a bit differently.
Dragging the left click allows mpv to request a window move to the
compositor. In some cases, this can also request a window resize if the
osc-windowcontrols are enabled. These functions had the strange side
effect of messing up mpv's deadzone (it seemed to disappear completely).
A harmless enough workaround is to just explictly send an UP event for
left click after the move/resize functions are finished executing. The
xdg_toplevel move and resize functions both finish after the button
press is let go, so we are guarenteed to have the left click in the UP
state here. Sending this event probably unconfuses some calculation
somewhere thus fixing the deadzone bug. It feels a little silly, but
it's safe and works. Fixes #7651.
|
| |
|
|
|
| |
We want basemode unmodified so that we can use it if setting VT mode
fails.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When stats.lua is used without a video window then it uses the terminal.
On Windows, however, so far it disabled ansi escape sequences and used
plaintext unless ANSICON env is set.
It's unclear why it's disabled on windows, because at the time it was
added it only used bold by default and mpv ansi emulation on windows
already supported bold at that time.
We can guess that it was disabled because if the same config is used on
both linux and Windows, and it had complex escape sequences for
stats.lue, then it would be emulated incorrectly on Windows.
This shouldn't be an issue anymore, as the last two commits both enhance
the emulation to be quite complete (and graceful where it's not), and
also enable the much-more complete native VT terminal when possible
(Windows 10).
Just remove this windows exception at stats.lua.
|
| |
|
|
|
|
|
|
| |
This enables native and more complete escape-sequence handling instead
of our emulation. E.g. it supports 256/true colors, and more.
This should get enabled automatically on Windows 10 build 16257
(August 2017) or later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously an SGR sequence was emulated correctly only if:
- It had exactly 1 or 2 numeric values (not 0).
- Only reset, bold, and foreground colors were supported.
- 256/true colors were not skipped correctly with their sub-values.
Now it supports the same as before, plus:
- 0-16 (inclusive) numeric values, e.g. \e[m now resets correctly.
- Supports also codes for background color, reverse, underline* .
- Supports also codes for default intensity/fg/bg/reverse/underline.
- 256/true colors are recognized and skipped gracefully.
* Reverse/underline seem to work only on windows 10.
|
| | |
|
| |
|
|
| |
part of EGL 1.5 which is not present ie on Raspberry Pi
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
On FreeBSD non-POSIX threading functions are in a separate header.
DragonFly and OpenBSD adopted FreeBSD header and extensions.
../test.c:3:3: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
{ pthread_set_name_np(pthread_self(), "ducks"); return 0; }
^
../osdep/threads.c:47:5: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pthread_set_name_np(pthread_self(), tname);
^
Signed-off-by: Jan Beich <jbeich@FreeBSD.org>
|
| |
|
|
|
| |
This makes it use the previously added fringe image formats. What is the
purpose of this change? Who knows.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move lookup GBRP or planar gray/alpha formats to separate functions in
some cases.
Make setup_regular_rgb_packer() not use a 4:4:4 YUV format to "pass"
RGB. This was used as a "trick" to avoid the stupid GBRP plane
permutation, but it confused severely, so get rid of it. Just do the
reordering, even if the zimg wrapper itself will reorder it back (which
is so stupid that I used the other approach at first). The comment
saying IMGFMT_420P was bogus of course; typically it was IMGFMT_444P.
|
| |
|
|
| |
Probably doesn't matter anywhere.
|
| |
|
|
|
|
|
|
|
| |
This was inconsistent for unknown reason. monob was the way we wanted
it, and handling of monow was missing.
See the previous "img_format: add some mpv-only helper formats" commit.
Matters for the zimg wrapper.
|
| |
|
|
|
|
|
|
| |
mp_imgfmt_get_forced_csp() should be consistent with the MP_CSP_RGB/YUV
flags.
At least the different handling of the XYZ exception was a mess, even if
the result was the same.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)
Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When I added mp_regular_imgfmt, I made the chroma subsampling use the
actual chroma division factor, instead of a shift (log2 of the actual
value). I had some ideas about how this was (probably?) more intuitive
and general. But nothing ever uses non-power of 2 subsampling (except
jpeg in rare cases apparently, because the world is a bad place).
Change the fields back to use shifts and rename them to avoid mistakes.
|
| |
|
|
|
|
|
| |
Make this slightly less ad-hoc. Also correct the missing alpha flag for
yap8/yap16.
Despite reduced redundancy, the LOC is going up anyway... whatever.
|
| |
|
|
|
|
|
|
|
|
|
| |
On FreeBSD and DragonFly kernel checks if `frsig` is valid and aborts
with `EINVAL` if not. However, `frsig` was never implemented.
$ build/mpv --gpu-context=drm /path/to/video.mkv
[...]
[vo/gpu] VT_SETMODE failed: Invalid argument
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.
[...]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ ./waf configure
Checking for vt.h : no
Checking for DRM : vt.h not found
[...]
../test.c:1:10: fatal error: 'sys/vt.h' file not found
#include <sys/vt.h>
^~~~~~~~~~
$ build/mpv --gpu-context=drm /path/to/video.mkv
Error parsing option gpu-context (option parameter could not be parsed)
Setting commandline option --gpu-context=drm failed.
Exiting... (Fatal error)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One not-so-nice hack in the wayland code is the assumption of when a
window is hidden (out of view from the compositor) and an arbitrary
delay for enabling/disabling the usage of presentation time. Since you
do not receive any presentation feedback when a window is hidden on
wayland (a feature or misfeature depending on who you ask), the ust is
updated based on the refresh_nsec statistic gathered from the previous
feedback event.
The flaw with this is that refresh_nsec basically just reports back the
display's refresh rate (1 / refresh_rate * 10^9). It doesn't tell you
how long the vsync interval really was. So as a video is left playing
out of view, the wl->last_queue_display_time becomes increasingly
inaccurate. This led to a vsync spike when bringing the mpv window back
into sight after it was hidden for a period of time. The hack for
working around this is to just wait a while before enabling presentation
time again. The discrepancy between the "bogus"
wl->last_queue_display_time and the actual value you get from the
feedback only happens initially after a switch. If you just discard
those values, you avoid the dramatic vsync spike.
It turns out that there's a smarter way to do this. Just use mp_time_us
deltas. The whole reason for these hacks is because
wl->last_queue_display_time wasn't close enough to how long it would
take for a frame to actually display if it wasn't hidden. Instead, mpv's
internal timer can be used, and the difference between wayland_sync_swap
calls is a close enough proxy for the vsync interval (certainly better
than using the monitor's refresh rate). This avoids the entire conundrum
of massive vsync spikes when bringing the player back into view, and it
means we can get rid of extra crap like wl->hidden.
|
