Provides a simplistic way to seek without having to care about weird
situations like timestamp vs. playback time. This is good, because the
seek command is currently timestamp based, so when using the seek
command the user _does_ have to care.
If this mode is enabled, the player tries to strictly synchronize video
to display refresh. It will adjust playback speed to match the display,
so if you play 23.976 fps video on a 24 Hz screen, playback speed is
increased by approximately 1/1000. Audio wll be resampled to keep up
with playback.
This is different from the default sync mode, which will sync video to
audio, with the consequence that video might skip or repeat a frame once
in a while to make video keep up with audio.
This is still unpolished. There are some major problems as well; in
particular, mkv VFR files won't work well. The reason is that Matroska
is terrible and rounds timestamps to milliseconds. This makes it rather
hard to guess the framerate of a section of video that is playing. We
could probably fix this by just accepting jittery timestamps (instead
of explicitly disabling the sync code in this case), but I'm not ready
to accept such a solution yet.
Another issue is that we are extremely reliant on OS video and audio
APIs working in an expected manner, which of course is not too often
the case. Consequently, the new sync mode is a bit fragile.
For video sync, we want separate playback speed controls for user-
requested speed and the "correction" speed for video timing. Further, we
use this separation to make sure only a resampler is inserted if
playback speed is only changed for video sync correction.
As of this commit, this is basically inactive code. It's just
preparation for the video sync code (the following commit).
Removes some more internal API calls from the Lua scripting backend.
Which is good, because ideally the scripting backend would use libmpv
functions only.
One awkwardness is that mouse sections are still not supported by the
public commands (and probably will never), so flags like allow-hide-
cursor make no sense to an outside user.
Also, the way flags are passed to the Lua function changes. But that's
ok, because they're only undocumented internal functions, and not
supposed to be used by script users. osc.lua only does due to historical
reasons.
This was requested. It was more or less present internally already and
used for Lua scripting. Lua will switch to the "public" functions in
the following commits.
Nobody wanted to restore this, so it gets the boot.
If anyone still wants to volunteer to restore menu support, this would
be welcome. (I might even try it myself if I feel masochistic and like
wasting a lot of time for nothing.) But if it does get restored, it
should be done differently. There were many stupid things about how it
was done. For example, it somehow tried to pull mp_nav_events through
all the layers (including needing to "buffer" them in the demuxer),
which was needlessly complicated. It could be done simpler.
This code was already inactive, so this commit actually changes nothing.
Also keep in mind that normal DVD/BD playback still works.
At least Matroska files have a "forced" flag (in addition to the
"default" flag). Export this flag. Treat it almost like the default
flag, but with slightly higher priority.
This command has been deprecated in the 0.8.x and 0.9.x releases - get
rid of it. Its only point ever was MPlayer compatibility, which broke
years ago anyway.
Wnile it seems quite logical to me that commands use _ as word
separator, while properties use -, I can't really explain the
difference, and it tends to confuse users as well. So always
prefer - as separator for everything.
Using _ still works, and will probably forever. Not doing so would
probably create too much chaos and confusion.
Also replace their implementation with the recently introduced
properties. One significant difference is that audio-channels using OSD
formatting does not print the channel layout. The user can just use the
replacement property instead.
Now --volume takes an absolute volume, meaning it doesn't depend on
--softvol-max. 0 is still silence, and 100 now always means unchanged
volume. The OSD and the "volume" property are changed accordingly.
Also raise the minimum value of --softvol-max. A value below 100 makes
no sense and breaks the OSD.
Only absolute percentage seeking was permitted first. It is now also
possible to seek by relative percentage.
MPSEEK_FACTOR is used as seek_type.
Fixes#1950.
Signed-off-by: wm4 <wm4@nowhere>
Now the rescan_external_files command will by default reselect the audio
and subtitle streams. This should be more intuitive.
Client API users and Lua scripts might break, but can be fixed in a
backward-compatible way by setting the mode explicitly.
Approximate time of video buffered in the demuxer, in seconds. Same as
`demuxer-cache-duration` but returns the last timestamp of bufferred
data in demuxer.
Signed-off-by: wm4 <wm4@nowhere>
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
The old behavior does not make too much sense after all. If you don't
want to file to be overwritten, the user can check this manually.
This is a change in behavior - let's hope nobody actually relied on it.
Requested change in behavior.
Note that we set the assumed "infinite" display_fps to 1e6, which
conveniently lets vo_get_vsync_interval() return a dummy value of 1,
which can be easily checked against, and still avoids doing math with
float INFs.
This gets rid of the need for a second (or more) parameters; instead it
can be all in one parameter. The (now) redundant parameter is still
parsed for compatibility, though.
The way the flags make each other conflict is a bit tricky: they have
overlapping bits, and the option parser disallows setting already set
bits.
Now --ass-use-margins doesn't apply to normal subtitles anymore. This is
probably the inverse from the mpv behavior users expected so far, and
thus a breaking change, so rename the option, that the user at least has
a chance to lookup the option and decide whether the new behavior is
wanted or not.
The basic idea here is:
- plain text subtitles should have a certain useful defalt behavior,
like actually using margins
- ASS subtitles should never be broken by default
- ASS subtitles should look and behave like plaintext subtitles if
the --ass-style-override=force option is used
This also subtly changes --sub-scale-with-window and adds the --ass-
scale-with-window option. Since this one isn't so important, don't
bother with compatibility.
Not very important for the command line player; but GUI applications
will want to know about this.
This only adds the internal API; support for specific audio outputs
comes later.
This reuses the ao struct as context for the hotplug event listener,
similar to how the "old" device listing API did. This is probably a bit
unclean and confusing. One argument got reusing it is that otherwise
rewriting parts of ao_pulse would be required (because the PulseAudio
API requires so damn much boilerplate). Another is that --ao-defaults is
applied to the hotplug dummy ao struct, which automatically applies such
defaults even to the hotplug context.
Notification works through the property observation mechanism in the
client API. The notification chain is a bit complicated: the AO notifies
the player, which in turn notifies the clients, which in turn will
actually retrieve the device list. (It still has the advantage that it's
slightly cleaner, since the AO stuff doesn't need to know about client
API issues.)
The weird handling of atomic flags in ao.c is because we still don't
require real atomics from the compiler. Otherwise we'd just use atomic
bitwise operations.
This shouldn't exist and for the most part is meant to be used by the
ytdl Lua script, but let's document it anyway. Since the Lua API handles
all the details, it's considered much more "stable" than the raw API,
which is why the raw API wasn't documented.
These commands are counterparts of sub_add/sub_remove/sub_reload which
work for external audio file.
Signed-off-by: wm4 <wm4@nowhere>
(minor simplification)
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)
This also requires every hwdec backend to identify itself (see hwdec.h
changes).
If a file is unseekable (consider e.g. a http server without resume
functionality), but the stream cache is active, the player will enable
seeking anyway. Until know, client API user couldn't know that this
happens, and it has implications on how well seeking will work. So add a
property which exports whether this situation applies.
Fixes#1522.
New command `mouse <x> <y> [<button> [single|double]]` is introduced.
This will update mouse position with given coordinate (`<x>`, `<y>`),
and additionally, send single-click or double-click event if `<button>`
is given.
Repurpose demuxer->filetype for this. It used to be used to print a
human readable format description; change it to a symbolic format name
and export it as property.
Unfortunately, libavformat has its own weird conventions, which are
reflected through the new property, e.g. the .mp4 case mentioned in the
manpage.
Fixes#1504.
The "\\" escape was rendered as "\" on the website. I'm hoping quoting
this in ``...`` will render it correctly.
Also add an example for show_text, which awkwardly does not require
escaping the "\".
Make their meaning more exact, and don't pretend that there's a
reasonable definition for "bits-per-pixel". Also make unset fields
unavailable.
average_depth still might be inconsistent: for example, 10 bit 4:2:0 is
identified as 24 bits, but RGB 4:4:4 as 12 bits. So YUV formats
seemingly drop the per-component padding, while RGB formats do not.
Internally it's consistent though: 10 bit YUV components are read as
16 bit, and the padding must be 0 (it's basically like an odd fixed-
point representation, rather than a bitfield).
bpp(bits-per-pixel) and depth(bit-depth for color component) can
be calculated from pixelformat technically but it requires massive
informations to be implemented in client side.
These subproperties are provided for convenience.
Do so by using mp_subprocess(). Although this uses completely different
code on Unix too, you shouldn't notice a difference. A less ncie thing
is that this reserves an entire thread while the command is running
(which wastes some memory for stack, at least). But this is probably
still the simplest way, and the fork() trick is apparently not
implementable with posix_subprocess().
Essentially, don't make it the mmap() argument, and just add it to the
memory address. This hides tricky things like alignment reequirements
from the user.
Strictly speaking, this is not entirely backwards compatible: this adds
the regression that you can't access past 2 or 4 GB of a file on 32 bit
systems anymore. But I doubt anyone cared about this.
In theory, we could be clever, and just align the offset manually and
pass that to mmap(). This would also be transparent to the user, but
minimally more effort, so this is left as exercise to the reader.
Makes all of overlay_add work on windows/mingw.
Since we now don't explicitly check for mmap() anymore (it's always
present), this also requires us to make af_export.c compile, but I
haven't tested it.
This was requested.
It seems libdvdread can't get the duration for titlesets other than the
currently opened title. The data structures contain dangling pointers
for these, and MPlayer works this around by opening every title
separately for the purpose of dumping the title list.
By now, input.conf is actually just a small part of input handling.
Rename the section to something else ("command interface" was the
first reasonable thing that came to mind).
Also fix a minor typo further down.
The fact that it's a generic command prefix that is parsed even when
using the client API is a bit unclean (because this flag makes sense
for actual key-bindings only), but it's less code this way.
This command was actually requested on IRC ages ago, but I forgot about
it.
The main purpose is that the decoding state can be reset without issuing
a seek, in particular in situations where you can't seek.
This restarts decoding from the middle of the packet stream; since it
discards the packet buffer intentionally, and the decoder will typically
not output "incomplete" frames until it has recovered, it can skip a
large amount of data.
It doesn't clear the byte stream cache - I'm not sure if it should.
Probably needs to be polished a bit more. Also, might require a key
binding that can set/clear the loop points in a more intuitive way.
For now, something like this can be put into input.conf to use it:
ctrl+y set ab-loop-a ${time-pos} # set A
ctrl+x set ab-loop-b ${time-pos} # set B
ctrl+c set ab-loop-a no # clear (mostly)
Fixes#1241.
Due to the current code structure, the "current" entry and the entry
which is playing can be different. This is probably silly, but still
try to mark the entries correctly.
Refs #1260.
This actually doesn't even write/return the new sub-property, because
I dislike the idea of dumping that field for every single playlist
entry, even though it's "needed" only for one.
Fixes#1260.
This might be interesting for GUIs and such.
It's probably still a little bit insufficient. For example, the filter
and audio/video output lists are not available through this.
Call VOCTRL_GET_DISPLAY_NAMES it when the property is
requested. The vo should return the names of the displays that the mpv
window is covering. For example, with x11 vos, xrandr names LVDS1,
HDMI1, etc.
No development activity (or even any sign of life) for almost a year.
A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.
Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
So a client API user can know when a window is created or destroyed.
Also might be useful for the OSC: it could disable itself if video is
disabled.
Before this commit, there were only indirect ways of detecting this.
The behavior of reverse cycling (with the "!reverse" magic value) was a
bit weird and acted with a "delay". This was because the command set the
value the _next_ command should use. Change this and make each command
invocation select and use the next command directly. This requires an
"uninitialized" special index in the counter, but that is no problem at
all.
Allows properly changing/updating the cursor state. Useful for client
API window embedding, because the host application may not want the mpv
window to grab mouse input, and this has to manually handle the cursor.
Changing the cursor of foreign windows is usually not sane.
It might make sense to allow changing the cursor icon, but that would be
much more complicated, so I won't add it unless someone actually
requests it.
Whether you consider the semantics weird or not depends on your use
case, but I suppose it's a bit confusing anyway. At this point, we keep
MPV_EVENT_PAUSE/UNPAUSE for compatibility only.
Make the "core-idle" property somewhat more useful in this context.
For the sake of libmpv. Might make things much easier for the user,
especially on Windows. On the other hand, it's a bit sketchy that a
command exists that makes the player access arbitrary memory regions.
(But do note that input commands are not meant to be "secure" and never
were - for example, there's the "run" command, which obviously allows
running random shell commands.)
Use percent-pos instead, which is exactly the same, except with the
range 0.0-100.0.
I'm not sure how this got there; it was probably introduced and then
removed again as percent-pos got more precise.
CC: @mpv-player/stable
We don't allow this by default, because it would be silly if random
external data (like filenames or file tags) could accidentally trigger
them.
Add a property that magically disables this ASS tag escaping.
Note that malicious input could still disable ASS tag escaping by
itself. This would be annoying but harmless.
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.)
In particular, use the note markup. The issue about rounded timestamps
is mostly with respect to Matroska (which usually rounds them to
milliseconds), which somewhat adds to the reliability issue.
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.
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.
Handle --term-playing-msg at a better place.
Move MPV_EVENT_TICK hack into a separate function. Also add some words
to the client API that you shouldn't use it. (But better leave breaking
it for later.)
Handle --frames and frame_step differently. Remove the mess from the
playloop, and do it after frame display. Give up on the weird semantics
for audio-only mode (they didn't make sense anyway), and adjust the
manpage accordingly.
"loadfile filename append-play" will now always append the file to the
playlist, and if nothing is playing yet, start playback. I don't want to
change the semantics of "append" mode, so a new mode is needed.
Probably fixes issue #950.
