| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
| |
Undefined behavior.
|
|
|
|
|
| |
getch2 now deals with the cases where we don't have termcap. Add a dummy
load_termcap to getch2-win so we don't get linking errors on mingw.
|
|
|
|
|
| |
A cygwin mpv will usually run inside mintty, and even if it were to be run
in a regular console window, the cygwin dll emulates ANSI escapes.
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
Attached pictures are now handled specially and on a separate codepath,
so this hack is not needed anymore. Remove it from the normal codepath.
|
|
|
|
|
|
| |
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).
|
|
|
|
|
| |
This means that AOs/VOs with no options set do not take the legacy
option parsing path, but instead report that they have no options.
|
|
|
|
| |
Finally not used by anything anymore. Farewell.
|
|
|
|
| |
Also get rid of the useless comment.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
These can't be used manually. Encoding is enabled with -o instead, and
the encoding AO/VO is selected using internal mechanisms.
|
|
|
|
| |
This requires completely refactoring the AO creation code too.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This remained stuck at no selection.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Sigh, why does this happen all the time...
|
| |
|
|
|
|
|
|
| |
Much has been said about this topic, we don't need to say even more.
See additions to options.rst.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| | |
The merged branch doesn't actually just remove old demuxers, but also
includes a branch of cleanups and some refactoring.
Conflicts:
stream/stream.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes the dependency on DEMUXER_TYPE_* and the file_format
parameter from the stream open functions.
Remove some of the playlist handling code. It looks like this was
needed only for loading linked mov files with demux_mov (which was
removed long ago).
Delete a minor bit of dead network-related code from stream.c as well.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, we tried to play along with libavformat and tried
to pretend that attached pictures are video streams with a single
frame, and that the frame magically appeared at the seek position when
seeking. The playback core would then switch to a mode where the video
has ended, and the "remaining" audio is played.
This didn't work very well:
- we needed a hack in demux.c, because we tried to read more packets in
order to find the "next" video frame (libavformat doesn't tell us if
a stream has ended)
- switching the video stream didn't work, because we can't tell
libavformat to send the packet again
- seeking and resuming after was hacky (for some reason libavformat sets
the returned packet's PTS to that of the previously returned audio
packet in generic code not related to attached pictures, and this
happened to work)
- if the user did something stupid and e.g. inserted a deinterlacer by
default, a picture was never displayed, only an inactive VO window)
- same when using a command that reconfigured the VO (like switching
aspect or video filters)
- hr-seek didn't work
For this reason, handle attached pictures as separate case with a
separate video decoding function, which doesn't read packets. Also,
do not synchronize audio to video start in this case.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code touched by this commit makes sure that DVD subtitle tracks
known by libdvdread but not known by demux_lavf can be selected and
displayed properly. These subtitle tracks have the first packet
some time late in the packet stream, so that libavformat won't
immediately recognize them, and will add the track as soon as the
first packet is seen during normal demuxing.
demux_mpg used to handle this elegantly: you just set the MPEG ID of
the stream you wanted. demux_lavf couldn't do this, so it was emulated
with a DEMUXER_CTRL. This commit changes it so that new streams are
selected by default (if autoselect is enabled), and the playloop
simply can take appropriate action before the lower layer throws away
the first packet.
This also changes the demux_lavf behavior that subtitle packets are
always demuxed, even if not needed. (They were immediately thrown away,
so there was no advantage to this.)
Further, this adds the ability to demux.c to deal with demuxing more
than one stream of a kind at once. (Though currently it's not useful.)
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Generally remove all accesses to demux_stream from all the code, except
inside of demux.c. Make it completely private to demux.c.
This simplifies the code because it removes an extra concept. In demux.c
it is reduced to a simple packet queue. There were other uses of
demux_stream, but they were removed or are removed with this commit.
Remove the extra "ds" argument to demux fill_buffer callback. It was
used by demux_avi and the TV pseudo-demuxer only.
Remove usage of d_video->last_pts from the no-correct-pts code. This
field contains the last PTS retrieved after a packet that is not NOPTS.
We can easily get this value manually because we read the packets
ourselves. Reuse sh_video->last_pts to store the packet PTS values. It
was used only by the correct-pts code before, and like d_video->last_pts,
it is reset on seek. The behavior should be exactly the same.
|
| |
| |
| |
| |
| | |
Boolean variables shouldn't carry a negated meaning, so rename
non_interleaved to interleaved.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is not directly related to the handling of format changes itself,
but playing audio normally after the change. This was broken: the output
byte rate was not recalculated, so audio-video sync was simply broken.
Fix this by calculating the byte rate on the fly, instead of storing it
in sh_audio.
Format changes are relatively common (switches between stereo and 5.1
in TV recordings), so this fixes a somewhat critical bug.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Removing this code doesn't change anything. All remaining audio decoders
are well-behaved enough to not overwrite sh_audio->pts if they don't
know the PTS. And if they don't know the PTS, the d_audio->last_pts
field can't contain any usable value either, because both fields contain
theame value: the last known valid PTS found in an audio packet.
|