| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This means use of the min/max fields can be dropped for the flag option
type, which makes some things slightly easier. I'm also not sure if the
client API handled the case of flag not being 0 or 1 correctly, and this
change gets rid of this concern.
|
|
|
|
|
| |
Now MPOpts.sub_fix_timing corresponds to the commandline switch
directly, instead of storing the inverted value.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also clarify the semantics.
It seems --idx didn't do anything. Possibly it used to change how the
now removed legacy demuxers like demux_avi used to behave. Or maybe
it was accidental.
--forceidx basically becomes --index=force. It's possible that new
index modes will be added in the future, so I'm keeping it
extensible, instead of e.g. creating --force-index.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Probably "needed" to get the correct alignment, although I'm not aware
of actual breakages or performance issues.
In fact we should probably always just allocate AVPackets, but for now
use the simple fix.
|
|
|
|
|
| |
Actually we don't need to resize packets; we just need to make them
shorter.
|
|
|
|
|
| |
Instead, the recursive call has been flattened away by instead
overwriting a parameter and continuing.
|
|
|
|
| |
This reverts commit 231c6672140f019257edd26db20fbcfc2554258f.
|
|
|
|
|
|
|
|
|
| |
FFmpeg requires a bullshit padding after each input buffer, and they
just increased that padding without warning and without ABI or API bump.
We need this only in one file (although mp_image hardcodes something
similar, for which no FFmpeg API define is available), so drop our own
define.
|
|
|
|
| |
Seems pretty useless in general, so this reduces output noise.
|
|
|
|
|
|
|
| |
Does anyone actually use this?
For now, update it, because it's the only case left where an option
points to a global variable (and not a struct offset).
|
| |
|
|
|
|
| |
Like in commit 99f5fe.
|
|
|
|
| |
This is most likely never intended.
|
|
|
|
| |
Dump what the AO does on driver->play().
|
|
|
|
|
| |
A corner case that could possibly lead to infinite waiting. Though
I'm not aware that this actually happened in practice.
|
|
|
|
|
|
|
|
| |
Unfortunately, there's a recursive function call in ao_lavc.c (play
function), leading to a deadlock. The locking is getting a bit messy, so
just make the lock recursive.
This fixes #844.
|
|
|
|
|
| |
HAVE_* flags are always defined so ifdef will never work.
They should be checked with their values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Squashed from the following mplayer-svn commits. The '#' is removed from
the bug ID to prevent github from doing something stupid. Instead of
adding the mplayer configure check for clock_gettime(), the POSIX
identifiers are used for checking presence of the function.
Use correct type of timestamps when recording from v4l2. Fix 2176
Patch by Jarek Czekalski <jarekczek at poczta onet pl>.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37222 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow building of v4l2 without clock_gettime().
Add overly verbose message in case monotone timestamps are required by the kernel.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37223 b3059339-0415-0410-9bf9-f77b7e298cf2
|
|
|
|
| |
Similar to previous commits.
|
|
|
|
|
|
|
|
|
| |
Similar to previous commits.
This also renames --doubleclick-time to --input-doubleclick-time, and
--key-fifo-size to --input-key-fifo-size. We could keep the old names,
but these options are very obscure, and renaming them seems better for
consistency.
|
|
|
|
| |
Similar to previous commits.
|
|
|
|
| |
Similar to previous commit.
|
|
|
|
|
| |
Removes specifics from options.h and options.c, and puts everything into
vd_lavc.c.
|
|
|
|
| |
This is probably the last one, at least with my current configuration.
|
| |
|
| |
|
|
|
|
|
|
|
| |
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
|
|
|
|
| |
The shit I put up with...
|
| |
|
| |
|
|
|
|
|
|
| |
Additionally to removing the global variables, this makes the options
more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws-
scaler. For --sws-scaler, use choices instead of magic integer values.
|
|
|
|
|
| |
We don't need a separate stream_dvd.h header file anymore. Some dead
functions become apparent; remove them.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually, each stream driver declares the size and option list of its
private data. This was pretty natural for when most streams still used
global variables to setup their defaults. They did by pointing
priv_defaults to the (mutable) struct containing the option values. But
falls short when storing the option values in MPOpts. So provide a
somewhat inelegant but simple way to let the stream implementation setup
the priv struct at initialization time.
This is done with the get_defaults callback. It should return a copy of
the struct used in MPOpts. (A copy, because if MPOpts is changed, string
fields might be deallocated, and if that field is not described by
stream_info.options, it won't be copied on init.)
|
| |
|
| |
|
|
|
|
|
|
| |
Pretty much nothing changes, but using -tv-scan with suboptions doesn't
work anymore (instead of "-tv-scan x" it's "-tv scan-x" now). Flat
options ("-tv-scan-x") stay compatible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert all these commands to properties. (Except tv_last_channel, not
sure what to do with this.) Also, internally, don't access stream
details directly, but dispatch commands with stream ctrls.
Many of the new properties are a bit strange, because they're write-
only. Also remove some OSD output these commands produced, because I
couldn't be bothered to port these.
In general, this makes everything much cleaner, and will also make it
easier to e.g. move the demuxer to its own thread.
Don't bother updating input.conf, but changes.rst documents how old
commands map to the new ones.
Mostly untested, due to lack of hardware.
|
| |
|
|
|
|
|
|
|
|
| |
The Perl script generating the completions actually invokes mpv, and it
runs during the build. This is not sane and breaks at least cross
compilation.
As a workaround, disable the completions by default for now.
|
|
|
|
| |
This started getting annoying.
|
|
|
|
|
|
|
| |
Playing a video and then an audio file with cover art kept displaying
the last frame of the video. This was because the hasframe flag was set,
perhaps due to redrawing the last video frame before the cover art image
is decoded.
|
|
|
|
|
|
| |
Not only should using libmpv hog such global resources; it's also very
unlikely an application embedding mpv will ever want to make use of
this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, this allows gapless playback with similar files (including
the ordered chapter case), while still being robust in general.
The implementation is quite simplistic on purpose, in order to avoid
all the weird corner cases that can occur when creating the filter
chain. The consequence is that it might do not-gapless playback in
more cases when needed, but if that bothers you, you still can use
the normal gapless mode.
Just using "--gapless-audio" or "--gapless-audio=yes" selects the old
mode.
|
|
|
|
| |
This commit implements them for volume and some video properties.
|
| |
|
|
|
|
| |
As discussed in #775
|
| |
|
|
|
|
|
|
|
|
|
| |
Since redundant wakeups are avoided now, it's easy to miss a wakeup when
creating/setting the pipe/callback after the client API was signalled.
If the client API is signalled, need_wakeup is set to true, and
wakeup_client skips writing to the pipe or calling the client API. That
this can happen is not very obvious to the client API, so trigger a
wakeup right on start in order to remove this special case.
|
|
|
|
| |
This was forgotten in the previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--sub-file is actually a string list, so you can add multipel external
subtitle files. But to be able to set a list, the option value was split
on ",". This made it impossible to add filenames.
One possible solution would be adding escaping. That's probably a good
idea (and some other options already do this), but it's also complicated
both to implement and for the user.
The simpler solution is making --sub-file appending, and make it take
only a single entry.
I'm not quite sure about this yet. It breaks the invariant that if a
value is printed and parsed, you get the same value back. So for now,
just go with the simple solution.
Fixes #840.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, availability of new log messages (through the mechanism
associated with mpv_request_log_messages()) did not wakeup the client
API properly. Commit 3b7402b5 was basically a hack to improve that
somewhat, but it wasn't a solution.
The main problem is that the client API itself is producing messages, so
the message callback would attempt to lock the client API lock,
resulting in a deadlock. Even if the lock was recursive, we'd run into
lock-order issues.
Solve this by using a separate lock for waiting and wakeup. Also, since
it's a natural addition, avoid redundant wakeups. This means the wakeup
callback as well as the wakeup pipe will be triggered only once until
the next mpv_wait_event() call happens.
This might make the wakeup callback be invoked in a reentrant way for
the first time, for example if a mpv_* function prints to a log. Adjust
the docs accordingly. (Note that non-reentrant beheavior was never
guaranteed - basically the wakeup callback is somewhat dangerous and
inconvenient.)
Also remove some traces of unneeded code. ctx->shutdown for one was
never set, and probably a leftover of an abandoned idea.
|
|
|
|
|
|
| |
A bit verbose, but less misleading. In most cases, the API user probably
actually wants mpv_terminate_destroy() instead, so the less-useful
function shouldn't have a simnpler name anyway.
|
|
|
|
|
|
|
|
|
|
|
| |
It wasn't necessarily clear how this works. Especially make clear that
the API user shouldn't expect that there's one byte per readable event
in the wakeup pipe. Actually, the reason why this currently won't work
is because property notifications can generate more events than wakeups.
The limit of 4096 is a more fundamental issue, but the event ringbuffer
is currently limited to 1000 entries anyway.
Also add some important comments to mpv_set_wakeup_callback.
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv_destroy() should perhaps better be called mpv_detach(), because it
destroys only the handle, not necessarily the player. The player is only
terminated if a quit command is sent.
This function quits automatically, and additionally waits until the
player is completely destroyed. It removes the possibility that the
player core is still uninitializing, while all client handles are
already destroyed. (Although in practice, the difference is usually not
important.)
|
| |
|
|
|
|
|
|
|
|
|
| |
Now a negative timeout mean an infinite timeout. This is similar to the
poll() system call. Apparently this is more intuitive and less confusing
than specifying a "very high" value as timeout if you want to wait
forever.
For callers that never pass negative timeouts, nothing changes.
|
|
|
|
|
|
|
|
| |
This was never intended to be installed; waf just picked it up
automagically. There's also a closed ticket on github where someone
complains that the program "simple" is installed, and I didn't realize
at this point that it was actually installed by default when enabling
the client API.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Listening on messages currently uses polling (every time
mpv_wait_event() has no new events, the message buffer is polled and a
message event is possibly created). Improve this situation a bit, and
call the user-supplied wakeup callback.
This will increase the frequency with which the wakeup callback is
called, but the client is already supposed to be able to deal with this
situation. Also, as before, calling mpv_wait_event() from the wakeup
callback is forbidden, so the client can't read new messages from the
callback directly.
The wakeup pipe is written either. Since the wakeup pipe is created
lazily, we can't access the pipe handle without creating a race
condition or a deadlock. (This is actually very silly, since in practice
the race condition won't matter, but for now let's keep it clean.)
|
|
|
|
|
|
|
|
| |
It seems we can't really get rid of this. There are no other hints to
remove decorations that work across all reasonable WMs, so we're stuck
with the ugly motif stuff.
But at least we can make the code for it less ugly.
|
|
|
|
|
|
| |
By default this is disabled. But if it's enabled, then we have to
account for proper states when enabling/disabling the terminal state
itself.
|
|
|
|
|
|
| |
If an API user calls mpv_wait_event() and mpv_observe_property() before
mpv_initialize(), it could happen that a property was accessed before
initialization, which is not ok.
|
|
|
|
|
|
|
|
|
| |
This was always intended this way, and even documented in client.h. Due
to an oversight it was never actually implemented.
The intention is that mpv embedded in applications and "real mpv" don't
conflict. An API user can undo this by setting the "config" option to
"yes", if using the user's mpv config is desired.
|
|
|
|
| |
Should be equivalent, reduces code duplication.
|