| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
| |
There's no reason to let the core wait until the frame is done
displaying. In practice, the core normally didn't need this additional
wakeup, and the VO was quick enough to fetch the new frame, before the
core even attempted to queue a new frame. But it wasn't entirely clean,
and the correct wakeup handling might matter in some cases.
|
|
|
|
|
|
|
|
|
|
| |
With default settings, this allows you to hit the 100% mark (with
default --softvol-max in the middle) even if you've reached min or max
volume before. This is because 50 is not divisible by 3 (old default)
but by 2 (new default).
Not really sure why there still can be issues with higher --softvol-max
and --volstep=1, but this is where I stop caring.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If --write-filename-in-watch-later-config is used, and the filename
contains newline characters (as generally allowed on Unix), then the
newline will be written to the resume file literally, and the parts
after the newline character are interpreted as options.
This is possibly security relevant.
Change newline characters (and in fact any other special characters)
to '_'.
Reported as #1099 (this commit is a reimplementation of the proposed
pull request).
CC: @mpv-player/stable
|
|
|
|
| |
Now the packet allocation functions can fail.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Just check against zero directly.
Changes behavior, but that should be ok.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
ShellCheck warns about "vara-varb" about not being in $(()), but we
actually want the literal string, so quote it. Also fix a typo.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
| |
buffer_pool_get_front now returns always a valid buffer.
No need for corner cases.
|
| |
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
| |
Apparently making ESC exit fullscreen mode is the more popular
convention compared to ESC quitting the program.
It was also concluded that ESC should do nothing when the windows is
already in normal state.
See discussion in #973.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The filter output size can be 0. Due to how filtering works, this is
nothing unusual, but avresample_convert() will return 0. The same case
is already handling with "normal" resampling (this commit fixes the
reordering code).
Additionally, don't use an assert(). avresample_convert() failing is
unusual, but might also happen due to e.g. internal out of memory
conditions, so we shouldn't just crash on it.
Curiously observed with --ao=oss --audio-channels=5.1 when changing
speed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently NetBSD users want/need this (see issue #1080).
In order not to break playback, we need at least to emulate get_delay().
We do this approximately by using the system clock.
Also, always close the audio device on reset. Reopen it on play only. If
we can't reopen it, don't retry until after the next time reset or
resume is called, to avoid spam and unexpectedly "stealing" back the
audio device.
Also do something about framestepping causing audio desync.
|
|
|
|
|
|
|
| |
The context struct had an audio_buf_info field, but there's no reason
why this would be needed. It's a tiny struct, and it isn't permanent
state. It's always returned by SNDCTL_DSP_GETOSPACE. Keeping this as
field is just confusing, so get rid of it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code for reopening the audio device was separate, and duplicated
some of the "real" open code. This was very badly done, and major
required parts of initialization were skipped. Fix this by removing
the code duplication. This consists mainly of moving the code for
opening the device to a separate function, and adding some changes
to handle format changes gracefully. (We can't change the audio
format on the fly, but we can at least not explode and play noise
when that happens.)
As a minor change, actually always use SNDCTL_DSP_RESET when closing
the audio device. We don't want to wait until the rest of the buffer
is played.
Also, don't use strerror() when printing the error message that
reopening failed, simply because reopen_device() takes care of this,
and also errno might be clobbered at this point.
|
|
|
|
|
|
|
| |
I have no idea whether this is true, because there literally doesn't
seem to exist documentation for SNDCTL_DSP_RESET. But at least on
Linux' OSS emulation, it is true. Also, it would be quite insane if
it would be needed.
|
|
|
|
|
|
| |
It seems on NetBSD SNDCTL_DSP_RESET exists, but using it for pausing
is not feasible. We still use it to discard the audio buffer when
closing the audio device.
|
|
|
|
| |
MPlayer uses bytes, mpv uses sample counts in the AO API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some window managers can prevent mapping of a window as a feature. i3
can put new windows on a certain workspace (with "assign"), so if mpv is
started on a different workspace, the window will never be mapped.
mpv currently waits until the window is mapped (blocking almost all of
the player), in order to avoid race conditions regarding the window
size. We don't want to remove this, but on the other hand we also don't
want to block the player forever in these situations.
So what we need is a way to know when the window manager is "done" with
processing the map request. Unfortunately, there doesn't seem to be a
standard way for this. So, instead we could do some arbitrary
communication with the WM, that may act as "barrier" after map request
and the "immediate" mapping of the window. If the window is not mapped
after this barrier, it means the window manager decided to delay the
mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such
a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS
property on the mpv window, and we receive a PropertyNotify event. If
that happens, we always continue and cancel waiting for the MapNotify
event.
I don't know if this is sane or if there's a better mechanism. Also,
this works only for WMs which support this message, which are not many.
But at least it appears to work on i3. It may reintroduce flickering on
fullscreen with other WMs, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is pretty imperfect, but it's just a demo.
The main purpose is clarifying how and when to get the video size.
In theory, retrieving the properties this way has a race condition:
after reading dwidth, the video could resize again. But the worst that
can happen are mismatching dwidth/dheight values, and the
MPV_EVENT_VIDEO_RECONFIG event would be immediately received again,
which would fix the mismatch. You could read the full video-out-params
property to absolutely avoid it, but it's not worth the trouble.
|
| |
|
|
|
|
|
|
|
| |
(a << 24) is not in the valid int range when a is 255, so use an
unsigned instead.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
| |
Merges pull request #1094, with some minor changes. mpv expects IEEE,
and IEEE allows divisions by 0 for floats, so these shouldn't actually
be a problem, but do it anyway for the sake of clang.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use libwaio to read from pipes (stdin or named pipes) on Windows. This
liberates us from nasty issues, such as pipes (as created by most
programs) not being possible to read in a non-blocking or event-driven
way. Although it would be possible to do that in a somewhat sane way
on Vista+, it's still not easy, and on XP it's especially hard. libwaio
handles these things for us.
Move pipe.c to pipe-unix.c, and remove Windows specific things. Also
adjust the input.c code to make this work cleanly.
|
| |
|
|
|
|
| |
See issue #1084.
|
|
|
|
| |
Regression from today.
|
|
|
|
|
| |
This code was legal with C11 atomics, but it fails with our
compatibility wrapper.
|
|
|
|
|
|
| |
If you send the "quit" or "stop" command with the client API, it will
now attempt to kill network I/O immediately (same as normal input in the
previous commits).
|
|
|
|
|
|
|
| |
Refine the ugly hack from the previous commit, and let the "quit"
command and some others abort playback immediately. For
playlist_next/playlist_prev, still use the old hack, because we can't
know if they would stop playback or not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mechanism originates from MPlayer's way of dealing with blocking
network, but it's still useful. On opening and closing, mpv waits for
network synchronously, and also some obscure commands and use-cases can
lead to such blocking. In these situations, the stream is asynchronously
forced to stop by "interrupting" it.
The old design interrupting I/O was a bit broken: polling with a
callback, instead of actively interrupting it. Change the direction of
this. There is no callback anymore, and the player calls
mp_cancel_trigger() to force the stream to return.
libavformat (via stream_lavf.c) has the old broken design, and fixing it
would require fixing libavformat, which won't happen so quickly. So we
have to keep that part. But everything above the stream layer is
prepared for a better design, and more sophisticated methods than
mp_cancel_test() could be easily introduced.
There's still one problem: commands are still run in the central
playback loop, which we assume can block on I/O in the worst case.
That's not a problem yet, because we simply mark some commands as being
able to stop playback of the current file ("quit" etc.), so input.c
could abort playback as soon as such a command is queued. But there are
also commands abort playback only conditionally, and the logic for that
is in the playback core and thus "unreachable". For example,
"playlist_next" aborts playback only if there's a next file. We don't
want it to always abort playback.
As a quite ugly hack, abort playback only if at least 2 abort commands
are queued - this pretty much happens only if the core is frozen and
doesn't react to input.
|
|
|
|
|
|
|
|
|
| |
This means they get special handling for asynchronously aborting
playback, even if the player is "stuck".
Also document "stop". It seems somewhat useful for client API users
(although that will be implemented properly only in the following
commits.)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The memcpy() is actually not enough: the types are incompatible, and no
memcpy, union, etc. will change that. (Although no real compiler will
ever break this.) Attempt to make this theoretically correct by actually
using a struct pointer. It's not the same struct type, but supposedly
it's ok, because all struct pointers always have the same size and
representation in standard C.
|
|
|
|
|
|
|
|
|
|
|
| |
Idle mode went to sleep too early, e.g. just pressing "ESC" did nothing,
until the next event happened. This was because it directly went to
sleep after processing commands. What we should do instead is rechecking
all state after processing commands, redraw OSD, and then go to sleep.
This also fixes some strange OSD-related behavior.
Also move some other code around to separate idle mode initialization
from the normal run loop.
|
|
|
|
|
|
|
| |
Not sure why this was originally added as autorepeated. It makes no
sense, because switching between choices should never autorepeat. (For
the normal "add"/"cycle" commands, autorepeat is usually enabled, but
command.c tries to disable it specifically for choice properties.)
|
|
|
|
|
| |
Just some minor things. In particular, don't call mp_input_wakeup()
manually, but make it part of queuing commands (as far as possible).
|
|
|
|
|
|
|
|
| |
Mismatching units in timeout calculation.
Also, as a near-cosmetic change, explicitly wake up the core on the
right time. Currently this does nothing, because the core is woken up
anyway - but it will matter with the next commit.
|
| |
|
|
|
|
|
| |
Close the audio device if it was already opened, but the rest of
initialization failed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace select() usage with poll() (and reduce code duplication).
Also, while we're at it, drop --disable-audio-select, since it has the
wrong name anyway. And I have doubts that this is needed anywhere. If
it is, it should probably fallback to doing the right thing by default,
instead of requiring the user to do it manually. Since nobody has done
that yet, and since this configure option has been part of MPlayer ever
since ao_oss was added, it's probably safe to say it's not needed.
The '#ifdef SNDCTL_DSP_GETOSPACE' was pointless, since it's already used
unconditionally in another place.
|
|
|
|
|
|
|
| |
Might help with debugging.
Unfortunately, there doesn't seem to be a way to get the actual
pulseaudio server version.
|
| |
|
|
|
|
| |
I broke it again.
|