Remove the (now unused) code for determining correct-pts mode based on
the demuxer in use. Change its description in the manpage to reflect
what this option does now.
Doing e.g. show_text "${time-pos/full}" will show the time formatted
with a milliseconds part.
This is actually special cased for a few properties which use
CONF_TYPE_TIME, instead of making all properties using CONF_TYPE_TIME
respect this. This is a technical limitation.
I'm not entirely happy with this approach, so I'll leave it
undocumented. It's relatively ok, but he fact that it's special-cased to
some properties is not elegant. So for now, this is just a hack to make
ChrisK2 happy (hi there).
The "options" pseudo-property allows reading global like this:
show_text ${options/name}
Where "name" maps to the option "--name". This allows retrieving option
values that are not properties. Write-access is not possible: this is
reserved for normal properties.
Note: it is possible that we'll change this again, and don't require the "options/" prefix to access options.
The --profile top-level option is handled specially in m_config.c. But
this code also broke sub-options that happened to be named "profile"
(e.g. when trying to use "-af-add=bs2b=profile=cmoy"). Handle it
specially only if it's the top-level --profile option.
This didn't setup the linked list of sub-commands for multi-part
commands ("a ; b ; c") correctly. Also, the new commands were attached
to the allocation of the _old_ command instead of the new one. (Wow,
whatever the hell I was (not) thinking when I wrote this code.)
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
Commit 9a83d03 accidentally removed this. (Overlooked "static"?)
The handling of this rather sucks. Maybe a better solution will be
possible once we clean up the mp_msg code.
This also affects --audiofile. The previous behavior wasn't really
useful. There are even separate switches for that: --audio-demuxer and
--sub-demuxer.
Make the VF/VO/AO option parser available to audio filters. No audio
filter uses this yet, but it's still a quite intrusive change.
In particular, the commands for manipulating filters at runtime
completely change. We delete the old code, and use the same
infrastructure as for video filters. (This forces complete
reinitialization of the filter chain, which hopefully isn't a problem
for any use cases. The old code forced reinitialization too, but it
could potentially allow a filter to cache things; e.g. consider loaded
ladspa plugins and such.)
These two options were supported by ALSA and OSS only. Further, their
values were specific to the respective audio systems, so it doesn't make
sense to keep them as top-level options.
The AO creation part was split into two separate parts (one calling
ao_create and one calling ao_init). This didn't really have good
reasons, and obfuscates how AO creation works. Put them together.
Nothing should change from user perspective.
mpv --vo=opengl:help now works.
Remove the vo_opengl inline help text. The new code can list option
names for you, but that's it. Refer to the manpage if you have trouble.
This is in preparation of making VOs and AOs use the parser which
originally was for video filters only.
The --vo and --ao options have several very annoying features, which are
added here:
- They can skip unknown video outputs (might be useful if a config file
is supposed to work on several systems, where not all VOs/AOs are
available everywhere)
- The trailing "," in "-vo a,b," was significant, and meant that if "a"
and "b" don't work, try the normal autoprobe order as fallback
- There were deprecated VO names (like "gl3" and "gl"), which have to be
handled with the option parser
- Separating VO/VF names and options is different
("-vf foo=opts" vs. "-vo foo:opts")
- vo_opengl.c provides opengl-hq as opengl + preset options
This is printed with --list-options or e.g. --vf=lavfi=help.
Note that in theory, the options should be able to print their own help,
and we shouldn't special case certain types (like m_option_type_choice
in the commit). But that is too hairy for now, so we don't do it.
For some reason, both m_config and m_struct are somewhat similar, except
that m_config is much more powerful. m_config is used for VOs and some
other things, so to unify them. We plan to kick out m_struct and use
m_config for everything. (Unfortunately, m_config is also a bit more
bloated, so this commit isn't all that great, but it will allow to
reduce the option parser mess somewhat.)
This commit also switches all video filters to use the option macros.
One reason is that m_struct and m_config, even though they both use
m_option, store the offsets of the option fields differently (sigh...),
meaning the options defined for either are incompatible. It's easier to
switch everything in one go.
This commit will allow using the -vf option parser for other things,
like VOs and AOs.
Windows generates WM_MOUSEMOVE messages internally whenever the window
manager wants to know where the mouse is[1] and broadcasts that to
everyone; w32_common doesn't check whether the position is different
and just (indirectly) calls this.
Do the check on input.c since it's possible some other VO or frontend
also do the same thing.
[1]: http://blogs.msdn.com/b/oldnewthing/archive/2003/10/01/55108.aspx
There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and
VOFLAG_FULLSCREEN. Remove all these and introduce a
mp_vo_opts.fullscreen flag instead.
When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the
current fullscreen mode to the state in mp_vo_opts.fullscreen. They
also should do this implicitly on config().
VOs which are capable of doing so can update the mp_vo_opts.fullscreen
if the actual fullscreen mode changes (e.g. if the user uses the
window manager controls). If fullscreen mode switching fails, they
can also set mp_vo_opts.fullscreen to the actual state.
Note that the X11 backend does almost none of this, and it has a
private fs flag to store the fullscreen flag, instead of getting it
from the WM. (Possibly because it has to deal with broken WMs.)
The fullscreen option has to be checked on config() to deal with
the -fs option, especially with something like:
mpv --fs file1.mkv --{ --no-fs file2.mkv --}
(It should start in fullscreen mode, but go to windowed mode when
playing file2.mkv.)
Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com>
Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of
the normal video format negotiation. The colorspace is passed down like
other video params with config/reconfig calls.
Forcing colorspaces (via the --colormatrix options and properties) is
handled differently too: if it's changed, completely reinit the video
chain. This is slower and requires a precise seek to the same position
to perform an update, but it's simpler and less bug-prone. Considering
switching the colorspace at runtime by user-interaction is a rather
obscure feature, this is a good change.
The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it,
and would have to be changed to get rid of them. We'll do that later,
and convert them incrementally instead of in one go.
Note that controlling the output range now always works on VO level.
Basically, this means you can't get vf_scale to output full-range YUV
for whatever reason. If that is really wanted, it should be a vf_scale
option. the previous behavior didn't make too much sense anyway.
This commit fixes a few bugs (such as playing RGB video and converting
that to YUV with vf_scale - a recent commit broke this and forced the
VO to display YUV as RGB if possible), and might introduce some new
ones.
From now on, usage of these macros is encouraged over using FFMAX and
FFMIN. FFMAX and FFMIN are perfectly fine, and the added macros are
actually exactly the same as the FFMAX and FFMIN definitions. But they
require including libavutil headers, and certain differences between
Libav and FFmpeg very often introduced breakages if these macros were
somehow not defined because a header was not recursively included.
Defining this macro on our own is the best way to escape from this
annoying issue.
DVD playback had some trouble with PTS resets: libavformat's genpts
feature would try reading until EOF (worst case) to find a new usable
PTS in case a packet's PTS is not set correctly. Especially with slow
DVD access, this would make the player to appear frozen.
Reimplement it partially in demux_lavf.c, and use that code in the DVD
case. This is heavily "inspired" by the code in av_read_frame from
libavformat/utils.c. The difference is that we stop reading if no PTS
has been found after 50 packets (consider this a heuristic). Also, we
don't bother with the PTS wrapping and last-frame-before-EOF handling.
Even with normal PTS wraps, the player frontend will go to hell for the
duration of a frame anyway, and should recover quickly after that.
The terribleness of this commit is mostly that we duplicate libavformat
functionality, and that we suddenly need a packet queue.
Move the reading loop from read_all_fd_events to read_events. If
got_new_events is set when calling read_events, don't actually wait
and set the timeout to 0.
(Note that not waiting is sort of transparent to the caller: the caller
is just supposed to execute the event loop again, and then it will
actually wait. mplayer.c handles this correctly.)
This might reduce latency with some input sources.
Removes some code duplication. Also restructure the input waiting code
a bit: split the select() loop into a input_wait_read() function. On
systems which do not have POSIX select(), this function has an alternate
implementation, which waits unconditionally.
This was useless for anything but the raw demuxers. In most cases, this
would most likely lead to display of bogus duration values, because the
bitrates used are per-track, not the total file bitrate. There was
actually no case left where this code was helpful.
Note that demux_lavf has its own code for this using the total file
bitrate. Also, mplayer.c can calculate the playback percentage from
current file position / current file size. This is not removed.
All demuxers make a reasonable effort to set packet timestamps, and thus
support correct-pts mode. This commit also implicitly switches
demux_rawvideo to correct-pts mode.
We still allow demuxers to disable correct-pts mode in theory.
Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants.
Instead of having two open functions for the demuxer callbacks (which
somehow are both optional, but you can also decide to implement both...),
just have one function. This function takes a parameter that tells the
demuxer how strictly it should check for the file headers. This is a
nice simplification and allows more flexibility.
Remove the file extension code. This literally did nothing (anymore).
Change demux_lavf so that we check our other builtin demuxers first
before libavformat tries to guess by file extension.
