| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
No functional changes.
|
| |
|
|
|
|
|
| |
These cases were probably confusing. Exit early, which makes it much
clearer what's going on. Should not change anything functionally.
|
|
|
|
|
| |
No changes in functionality, other than being slightly more correct at
stream EOF.
|
|
|
|
|
|
| |
Fixes #1009.
CC: @mpv-player/stable
|
|
|
|
|
| |
Otherwise vdp_video_mixer_destroy() would later fail when called on an invalid
video mixer handle. With mesa r600 vdpau driver, this would cause a segfault.
|
|
|
|
|
|
|
| |
Since the 'syms' tool is shipped in waf's extras, when using system waf the
default tool overrides our own. Force our syms tool by providing the tooldir.
Fixes #1006
|
|
|
|
|
|
| |
Fixes #1007.
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
|
| |
Xlib is not thread-safe. Or actually it is, but it's an incomprehensible
hack that was added later, and which needs to be acitvated manually
(this makes no sense). And it appears that the vdpau accesses X from the
decoder thread if GLX interop is used (and not in any other situations -
this doesn't make too much sense either).
So, just call the magic function that enables Xlib thread-safety.
|
|
|
|
| |
It seems only stereo PCM should be passed through.
|
|
|
|
| |
Also, imitate the qt example somewhat.
|
| |
|
|
|
|
|
|
|
| |
No reason to use less.
Since the name "default" is misleading now, replace it with "auto"
(still recognize the old name).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
|
|
|
|
|
|
|
| |
Also add instructions to release-policy.md, since this can be easily
forgotten.
CC: @mpv-player/stable
|
|
|
|
|
|
| |
Requested on: https://github.com/mpv-player/mpv/commit/90ec3334174e80c16f00971886223a3afabc1aca#commitcomment-7331673
Might remove or remap them again later.
|
|
|
|
|
| |
Or at leats this is the intention. It's a bit hard to tell which
information is needed, and which not.
|
|
|
|
| |
This makes a certain corner case simpler at a later point.
|
|
|
|
|
|
| |
Found with valgrind. This is somewhat terrifying, because the VA-API API
function is supposed to fill these values, and we access them only if
the API functions return success. So this shouldn't have happened.
|
| |
|
| |
|
|
|
|
|
| |
Looks like TOOLS/lua/ is now established as dumping ground for random
Lua scripts, so DOCS/lua_examples/ is not needed anymore.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The function video_decode_and_filter(), called between initializing the
local vf variable and using it, can actually destroy and recreate the
filter. Thus, the vf variable turns into a dangling pointer if that
happens.
Could be observed with: --hwdec=vda --deinterlace=yes --vf=yadif
(Also happens with vdpau/vaapi.)
|
|
|
|
|
| |
Whether this helps is probably questionable and depends on the GPU. But
the vaapi code does it too.
|
|
|
|
|
|
|
|
| |
When a new event was added, merely a flag was set, instead of actually
waking up the core (if needed). This was ok in ancient times when all
event sources were part of the select() loop. But now there are several
cases where other threads can add input, and then you actually need to
wakeup the core in order to make it read the events at all.
|
| |
|
|
|
|
| |
For convenience. Use ${=cache} to get the old formatting.
|
|
|
|
|
|
|
|
| |
This code was sending a string to a different thread, and then
deallocated the string shortly after, which means most of the time
the other thread was accessing a dangling pointer.
It's possible that this is the cause for #1002.
|
|
|
|
| |
We want this heuristic to trigger during normal playback only.
|
|
|
|
|
|
| |
vo_sdl.c has broken event handling and just polls. The polling time was
quite low, so the playloop OSD redrawing heuristic inhibited redraws,
which made the window appear frozen when paused.
|
| |
|
|
|
|
|
|
|
|
|
| |
Completely useless, and could accidentally be enabled by cycling
framedrop modes. Just get rid of it.
But still allow triggering the old code with --vd-lavc-framedrop, in
case someone asks for it. If nobody does, this new option will be
removed eventually.
|
|
|
|
|
|
|
| |
Some of them changed semantics or got renamed.
Note that the replacements in the example.conf are not necessarily the
equivalents of the replaced options.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to jump chapters in a gile that has no chapters does nothing,
not even show a warning. This is confusing. The reason is that the
"add chapter" command will just bail out completely if the property
is unavailable.
This was because it exited when it couldn't get the property type.
Instead of exiting, just don't enter the code that needs the type.
(I'm not sure when this behavior changed. I consider it a regression.
It was probably caused by changes to the chapter code, which perhaps
started returning UNAVAILABLE instead of OK if there are no chapters.)
|
| |
|
|
|
|
|
|
| |
"UP" seeks forward, so "PGUP" should skip to the next chapter.
Fixes #998.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split the options into the following sections:
* Playback Control
* Program Behaviour
* Video
* Audio
* Subtitles
* Window
* Disc Devices
* Equalizer
* Demuxer
* Input
* OSD
* Screenshot
* Software Scaler
* Terminal
* TV
* Cache
* Network
* DVB
* PVR
* Miscellaneous
Most options are sorted by usefullness and how often they're used or how
important they are.
This makes finding the right options easier and adds some sort of structure.
|
|
|
|
|
|
| |
Reduce from 1000ms to 100ms. Since there is an audio thread updating AOs
quickly enough now, requesting such a large buffer size makes no sense
anymore.
|
|
|
|
|
|
|
|
|
|
| |
Changing audio-delay is probably not needed.
Changing balance "works", but not as expected (sets up a pan matrix to
change left/right contributions to each other, rather than changing the
relative volumes of each channel).
I expect that the rest are not in use by anyone.
|
|
|
|
|
|
| |
The client API exports this state via events already, but maybe it's
better to explicitly provide this property in order to facilitate use on
OSD and similar cases.
|
|
|
|
|
|
| |
This is delayed by 300ms - before that, the status doesn't change. I
feel like it would too annoying if the status line would "flicker" on
normal seek by quickly showing and hiding the indicator.
|
|
|
|
|
|
| |
As discussed in #973.
Keep the old bindings for now; there's no reason to unmap them yet.
|
|
|
|
| |
Don't like this? You're invited to fix this crap.
|
|
|
|
| |
Should fix #989.
|
|
|
|
|
|
|
|
|
| |
If this code is not skipped, encoding (or dumping with --ao=pcm) will
attempt to adjust video timing to audio. Since another commit (0cce8fe6)
already avoids writing audio ahead, this didn't slow down encoding to
realtime, but it was still significantly slower.
This change should actually remove all extra sleeping.
|
|
|
|
|
| |
The temporary QByteArray is deallocated already at the end of the
statement in C++, instead of the end of the scope (like in C).
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switching tracks caused cached_demux_control() to catch the command to
switch tracks, even if no thread was running. Thus, the tracks were
never really switched, and EOF happened immediately on playback start.
Fix it by not using the cache at all if the demuxer thread is disabled.
The cache code still has to be called somewhere, though, because it
handles stream metadata update.
Regression from today.
|
| |
|
| |
|
|
|
|
| |
Also fix a typo in the Makefile manpage rule.
|
|
|
|
|
|
|
| |
Got lost some time ago. Although I'm not sure if it actually does
anything on MPlayer (it exists there, but might broken, not sure).
Fixes #988 (untested).
|
|
|
|
|
|
|
|
| |
channels.conf was never used (even though its config path was resolved).
Also remove the non-sense with the access() call.
Fixes #987 (untested).
|
|
|
|
|
|
|
| |
This can just happen in the time between VO creation, and the first call
to vo_reconfig. It seems the recent threading changes exposed this bug.
Fixes #986.
|
|
|