| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Allows to query if some timer is currently running or was
stopped/killed.
|
|
|
|
| |
Partial fix to #3090
|
|
|
|
|
|
|
|
| |
This uses the normal autoprobing rules like "auto", but rejects anything
that isn't flagged as copying data back to system memory.
The chunk in command.c was dead code, so remove it instead of updating
it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 786f37ae accidentally changed seeking behavior such that
continuous seeking (holding the seek button down) would use the previous
seek target timestamp, instead of the new video timestamp. (This is for
the default mode, seeking to keyframes.)
The result is that the movement on the seekbar is smooth, but the way
the video updates is awkward. Some might actually prefer the new
behavior (and some players effectively show similar bahavior), but I
don't. So restore the old behavior.
This is done in two steps:
First: strictly wait for the entire seek process to finish, which will
effectively make the seeking code pick up the new video timestamp
correctly.
This would play audio immediately, which would result in noise during
continuous seeking, which leads to second: explicitly abort the playback
restarting process if this case is detected, and never play audio.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and
renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or
documented where not), which makes the whole thing saner and cleaner. In
particular, thread-safety rules become less subtle and more obvious.
The new internal API makes it easier to support multiple OpenGL interop
backends. (Although this is not done yet, and it's not clear whether it
ever will.)
This also removes all the API-specific fields from mp_hwdec_ctx and
replaces them with a "ctx" field. For d3d in particular, we drop the
mp_d3d_ctx struct completely, and pass the interfaces directly.
Remove the emulation checks from vaapi.c and vdpau.c; they are
pointless, and the checks that matter are done on the VO layer.
The d3d hardware decoders might slightly change behavior: dxva2-copy
will not use the VO device anymore if the VO supports proper interop.
This pretty much assumes that any in such cases the VO will not use any
form of exclusive mode, which makes using the VO device in copy mode
unnecessary.
This is a big refactor. Some things may be untested and could be broken.
|
|
|
|
|
|
|
|
|
|
|
| |
Add --taskbar-progress command line option and property which controls taskbar
progress indication rendering in Windows 7+. This option is on by default and
can be toggled during playback.
This option does not affect the creation process of ITaskbarList3. When the
option is turned off the progress bar is just hidden with TBPF_NOPROGRESS.
Closes #2535
|
|
|
|
|
| |
Requested. Will prevent odd layout for playlists with URLs longer than
the screen.
|
|
|
|
|
|
|
|
| |
Introduce hwdec-current and hwdec-interop properties.
Deprecate hwdec-detected, which never made a lot of sense, and which is
replaced by the new properties. hwdec-active also becomes useless, as
hwdec-current is a superset, so it's deprecated too (for now).
|
|
|
|
|
|
|
|
|
| |
For "current" markers on OSD properties like chapter-list. The marker is
now an actual arrow instead of "> ", and non-current entries will have
the same indentation as the current entry.
While I'm not entirely sure about the new look of those lists, it's a
bit better than the visual mess that was before.
|
|
|
|
| |
So we can concatenate them with strings at compile time.
|
|
|
|
|
|
|
|
|
|
| |
Because it's annoying and feels unnatural.
If the B point is set while paused, don't seek. If not paused, it should
properly loop immediately.
In theory there's a chance that it will show at least 1 frame after the
loop point when setting the B point. But let's not care about that.
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes backstepping getting "stuck" when e.g. holding down a key
bound to the backstep command. The reason is that even if the backstep
itself is finished, the next backstep might not take the new video PTS
as reference if the hr-seek itself isn't finished yet.
The intention of not waiting for the hr-seek to finish was faster
backstepping by possibly skipping audio decoding. But it probably
doesn't matter enough to make the rest of the code more complex.
|
|
|
|
|
|
|
| |
As a positive side-effect, this also errors out gracefully for the
extremely unlikely but possible case certain builtin filters are not
available. (This could happen only with crippled libavfilter builds that
can't be used by anything using its public API.)
|
| |
|
|
|
|
| |
Fixes bogus frame drop counter in cover art mode.
|
|
|
|
|
|
|
|
|
| |
Another crappy fix for timestamp reset issues. This time, we try to fix
files which have very weird but legitimate frame durations, such as
cdgraphics. It can have many short frames, but once in a while there are
potentially very long frames.
Fixes #3027.
|
|
|
|
|
| |
Switches to a black window if --force-window is used while coverart
"video" is playing.
|
|
|
|
|
| |
In particular, this won't overwrite the playback PTS in coverart mode,
which actually fixes relative seeks.
|
| |
|
|
|
|
| |
Truly dumb bug introduced with the previous commit.
|
|
|
|
|
|
|
|
|
|
| |
Commit 382bafcb changed the behavior for ab-loop-a. This commit changes
ab-loop-b so that the behavior is symmetric.
Adjust the OSD rendering accordingly to the two changes.
Also fix mentions of the "ab_loop" command to the now preferred
"ab-loop".
|
|
|
|
| |
Just a theoretical issue, most likely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check whether video is ready yet was done only in STATUS_FILLING.
But it also switched to STATUS_READY, which means the next time
fill_audio_out_buffers() was called, audio would actually be started
before video.
In most situations, this bug didn't show up, because it was only
triggered if the demuxer didn't provide video packets quickly enough,
but did for audio packets.
Also log when audio is started.
(I hate fill_audio_out_buffers(), why did I write it?)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Strictly schedule an update in regular intervals as long as either
stream cache or demuxer are prefetching. Don't update just always
because the stream cache is enabled ("idle != -1") or cache-related
properties are observed (mp_client_event_is_registered()).
Also, the "idle" variable was awkard; get rid of it with equivalent
code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calculate the buffering percentage in the same code which determines
whether the player is or should be buffering. In particular it can't
happen that percentage and buffering state are slightly out of sync due
to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the
previously determined buffering state.
Now it's also easier to guarantee that the buffering state is updated
properly.
Add some more verbose output as well.
(Damn I hate this code, why did I write it?)
|
|
|
|
| |
Possibly slightly more useful/intuitive.
|
|
|
|
|
|
|
| |
And remove the same thing from the client API code.
The command.c code has to deal with many specialized M_PROPERTY_SET_*
actions, and we bother with a subset only.
|
|
|
|
| |
In that case, it merely changes the underlying option value.
|
|
|
|
|
|
|
|
|
| |
If a mpv_node wrapped a string, the behavior was different from calling
mpv_set_property() with MPV_FORMAT_STRING directly. Change this.
The original intention was to be strict about types if MPV_FORMAT_NODE
is used. But I think the result was less than ideal, and the same change
towards less strict behavior was made to mpv_set_option() ages ago.
|
|
|
|
| |
Probably fixes #3049.
|
|
|
|
|
|
| |
Just a bridge to the option.
(Did I ever mention that I hate the property/option separation.)
|
|
|
|
|
|
| |
Commit 57506b27 accidentally broke this. The status (including the
usually always active demuxer cache) should be shown only if the stream
cache is actually enabled.
|
|
|
|
|
|
|
|
| |
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)
Since this includes the cache speed, this should fix #3003.
|
|
|
|
|
|
| |
Enables runtime change of the option.
Fixes #2994.
|
|
|
|
|
|
|
|
|
|
|
| |
This would get stuck in reconfiguring the filter chain forever, because
params was mutated ("params.rotate = 0;"). This was used as input for
vf_reconfig(), but the filter chain input must always be equivalent to
the decoder output, or filter chain reconfiguration will be triggered.
The line of code to reset the rotation is from a time when this used to
work differently.
Also remove the unnecessary try_filter() parameter.
|
|
|
|
|
|
|
| |
Makes certain cases of runtime changes actually work.
Also change the label for the stereo3d filter and make it consistent
with the rotate one.
|
|
|
|
|
| |
Inverted condition due to weird semantics after a refactor some time
ago. Fixes #2848.
|
| |
|
|
|
|
|
| |
Requested. The intention is that scripts can provide mappable actions
for key bindings without setting a default key.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the JSON IPC protocol with named pipes, which are
probably the closest Windows equivalent to Unix domain sockets in terms
of functionality. Like with Unix sockets, this will allow mpv to listen
for IPC connections and handle multiple IPC clients at once. A few cross
platform libraries and frameworks (Qt, node.js) use named pipes for IPC
on Windows and Unix sockets on Linux and Unix, so hopefully this will
ease the creation of portable JSON IPC clients.
Unlike the Unix implementation, this doesn't share code with
--input-file, meaning --input-file on Windows won't understand JSON
commands (yet.) Sharing code and removing the separate implementation in
pipe-win32.c is definitely a possible future improvement.
|
|
|
|
|
| |
Also change the property to an int, since using double is questionable
and pointless.
|
|
|
|
|
|
|
| |
Should reflect I/O speed.
This could go into the terminal status line. But I'm not sure how to put
it there, since it already uses too much space, so it's not there yet.
|
|
|
|
|
|
|
|
|
| |
This changes behavior somewhat. The old behavior can be restored by
running "mp.use_suspend=true". It was originally introduced for the OSC,
but I can't reproduce whatever misbehavior I was seeing.
(See mp.suspend()/resume() for explanations what the suspend mechanism
does.)
|
|
|
|
|
| |
mp_switch_track() doesn't do it automatically for whatever reason, so do
it here.
|
|
|
|
|
|
|
| |
This also takes care of sending the required property change
notifications.
Fixes #2929 and maybe fixes #2920.
|
|
|
|
|
| |
some extractors don't return a format_note for their audio stream which
resulted in commandv complaining "argument 4 is not a string" (got nil).
|
|
|
|
|
|
|
| |
This pause stuff is bothersome and is needed only for a few corner-
cases. This commit removes it from the demuxer public API and replaces
it with a demux_run_on_thread() function and refactors the code which
needed demux_pause(). The next commit will change the implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changing the byte stream position without cooperation of the demuxer
seems a bit insane, and is certainly useless. A user should do factor
seeks instead. For formats like ts, this will actually translate to byte
seeks, while treating the rest of the playback chain a bit more
gracefully. With this argument, remove write access to this property.
If someone really complains, proper byte seeks could be added as seek
mode (although I'm going to need a convincing argument for this).
Read access changes too, but in a more subtle way.
|
|
|
|
|
|
| |
No need to have them everywhere. The only exception/annoyance is
MAX_OSD_PARTS, which is now basically duplicated (and at runtime
initialization is checked with an assert()).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, there was only 1 global ASS overlay that could be set by all
scripts. This was often perceived as bug when multiple scripts tried to
set their own ASS overlay.
This was kind of hard to solve because the script could set its own ASS
PlayResX/Y, which makes it impossible to share a single ASS_Renderer for
multiple scripts. The OSC unfortunately makes use of this feature (and
unfortunately can't be fixed because it's a POS), so we're stuck with
this complication.
Implement the worst-case solution and fix this by creating separate ASS
track and renderer objects for each script that wants to set an ASS
overlay.
The z-order is decided by the order the scripts set their text first.
This is essentially random, unless you do it at script init, and you
pass scripts in a specific order. Script initialization is currently
serialized (as a feature), so the first loaded script gets lowest
Z-order.
The Lua script API interestingly remains the same. (And also will remain
undocumented, unsupported, and potentially volatile.)
|
|
|
|
|
|
|
|
| |
The scaling was the wrong way around, and the section name was missing.
Regression since commit 5fa45fb5.
Fixes #2916.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not scale OSD mouse input to the ASS OSD script resolution. The
original idea of this mechanism was that the user doesn't have to care
about the actual resolution of anything, and can just use the OSD
resolution consistently. But this made things worse.
Remove the implicit scaling, and always use the screen resolution.
(Except with --vo=xv, where additional scaling is forced upon
everything.)
Drop get_osd_resolution(). There is no replacement. Rename
get_screen_size() and get_screen_margins() to use "osd" instead of
"screen". For anything but --vo=xv these are equivalent, but with
--vo=xv the OSD resolution has additional implicit scaling.
Add code to osc.lua which emulates the old behavior.
Note that none of the changed functions were public API, so implicit
breakage of scripts which used it is just going to happen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subtitles can be preloaded, which means they're fully read and copied
into ASS_Track. This in turn is mainly for the sake of being able to do
subtitle seeking (when it comes down to it, subtitle seeking is the
cause for most trouble here).
Commit a714f8e92 broke preloaded subtitles which have events with
unknown duration, such as some MicroDVD samples. The event list gets
cleared on every seek, so the property of being preloaded obviously gets
lost.
Fix this by moving most of the preloading logic to dec_sub.c. If the
subtitle list gets cleared, they are not considered preloaded anymore,
and the logic for demuxed subtitles is used.
As another minor thing, preloadeding subtitles did neither disable the
demux stream, nor did it discard packets. Thus you could get queue
overflows in theory (harmless, but annoying). Fix this by explicitly
discarding packets in preloaded mode.
In summary, now the only difference between preloaded and normal
demuxing are:
1. a seek is issued, and all packets are read on start
2. during playback, discard the packets instead of feeding them to the
subtitle decoder
This is still petty annoying. It would be nice if maintaining the
subtitle index (and maybe a subtitle packet cache for instant subtitle
presentation when seeking back) could be maintained in the demuxer
instead. Half of all file formats with interleaved subtitles have
this anyway (mp4, mkv muxed with newer mkvmerge).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 8d4a179c made subtitle decoders pick up fonts strictly from the
same source file (i.e. the same demuxer).
It breaks some fucked up use-case, and 2 people on this earth complained
about the change because of this. Add it back.
This copies all attached fonts on each subtitle init. I considered
converting attachments to use refcounting, but it'd probably be much
more complex.
Since it's slightly harder to get a list of active demuxers with
duplicate removed, the prev_demuxer variable serves as a hack to achieve
almost the same thing, except in weird corner cases. (In which fonts
could be added twice.)
|
| |
|
|
|
|
|
| |
Also change decoder-list (for the sake of sharing the underlying code
for both properties).
|
|
|
|
| |
Was printed only with "mpv -h" or so.
|