Move the command line parsing and some other things to the common init
routine shared between command line player and client API. This means
they're using almost exactly the same code now.
The main intended side effect is that the client API will load mpv.conf;
though still only if config loading is enabled.
(The cplayer still avoids creating an extra thread, passes a command
line, and prints an exit status to the terminal. It also has some
different defaults.)
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.
This automatically sets the gamma option depending on lighting conditions
measured from the computer's ambient light sensor.
sRGB – arguably the “sibling” to BT.709 for still images – has a reference
viewing environment defined in its specification (IEC 61966-2-1:1999, see
http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the
assumed ambient illuminance is 64 lux. This is the illuminance where the gamma
that results from ICC color management is correct.
On the other hand, BT.1886 formalizes that the gamma level for dim environments
to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for
color management) define the BT.1886 dim at 16 lux.
So the logic we apply is:
* >= 64lux -> 1.961 gamma
* =< 16lux -> 2.400 gamma
* 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human
perception of illuminance roughly follows a logaritmic scale of lux [1].
[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
Breaks vo_opengl by default. I'm hot able to fix this myself, because I
have no clue about the overcomplicated color management logic. Also,
whilethis is apparently caused by commit fbacd5, the following commits
all depend on it, so revert them too.
This reverts the following commits:
e141caa97d653b0dd529729c8b3f64fbacd5de31Fixes#1636.
Just use makeFirstResponder on the mpv events view from client code
if you need the built in keyboard events (this is easier for dealing with view
nesting).
This relies on upstream support in lavc, and will hence basically not
work at all. The intent is to get support for writing this information
into ffmpeg's PNG encoders etc.
Now that we have fast stream switching, we can bump these sizes, as the
queues cause no delay in switching anymore.
Of course, the fast stream switching works for mkv and mp4 only. Other
formats will incur a quite terrible delay especially in network mode,
which this commit changes to 10 seconds. Let's see if someone
complains...
The way I interpreted it, it seemed like this was not default behavior
and could be enabled with --audio-pitch-correction - it should be made
clearer that this is actually *the default behavior*.
This is based on pretty much the same (somewhat naive) logic right now.
I'm not convinced that the extra logic that eg. madVR includes is worth
enough to warrant heavily confusing the logic for it.
This shouldn't slow down the logic at all in any sane shader compiler,
and indeed it doesn't on any shader compiler that I tested.
Note that this currently doesn't affect cscale at all, due to the weird
implementation details of that.
This option allows the user to pass non-supported options directly to
youtube-dl, such as "--proxy URL", "--username USERNAME" and
'--password PASSWORD".
There is no sanity checking so it's possible to break things (i.e.
if you pass "--version" mpv exits with random JSON error).
Signed-off-by: wm4 <wm4@nowhere>
Hopefully, this will really clear up how the thing is supposed to work
(and that it's not SVP, nor MVTools).
I also removed instances of the word "interpolation", since that's a
term that's easily misleading.
Finally, I expanded on smoothmotion-threshold since the purpose/meaning
was a bit confusing.
This is done mainly for consistency, since all of the EWA filters share
similar properties and it's important to distinguish them for
documentation purposes.
This is a variation of ewa_lanczos that is sinc-windowed instead of
jinc-windowed. Results are pretty similar, but the logic is simpler.
This could potentially replace the ugly ewa_lanczos code.
It's hard to tell, but from comparing stills I think this one has
slightly less ringing than regular ewa_lanczos.
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.
You can set in which "corner" the OSD and subtitles are shown. I'd
prefer it a bit more general (so you could set the alignment using
a factor), but the libass API does not provide this.
Requested. See manpage additions.
This also makes the magical loop_times constants slightly saner, but
shouldn't change the semantics of any existing --loop option values.
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.
In my opinion the artifacts created by af_scaletempo on extreme slowdown
(50% or so) are too bothersome - but users disagree. So use
af_scaletempo on any speed changes, not just on speedup.
librubberband exports a big load of options. Normally, the default
settings (whether they're librubberband defaults or our defaults) should
be sufficient, but since I'm not so sure about this, making it
configurable allows others to figure it out for me.
If "--af=rubberband" is used, librubberband will be used to speed up or
slow down audio with pitch correction.
This still has some problems: the audio delay is not calculated
correctly, so the audio position jitters around by a few milliseconds.
This will probably ruin video timing.
This reverts commit a33b46194c.
It turns out FFmpeg really considers this a bug, and fixed it by making
the decoder output the correct pixel format.
Fixes#1565. Reverts the fix#1528, though it should work fine with
a recent git master FFmpeg.
Make it accept "," as separator, instead of only ":". Do this by using
the key-value-list parser. Before this, the option was stored as a
string, with the option parser verifying that the option value as
correct. Now it's stored pre-parsed, although the log levels still
require separate verification and parsing-on-use to some degree (which
is why the msg-level option type doesn't go away).
Because the internal type changes, the client API "native" type also
changes. This could be prevented with some more effort, but I don't
think it's worth it - if MPV_FORMAT_STRING is used, it still works the
same, just with a different separator on read accesses.
This introduces a new option linear-scaling, which is now implied by
srgb, icc-profile and sigmoid-upscaling.
Notably, this means (sigmoidized) linear upscaling is now enabled by
default in opengl-hq mode. The impact should be negligible, and there
has been no observation of negative side effects of sigmoidized scaling,
so it feels safe to do so.
Autoload external audio files only if there's at least a video track
(which is not coverart pseudo-video).
Enable external audio file autoloading by default. Now that we actively
avoid doing stupid things like loading an external audio file for an
audio-only file, this should be fine.
Additionally, don't autoload subtitles if a subtitle is played.
Although you currently can't play subtitles without audio or video,
it's disturbing and stupid that the player might load subtitle files
with different extension and then fail.
Giving this such a prominent place is not really appropriate anymore.
Most people seeing this would probably expect a release changelog, not
something about MPlayer.
Since the page still could be useful for former MPlayer users (in
particular to avoid confusion with renamed options etc.), still keep
it in the DOCS directory.
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.
In ancient times, this was needed because it was not default, and many
VOs had problems with it. But it was always default in mpv, and all VOs
are required to deal with it. Also, running --fixed-vo=no is not useful
and just creates weird corner cases. Get rid of it.
Comment explains why I have been so doubtful at adding this. The Apple docs
say CGDisplayModeGetRefreshRate is supposed to work only for CRTs, but it
doesn't, and actually works for LCD TVs connected over HDMI and external
displays (at least that's what I'm told, I don't have the hardware to test).
Maybe Apple docs are incorrect.
Since AFAIK Apple doesn't want to give us a better API – maybe in the fear we
might be able to actually write some useful software instead of "apps" –
I decided not to care as well and commit this.
This reverts the default behavior introduced in commit 93feffad. Way too
often libavcodec will return RGB data that has an alpha channel as per
pixel format, but actually contains garbage.
On the other hand, this will actually render garbage color values in
e.g. PNG files (for pixels with alpha==0, the color value should be
essentially ignored, which is what the old alpha blend mode did).
This "fixes" #1528, which is probably a decoder bug (or far less likely,
a broken file).
Make the lazy gamma initialization less weird, and make the default
value of the "gamma" sub-option 1.0. This means --vo=opengl:help will
list the actual default value.
Also change the lower bound to 0.1 - avoids a division by zero (I don't
know how shaders handle NaN, but it's probably not a good idea to give
them this value).
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)
These were derived from dividing our assumed video gamut (1.961) by some
typical screen values (2.2 for dimly lit and 2.4 for pitch black):
1.961/2.4 = 0.8170833333333334 ~= 0.8
1.961/2.2 = 0.8913636363636364 ~= 0.9
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).
This does what it's documented to do.
The implementation reuses the code in mpv_detach_destroy(). Due to the
way async requests currently work, just sending a synchronous dummy
request (like a "ignore" command) would be enough to ensure
synchronization, but this code will continue to work even if this
changes.
The line "ctx->event_mask = 0;" is removed, but it shouldn't be needed.
(If a client is somehow very slow to terminate, this could silence an
annoying queue overflow message, but all in all it does nothing.)
Calling mpv_wait_async_requests() and mpv_wait_event() concurrently is
in theory allowed, so change pthread_cond_signal() to
pthread_cond_broadcast() to avoid missed wakeups.
As requested in issue #1542.
This was apparently useful for correct interlaced scaling (although I
don't know anyone who used this). It was rarely used (if at all), had an
inconvenient output format (packed YUV), and now has a better solution
in libavfilter (using the libavfilter "scale" filter via vf_lavfi).
There is no reason to keep this filter any longer.
It's entirely useless. I left it in for a while, because the analog TV
code had a transitional bug that could switch chroma planes, but it was
fixed long ago. It's also available in libavfilter.
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.
This allows getting the log at all with --no-terminal and without having
to retrieve log messages manually with the client API. The log level is
hardcoded to -v. A higher log level would lead to too much log output
(huge file sizes and latency issues due to waiting on the disk), and
isn't too useful in general anyway. For debugging, the terminal can be
used instead.
The previous default ("no") seemed to be equivalent to "min" in practice
(though it might depend on the website, which is even worse).
Better just select the best stream by default.
This queries the _ICC_PROFILE property on the root window. It also tries
to reload the ICC when it changes, or if the mpv window changes the
monitor. (If multiple monitors are covered, mpv will randomly select one
of them.)
The official spec is a dead link on freedesktop.org, so don't blame me
for any bugs.
Note that this assumes that Xinerama screen numbers match the way mpv
enumerates the xrandr monitors. Although there is some chance that this
matches, it most likely doesn't, and we actually have to do complicated
things to map the screen numbers. If it turns out that this is required,
I will fix it as soon as someone with a suitable setup for testing the
fix reports it.
Seems like several people agree that it's a good filter for downscaling.
Setting this option by default may also prevent people from accidentally
using an unsuitable filter for downscaling by setting "scale" and
without being aware of the impliciations (maybe). On the other hand,
this change is not strictly backwards compatible for the same reasons.
Also, allow disabling this option with scale-down="" (before this, not
setting it was the only way to do this - not possible anymore if it's
set by default). This is what the change in handle_scaler_opt() does.
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.
vo.c queried the VO at initialization whether it wants to be updated on
every display frame, or every video frame. If the smoothmotion option
was changed at runtime, the rendering mode in vo.c wasn't updated.
Just let vo_opengl set the mode directly. Abuse the existing
vo_set_flip_queue_offset() function for this.
Also add a comment suggesting the use of --display-fps to the manpage,
which doesn't have anything to do with the rest of this commit, but is
important to make smoothmotion run well.
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 symlink trick made waf go crazy (deleting source files, getting
tangled up in infinite recursion... I wish I was joking). This means we
still can't build the client API examples in a reasonable way using the
include files of the local repository (instead of globally installed
headers). Not building them at all is better than deleting source files.
Instead, provide some manual instructions how to build each example
(except for the Qt examples, which provide qmake project files).
SmoothMotion is a way to time and blend frames made popular by MadVR. It's
intended behaviour is to remove stuttering caused by mismatches between the
display refresh rate and the video fps, while preserving the video's original
artistic qualities (no soap opera effect). It's supposed to make 24fps video
playback on 60hz monitors as close as possible to a 24hz monitor.
Instead of drawing a frame once once it's pts has passed the vsync time, we
redraw at the display refresh rate, and if we detect the vsync is between two
frames we interpolated them (depending on their position relative to the vsync).
We actually interpolate as few frames as possible to avoid a blur effect as
much as possible. For example, if we were to play back a 1fps video on a 60hz
monitor, we would blend at most on 1 vsync for each frame (while the other 59
vsyncs would be rendered as is).
Frame interpolation is always done before scaling and in linear light when
possible (an ICC profile is used, or :srgb is used).
These aliases were removed in commit 1ec77214. Add a notice to the
manpage how to get these back. Apparently, "lanczos2" and "lanczos3"
were the only interesting aliases possibly used by someone, so the
description is limited to these two.
These are now auto-detected sanely; and enabled whenever it would be a
performance or quality gain (which is pretty much everything except
bilinear/bilinear scaling).
Perhaps notably, with the absence of scale_sep, there's no more way to
use convolution filters on hardware without FBOs, but I don't think
there's hardware in existence that doesn't have FBOs but is still fast
enough to run the fallback (slow) 2D convolution filters, so I don't
think it's a net loss.
This is better even for non-separable. The only exception is when using
bilinear for both lscale and cscale. I've fixed the
documentation/comments to make more sense.
This is not quite the same thing as madVR's antiringing algorithm, but
it essentially does something similar.
Porting madVR's approach to elliptic coordinates will take some amount
of thought.
This also fixes the maximum range to 16.0, which was previously set to
32.0 and incorrectly documented as 8.0. 16 taps should be more than
anybody will ever need, but it's the highest radius that's supported by
all affected filters.
Before this, we merely printed a message to the terminal. Now the API
user can determine this properly. This might be important for API users
which somehow maintain complex state, which all has to be invalidated if
(state-changing) events are missing due to an overflow.
This also forces the client API user to empty the event queue, which is
good, because otherwise the event queue would reach the "filled up"
state immediately again due to further asynchronous events being added
to the queue.
Also add some minor improvements to mpv_wait_event() documentation, and
some other minor cosmetic changes.
Fixes#1472.
(Maybe these options should have been named --autofit-max and
--autofit-min, but since --autofit-larger already exists, use
--autofit-smaller for symmetry.)
