This caused complaints because the fps was basically rounded on
microsecond boundaries in the vsync interval (it seemed convenient to
store only the vsync interval). So store the fps as float too, and let
the "display-fps" property return it directly.
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.
Instead of refusing to set properties like "fullscreen" if no VO was
created, always allow it. So if no VO is created, setting the property
merely changes the options (and will be applied once the VO is created).
This is consistent with similar behavior changes to some other
properties.
Improves the behavior reported in #1676.
Also, we shouldn't check the config_ok variable - the VO should do this.
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.
The way the AO wakes up the playloop has nothing to do with events;
instead we must query the events on the AO once the playloop was woken
up. Querying the events in every playloop iteration is thus the correct
way to do this.
This commit adds notifications for hot plugging of devices. It also extends
the old behaviour of the `audio-out-detected-device` property which is now
backed by the hotplugging code. This allows clients to be notified when the
actual audio output device changes.
Maybe hotplugging should be supported for ao_coreaudio_exclusive too, but it's
device selection code is a bit fragile.
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.
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).
Opening the stream and opening the demuxer are both done asynchronously,
meaning the player reacts to client API requests. They also can
potentially take a while. Thus it's better to process outstanding
property changes, so that change events are sent for properties that
were changed during opening.
In particular, this would fix the sending the initial change event. It
was easily missed because MPV_EVENT_FILE_LOADED usually triggered it,
but the actual property could change only later, because audio
initialization really is kind of asynchronous to it.
This probably fixes#1544.
Now it shows one of:
- "Subtitles hidden" (sub-visibility=no)
- "Subtitles visible" (sub-visibility=yes, sub!=no)
- "Subtitles visible (but no subtitles selected)" (otherwise)
It should be a bit more self-explanatory than before. On the other hand,
I have no clue about UI issues.
This also gets close to what's reasonably possible with the OSD
expansion string syntax, which is why it looks so awful.
mpctx->audio_delay always has the same value as opts->audio_delay. (This
was not the case a long time ago, when the audio-delay property didn't
actually write to opts->audio_delay. I think.)
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.
`core-idle` depends on seeking state `mpctx->restart_complete`,
so make `core-idle` notified whenever `seeking` is notified, too.
`paused-for-cache` can be changed on MPV_EVENT_CACHE_UPDATE obviously.
Finally, `MPV_EVENT_PLAYBACK_RESTART` should be notified after
`mpctx->restart_complete` changed.
The "ontop" and "border" properties already used a common
mp_property_vo_flag() function, and the corresponding VOCTRLs used the
same conventions. "fullscreen" is pretty similar, but was handled
slightly similar. Change how VOCTRL_FULLSCREEN behaves, and use the same
helper function for "fullscreen" as the other flags.
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.
If there's only 1 chapter, the seeking by chapter (using the chapter
property) will either jump to the chapter point, or quit playback. This
is as designed, but seems like a useless and annoying behavior.
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().
If a filter exists, but has no metadata, just return success. This
allows the user to distinguish between no metadata available, and filter
not inserted.
See #1408.
Until now, these options took effect only at program start. This could
be confusing when e.g. doing "mpv list.m3u --shuffle". Make them always
take effect when a playlist is loaded either via a playlist file, or
with the "loadlist" command.
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.
Padding with spaces is very useless for OSD (because most fonts are
variable width), but it's good when using it on the terminal, e.g. for
reproducing the default terminal status line.
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.