| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
In particular, remove all the stupid debug printfs from the win code.
|
|
|
|
|
| |
Something about a non-working MinGW thing? Really, I don't care. It
also prevents using the console API properly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already redirect all terminal output through our own wrappers (for
the sake of UTF-8), so we might as well use it to handle ANSI escape
codes.
This also changes behavior on UNIX: we don't retrieve some escape codes
per terminfo anymore, and just hardcode them. Every terminal should
understand them.
The advantage is that we can pretend to have a real terminal in the
normal player code, and Windows atrocities are locked away in glue
code.
|
|
|
|
|
|
|
| |
The original intention was probably to avoid unnecessarily high numbers
of wakeups. Change it to wait at most 25% of buffer time instead of 75%
until refilling. Might help with the dsound problems in issue #1024, but
I don't know if success is guaranteed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So talking to a certain Intel dev, it sounded like modern VA-API drivers
are reasonable thread-safe. But apparently that is not the case. Not at
all. So add approximate locking around all vaapi API calls.
The problem appeared once we moved decoding and display to different
threads. That means the "vaapi-copy" mode was unaffected, but decoding
with vo_vaapi or vo_opengl lead to random crashes.
Untested on real Intel hardware. With the vdpau emulation, it seems to
work fine - but actually it worked fine even before this commit, because
vdpau was written and designed not by morons, but competent people
(vdpau is guaranteed to be fully thread-safe).
There is some probability that this commit doesn't fix things entirely.
One problem is that locking might not be complete. For one, libavcodec
_also_ accesses vaapi, so we have to rely on our own guesses how and
when lavc uses vaapi (since we disable multithreading when doing hw
decoding, our guess should be relatively good, but it's still a lavc
implementation detail). One other reason that this commit might not
help is Intel's amazing potential to fuckup anything that is good and
holy.
|
|
|
|
|
| |
For use as playlist navigation button in OSC, now the osd-font
carries all symbols needed by the OSC.
|
|
|
|
|
|
| |
Fixes #1025.
CC: @mpv-player/stable
|
|
|
|
| |
Although it's probably safe for most VOs, there's no guarantee.
|
| |
|
|
|
|
| |
Available and stable since forever (xkbcommon 0.2).
|
| |
|
| |
|
|
|
|
| |
This value is more accurate than the default value.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Provide a more useful example instead.
|
|
|
|
| |
This is still pretty useful for debugging timing-dependent things.
|
|
|
|
|
|
| |
This could be used by VO implementations to report a recent vsync time
to the generic VO code, which in turn will use it and the display FPS
to estimate at which point in time the next vsync will happen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses glXGetVideoSyncSGI() to check how many vsyncs happened since
the last flip_page() call. It allows checking a pattern of vsync
increments of at most 2 elements. For example, to check ~24 fps playback
on a ~60 Hz monitor, this can be used:
--vo=opengl:check-pattern=[3-2]:waitvsync
Whether the reported results are accurate or just plain wrong may depend
on the driver and if the waitvsync sub-option is used. There are no
guarantees.
This option is undocumented, and may be removed again in the near or
distant future.
|
|
|
|
|
|
|
| |
For debugging (drawing fun plots with TOOLS/stats-conv.py).
Also move last_flip under the correct comment: it's not protected by the
lock, and can be accessed by the VO thread only.
|
|
|
|
|
|
|
| |
Playing with high framedrop could make it run out of surfaces. In
theory, we wouldn't need an additional surface, if we could just clear
the vo_vaapi internal surface - but doing so would probably be a pain,
so I don't care.
|
|
|
|
|
|
|
|
| |
Only reports the most recently entered output if the window is displayed on
2 or more outputs. Should be changed to the lowest fps of all outputs the
window is visible. Until no one complains this will have to wait.
Look for the VO framedropping for more information on this topic.
|
|
|
|
|
|
| |
The FBO format was changed some time ago.
CC: @mpv-player/stable
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a new file is loaded, playback never starts instantly. Rather, it
takes some playloop iterations until initial audio and video have been
decoded, and the outputs have been (lazily) initialized. This means you
will get status line updates between the messages that inform of the
initialized outputs. This is a bit annoying and clutters the terminal
output needlessly.
Fix this by never printing the status line before playback isn't fully
initialized. Do this by reusing the --term-playing-msg code (which
prints a message once playback is initialized). This also makes sure the
status line _is_ shown during playback restart when doing seeks.
It's possible that the change will make the output more confusing if for
some reason is stuck forever initializing playback, but that seems like
an obscure corner case that never happens, so forget about it.
|
|
|
|
|
|
|
|
| |
print_status() is called at a later point anyway (and before sleeping),
so this code has little effect. This code was added in commit a4f7a3df5,
and I can't observe any problems with idle mode anymore.
Now print_status() is called from a single place only, within osd.c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the Xrandr configuration changes, re-read it. So if you change
display modes or screen configuration, it will update the framedrop
refresh rate accordingly.
This passes the rootwin to XRRSelectInput(), which may or may not be
allowed. But it works, and the documentation (which is worse than used
toilet paper, great job Xorg) doesn't forbid it, or in fact say anything
about what the window parameter is even used for.
|
| |
|
| |
|
|
|
|
| |
Implemented in shell, because it has to be done at runtime.
|
|
|
|
|
|
| |
Oops.
Fixes #1020.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nvidia's vdpau implementation is pretty good, but other factors make it
much less attractive for use as default VO. For example, Mesa often has
low quality drivers (mess up things with the presentation queue and the
vdpau API time source). Intel ruins things completely, and we're likely
to run on emulation via OpenGL. Compositing has unknown effects (to me
anyway), but appears to reduce the vdpau advantages.
One important reason to prefer vo_vdpau was that it could do proper
framedropping. Framedropping got fixed for the other VOs, so this reason
is going away.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works only on X11, and only if the refresh rate changes due to the
window being moved to another screen (detected by us). It doesn't
include system screen reconfiguration yet.
This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy.
It means extra thread communication with the win32 and Cocoa backends.
On the other hand, a frame doesn't happen _that_ often, and the
communication should still be pretty cheap and fast, so it's probably
ok.
Also needs some extra fuzz for vo_vdpau.c, because that does everything
differently.
|
|
|
|
| |
Oh, we have to free this stuff. OK.
|
| |
|
|
|
|
|
|
| |
This is always included in the Xorg development headers. Strictly
speaking it's not necessarily available with other X implementations,
but these are hopefully all dead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr
extension to retrieve the refresh rate. Xrandr has the advantage that it
supports multiple monitors (at least the modern version of it).
For now, we don't attempt any dynamic reconfiguration. We don't request
and listen to Xrandr events, and we don't notify the VO code of changes
in the refresh rate. (The later works by assuming that X coordinates map
directly to Xrandr coordinates, which probably is wrong with compositing
window manager, at least if these use complicated transformations. But I
know of no API to handle this.)
It would be nice to drop use of the Xinerama extension too, but
unfortunately, at least one EWMH feature uses Xinerama screen numbers,
and I don't know how that maps to Xrandr outputs.
|
|
|
|
| |
And change the defaults for the other queue options to reduce latency.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--demuxer-readahead-secs now controls how much the demuxer should
readahead by an amount of seconds. This is based on the raw packet
timestamps. It's not always very exact. For example, h264 in Matroska
does not store any linear timestamps (only PTS values which are going
to be reordered by the decoder), so this heuristic is usually off by
several hundred milliseconds.
The decision whether to readahead is basically OR-ed with the other
--demuxer-readahead-packets options. Change the manpage descriptions
to subtly convey these semantics.
|
| |
|
| |
|
|
|
|
|
|
| |
I must have broken it some time ago. The error case dealing with an
unavailable backbuffer was broken, and didn't handle memory management
correctly.
|
|
|
|
|
|
| |
Since the display FPS is currently detected on X11 only (and even there
it's known to be wrong on certain setups), it seems like a good idea to
make this user-configurable.
|
|
|
|
|
|
| |
This is probably a stupid idea, but it can't be denied that this
actually allows playing video without larger desync, even if video is
too slow.
|
|
|
|
|
|
|
|
|
| |
I'm not sure about the merit, though it does print nice numbers if debug
output is enabled.
Basically, this tries to achieve similar results as the glFinish()
business, but again it entirely depends on the drivers whether this
does anything meaningful, or whether it's actively harmful.
|
| |
|
|
|
|
|
|
| |
It seems that at least on nvidia systems with composting disabled, we
can get it to block deterministically on the actual vsync event, which
should improve framedropping.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
|
|
|
|
|
| |
Originally, I probably had plans to allow NULL images to handle things
like the last frame case, but that idea was dropped later.
|
|
|
|
|
|
|
|
|
| |
Apparently users prefer this behavior.
It was used for subtitles too, so move the code to calculate the video
offset into a separate function. Seeking also needs to be fixed.
Fixes #1018.
|
|
|
|
|
|
|
|
|
|
| |
The OSD is marked as changed, but the core isn't notified and this
doesn't immediately wakeup. (Possibly the OSD code should wakeup the
core instead, but maybe that woudl be overkill.)
Observed when using "mp.use_suspend = false" in the OSC, and pausing,
and moving the mouse pointer out of the window. The last part of the
fade remained visible for longer than intended.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code reorganized to make layouts exchangeable
alternative test layout can be tested with
layout=slimbox
in the OSC config
timers are now used to properly animate the fade out when the
player is paused
duplicate seeks are discarded again
|
|
|
|
| |
See additions to options.rst.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sub_reset() was called on cycling subtitle tracks and on seeking. Since
we don't want that subtitles disppear on cycling, sd_lavc.c didn't clear
its internal subtitle queue on reset, which meant that seeking with PGS
subtitles could leave the subtitle on screen (PGS subtitles usually
don't have a duration set).
Call it only on seeking, so we can also strictly clear the subtitle
queue in sd_lavc.
(This still can go very wrong if you disable a subtitle, seek, and
enable it again - for example, if used with libavformat that uses "SSA"
style demuxed ASS subtitle packets. That shouldn't happen with newer
libavformat versions, and the user can "correct" it anyway by executing
a seek while the subtitle is selected.)
|
|
|
|
|
|
|
|
| |
Until recently, vo_opengl could be accessed from a single thread only,
due to the OpenGL API context being thread-specific. This issue doesn't
exist anymore, because VOs run on their own thread. This means we can
simply lock/unlock the playloop instead of doing something complicated
to get the playloop thread to execute our code.
|
|
|
|
|
| |
I'd like to enable this by default, but unfortunately the OSC seems to
have some problems with it.
|
|
|
|
|
|
|
| |
It's not true anymore that the core will stop replying for 50ms
(waiting for video) without calling this function. Simplify the
documentation accordingly. Accessing properties that go through
the VO still have this problem, though.
|
| |
|
| |
|
|
|
|
|
| |
This Libav-invented API is of course completely different from the
FFmpeg-one. (The fun part is that I approved of both.)
|
|
|
|
|
|
| |
The previous commit made the completion script always return non-zero, even when
a match is found. This explicitly sets the return value to zero whenever a match
is found but defaults to non-zero in case nothing is matched.
|
|
|
|
|
|
|
|
| |
Returning a non-zero value signals to the zsh completion system that no matches
were added by the script so that it can try the user-defined matchers (e.g.
those defined with matcher-list).
Fixes #1008.
|
|
|
|
|
|
|
|
| |
Just always load the theme. It gets freed properly and dosn't bother anyone.
Fixes #1012.
CC: @mpv-player/stable
|
|
|
|
| |
Don't print PTS warnings by skipping the normal video path.
|
|
|
|
|
|
|
| |
This ran adjust_sync() on every playloop iteration, instead of every
newly decoded frame. It seems this was idempotent in the common case,
but the code was originally designed to be run once only, so restore
that.
|