| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
| |
This brings the volume control closer to what is percepted as linear
volume change.
Adjust the --softvol-max default to roughly the old maximum (roughly
doubles the gain).
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This means if --hwdec is used, and hardware decoding is supported for
HEVC, it's actually used.
|
| |
|
|
|
|
|
| |
When --no-video is set, the ytdl-format is set to "bestaudio/best". This
wasn't documented in the man page yet.
|
|
|
|
|
|
|
| |
This creates the window before the first file is loaded. This was
requested a bunch of times, but on the other hand a change to make this
behavior the default was reverted some time ago, because other users
hated it.
|
| |
|
|
|
|
| |
Minor user convenience.
|
| |
|
|
|
|
|
|
|
|
| |
This should take care of the endless complaints about the default
location for screenshots (and will of course create new ones).
If the screenshot-template is set to an absolute path, the directory
won't be used. So this should be reasonably compatible.
|
|
|
|
|
|
| |
So that the user realizes where they come from, or can find them at all.
This was a common complaint, and this is the most lazy solution. Better
suggestions for a default template are welcome.
|
|
|
|
|
| |
The plan is to use this to change the screenshot default location in
pseudo-gui mode.
|
|
|
|
| |
That's what it's usually about (again).
|
|
|
|
| |
That's what it's usually about.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This was basically requested.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
| |
Why did this exist in the first place? Other than being completely
useless, this even caused some regressions in the past. For example,
there was the case of a laptop exposing its accelerometer as joystick
device, which led to extremely fun things due to the default mappings of
axis movement being mapped to seeking.
I suppose those who really want to use their joystick to control a media
player (???) can configure it as mouse device or so.
|
|
|
|
| |
It's much easier to configure remotes as X11 input devices.
|
|
|
|
|
|
|
| |
It's relatively stable now.
Also fix a typo in an unrelated place (better not waste commits on
typos).
|
|
|
|
|
|
| |
I think this is what I alwass missed ever since I found the MPlayer
cache options: a way to enable the cache on local files with the default
settings, whatever they are.
|
|
|
|
| |
(Well, almost 150MB.)
|
|
|
|
| |
Fixes #1615.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
e141caa97dade07f4d7e0d6c208bcd3493e712ed
653b0dd5295453d9661f673b4ebd02c5ceacf645
729c8b3f641e633474be612e66388c131a1b5c92
fbacd5de31de964f7cd562304ab1c9b4a0d76015
Fixes #1636.
|
|
|
|
|
|
| |
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 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>
|
|
|
|
|
| |
No "modified libass" is needed anymore. Also, it said that the "force"
choice is more reliable than "force", which makes no sense.
|
|
|
|
|
| |
Maybe I don't know what I'm doing. I'm fairly certain though that Intel
does not know what they're doing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Not quite sure if this actually works as intended.
Fixes #1566.
|