| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This was in the "Window" section. It has absolutely nothing to do with
windows. Move it to the "Miscellaneous" section instead. The "--mc"
option, which has a similar function, was already there.
|
| |
|
|
| |
Requested. Works similar to the property with the same name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build failed because rst2pdf apparently has problems with
page breaks. In this case, the link to the ALSA upmix guide was
causing a page break in an admonition block. My guess is that
rst2pdf screws up when it can’t fill at least one line of text
following a page break, so I worked around this by making that
paragraph a little longer. Seems to do the trick.
I also shortened the URL using GitHub’s service because it was
causing some rather unsightly formatting in the manpage output.
Maybe we should just build HTML instead of a PDF.
|
| |
|
|
|
|
|
|
|
|
| |
Since joystick support was removed and is a difference from mplayer, it
should be included in the document with the mplayer changes.
It will help new users who were using mplayer's joystick support to
seek alternatives when switching to mpv. It will also be helpful for
people that had problems with the joystick support in mplayer (for
example, by incorrectly recognizing other input devices as joystick)
to know that those problems won't persist in mpv.
|
| | |
|
| |
|
|
|
| |
And also fix the description. It didn't actually reflect what the code
did.
|
| |
|
|
|
| |
There is some potential for breakage. If it happens, this might have to
be disabled by default.
|
| |
|
|
| |
Requested. Why not.
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
Requested.
The wild code for setting up the mpv_node probably deserves to be
cleaned up later.
Fixes #1800.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This will be used in the following commit, which adds screenshot_raw.
The reasoning is that this will be better for binding scripting
languages.
One could special-case the screenshot_raw commit and define fixed
semantics for passing through a pointer using the current API, like
formatting a pointer as string. But that would be ridiculous and
unclean.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This property indicates whether mouse cursor is located on button
or not for disc naviation.
|
| | |
|
| |
|
|
|
|
|
|
| |
Useful for dealing with libavfilter's terrible graph syntax.
Not strictly backwards compatible (for example "[a[b]" fails now - the
"[" within the quote is interpreted now). But hopefully it's obscure
enough not to warrant any kind of compatibility hacks.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It's entirely useless, especially now that vo.c handles screenshots in a
generic way, and requires no special VO support. There are some
potential weird use-cases, but actually I've never seen it being used.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
libavcodec makes it impossible to distinguish dropped frames (requested
with AVCodecContext.skip_frame), and cases when the decoder simply does
not return a frame by default (such as with VP9, which has invisible
reference frames).
This confuses users when decoding VP9 video. It's basically a cosmetic
issue, so just paint it over by ignoring them if framedropping is
disabled.
|
| | |
|
| |
|
|
|
|
| |
It seems this choice was never documented. "always" is actually older
than "yes", so just declare it a compatibility value for "yes". (Also
move it before "always" in the C code to make this clear.)
|
| | |
|
| | |
|
| |
|
|
|
| |
Supposedly this is not an issue anymore after we've changed the code to
use texture-from-pixmap.
|
| |
|
|
|
| |
Use a choice instead of an integer. This is incompatible, but I'm not
adding any compatibility since this option was added recently.
|
| |
|
|
|
|
| |
I tried to find that option by searching for terms like “cover art”
and got nothing. I imagine most users would look for similar terms.
Hope this helps.
|
| |
|
|
|
|
|
| |
This commit is to prevent changes being merged into upstream, without
being known if it is tested or not.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
| |
The gender specific pronoun is changed, since we shouldn't assume the
gender of the user.
The sentence itself is also changed to be more correct in general.
|
| | |
|
| | |
|
| |
|
|
|
| |
This can be used to draw the subtitles at the video's native res, which
can make them look more natural and increases performance.
|
| | |
|
| |
|
|
|
|
|
| |
This could help in cases where the DWM (Windows desktop compositor) adds another
layer of bufferring and therefore the SwapBuffers timing could get messed up.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
| |
Its vp parameter made no sense anymore. Introduce a new one.
|
| |
|
|
|
|
|
| |
And also let vo.c know of it.
Currently, this does not help much, but will facilitate future
improvements.
|
| |
|
|
|
|
| |
This seems to come up often. I guess '.' vs. ':' for Lua calls is
confusing, and this part of the scripting API is the only one which
requires using it.
|
| |
|
|
|
|
| |
There still might be FFmpeg demuxers which mess up if audio is disabled
(like it happened to the FLV demuxer), but these are bugs and shouldn't
happen.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With target-prim and target-trc it makes sense to include some common
colorspaces that aren't strictly speaking used for video.
|
| |
|
|
| |
Brings it in line with changes to vo_opengl options.
|
| |
|
|
| |
No real reason this is disabled with the new configuration API.
|
| |
|
|
| |
This lets us tune the window parameter
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
|
| |
|
|
|
| |
Makes vf_dsize completely useless. Unfortunately, even our "official"
encoding profiles still use it.
|
| | |
|
| |
|
|
| |
Terribly obscure, and vf_format can do this for all VOs.
|
| | |
|
| | |
|
| |
|
|
| |
This was basically requested.
|
| |
|
|
|
| |
remove depricated and convoluted validation. refer instead to the
--audio-device option.
|
| | |
|
| |
|
|
| |
(Stupid Unix conventions.)
|
| |
|
|
|
| |
Include 360 in the range and don't stop at 359. This makes cycling
through the range in 90° steps less awkward.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the colorspace-related top-level options, add them to vf_format.
They are rather obscure and not needed often, so it's better to get them
out of the way. In particular, this gets rid of the semi-complicated
logic in command.c (most of which was needed for OSD display and the
direct feedback from the VO). It removes the duplicated color-related
name mappings.
This removes the ability to write the colormatrix and related
properties. Since filters can be changed at runtime, there's no loss of
functionality, except that you can't cycle automatically through the
color constants anymore (but who needs to do this).
This also changes the type of the mp_csp_names and related variables, so
they can directly be used with OPT_CHOICE. This probably ended up a bit
awkward, for the sake of not adding a new option type which would have
used the previous format.
|
| |
|
|
|
|
|
| |
It was "by design" possible to make mpv crash if the parameters didn't
make enough sense, like "format=rgb24:yuv420p". While forcing the format
has some minor (rather questionable) use for debugging, allowing it to
crash is just stupid.
|
| |
|
|
|
|
| |
Instead of forcing a useless format (packed YUV??) by default.
Also cleanup.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires FFmpeg git master for accelerated hardware decoding.
Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav
will also work.
Most things work. Screenshots don't work with accelerated/opaque
decoding (except using full window screenshot mode). Subtitles are
very slow - even simple but huge overlays can cause frame drops.
This always uses fullscreen mode. It uses dispmanx and mmal directly,
and there are no window managers or anything on this level.
vo_opengl also kind of works, but is pretty useless and slow. It can't
use opaque hardware decoding (copy back can be used by forcing the
option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend
is preferred over the X11 ones in case you're trying on X11; but X11
is even more useless on RPI.
This doesn't correctly reject extended h264 profiles and thus doesn't
fallback to software decoding. The hw supports only up to the high
profile, and will e.g. return garbage for Hi10P video.
This sets a precedent of enabling hw decoding by default, but only
if RPI support is compiled (which most hopefully it will be disabled
on desktop Linux platforms). While it's more or less required to use
hw decoding on the weak RPI, it causes more problems than it solves
on real platforms (Linux has the Intel GPU problem, OSX still has
some cases with broken decoding.) So I can live with this compromise
of having different defaults depending on the platform.
Raspberry Pi 2 is required. This wasn't tested on the original RPI,
though at least decoding itself seems to work (but full playback was
not tested).
|
| |
|
|
| |
This was requested, more or less.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has a number of user-visible changes:
1. A new flag blend-subtitles (default on for opengl-hq) to control this
behavior.
2. The OSD itself will not be color managed or affected by
gamma controls. To get subtitle CMS/gamma, blend-subtitles must be
used.
3. When enabled, this will make subtitles be cleanly interpolated by
:interpolation, and also dithered etc. (just like the normal output).
Signed-off-by: wm4 <wm4@nowhere>
|
