mpv was hardcoded to always consider the right Alt key as Alt Gr, but there
are parituclar combinations of platforms and keyboard layouts where it's more
convenient to treat the right Alt as a keyboard modifier just like the left
one.
Fixes#388
There are some use cases for this. For example, you can use it to set
defaults of automatically inserted filters (like af_lavrresample). It's
also useful if you have a non-trivial VO configuration, and want to use
--vo to quickly change between the drivers without repeating the whole
configuration in the --vo argument.
This drops the --pp option, which was probably broken for a while. The
option automatically inserted the "pp" filter. The value passed to it
was ignored (which is probably broken, it always selected maximal
quality).
Inserting this filter can be done simply with --vf=pp, so this is not
needed anymore.
We found that the stretching - although it usually improves the looks of
the fonts - is incorrect.
On DVD, subtitles can cover the full area of the picture, and they have
the same pixel aspect as the movie itself.
Too bad many commercially released DVDs use bitmap fonts made with the
wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make
these more pretty then.
We had some code for checking profiles earlier, which was removed in
commits 2508f38 and adfb71b. These commits mentioned that (working) hw
decoding was sometimes prevented due to profile checking, but I can't
find the samples anymore that showed this behavior. Also, I changed my
opinion, and I think checking the profiles is something that should be
done for better fallback to software decoding behavior.
The checks roughly follow VLC's vdpau profile checks, although we do
not check codec levels. (VLC's profile checks aren't necessarily
completely correct, but they're a welcome help anyway.)
Add a --vd-lavc-check-hw-profile option, which skips the profile check.
This commit adds the --force-window option, which will cause mpv always
to create a window when started. This can be useful when pretending that
mpv is a GUI application (which it isn't, but users pretend anyway), and
playing audio files would run mpv in the background without giving a
window to control it.
This doesn't actually create the window immediately: it only does so
only after initializing playback and when it is clear that there won't
be any actual video. This could be a problem when starting slow or
completely stuck network streams (mpv would remain frozen in the
background), or if video initialization somehow is stuck forever in
an in-between state (like when the decoder doesn't output a video
frame, but doesn't return an error either). Well, we can pretend only
so much that mpv is a GUI application.
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
By default, libavformat uses UDP for rtsp playback. This doesn't work
very well. Apparently the reason is that the buffer sizes libavformat
chooses for UDP are way too small, and switching to TCP gets rid of this
issue entirely (thanks go to Reimar Döffinger for figuring this out).
In theory, you can set buffer sizes as libavformat options, but that
doesn't seem to help.
Add an option to select the rtsp transport, and make TCP the default.
Also remove an outdated comment from stream.c.
Note that this is intentionally never done if the AO or softvolume is
different, or if the current volume control method is thought to control
system wide volume (such as ALSA) or otherwise user controllable (such
as PulseAudio). The intention is to keep things robust and to avoid
messing with the user's audio settings as far as possible, while still
providing the ability to resume volume if it makes sense.
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
This option makes the cursor always visible in windowed mode.
Apparently, this is what (some?) Windows and OSX users expect. It's
disabled by default for now.
Restructure the cursor hide logic a bit for this purpose.
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
Add --video-align-x/y, --video-pan-x/y, --video-scale options and
properties. See the additions to the manpage for description and
semantics.
These transformations are intentionally done on top of panscan. Unlike
the (now removed) --panscanrange option, this doesn't affect the default
panscan behavior. (Although panscan itself becomes kind of useless if
the new options are used.)
This option allowed you to extend the range of the panscan controls, so
that you could essentially use it to scale the video. This will be
replaced by a separate option to set the zoom factor directly.
See github issue #194.
Unfortunately, this breaks the property that going back in the playlist
always works as expected. This changes, because the playlist_prev
command will work on the reshuffled playlist, instead of loading the
previously played files in order. If this ever becomes an issue, I
might revert this commit.
If close to chapter start, skipping back goes to previous chapter (no change).
If more than <threshold> seconds in, skipping back will now go to the beginning
of the current chapter instead.
The threshold is set by the new option --chapter-seek-threshold and defaults to
5 seconds. A negative value disables the new functionality.
core is used in many unix systems for core dumps. For that reason some tools
work under the assumption that the file is indeed a core dump (for example
autoconf does this).
This commit just renames the files. The following one will change all the
includes to fix compilation. This is done this way because git has a easier
time tracing file changes if there is a pure rename commit.
