| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This will allow to cancel opening slow/stuck network streams faster. How
well his work probably depends on the protocol implementation in
libavformat.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interrupt callback will can be called from another thread if the
cache is enabled, and the stream disconnects. Then stream_reconnect()
will call this function from within the cache thread.
mp_input_check_interrupt() is not thread-safe due to read_events() not
being thread-safe. It will call input callbacks added with
mp_input_add_fd() - these callbacks lead to code not protected by locks,
such as reading X11 events.
Solve this by adding a stupid hack, which checks whether the calling
thread is the main playback thread (i.e. calling the input callbacks
will be safe). We can remove this hack later, but it requires at least
moving the VO to its own thread first.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This used global variables for the asynchronous interrupt callback.
Pick the simple and dumb solution and stuff the callback into
mpv_global. Do this because interrupt checking should also work in the
connect phase, and currently stream creation equates connecting.
Ideally, this would be passed to the stream on creation instead, or
connecting would be separated from creation. But since I don't know yet
which is better, and since moving stream/demuxer into their own thread
is something that will happen later, go with the mpv_global solution.
|
| |
|
|
|
|
|
|
|
|
| |
This is the only function which actually used the time argument of
stream_check_interrupt(). Considering that the whole player freezes
anyway, this is not worth the complication.
Also generally reduce the maximum wait time due to timeout. Introduce
exponential backoff, which makes the first reconnect retries faster, but
still waits up to 500ms in the later retries.
|
| |
|
|
|
|
|
| |
Interestingly, their last use was removed with commit bbbea793, over
4 months ago.
Also remove a stray struct demux_stream forward declaration.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows to declare UTIs [1] for types of file that OS X doesn't know, like mkv,
mka, etc.
For example: instead of having a dynamically generated UTI for .mkv like
'dyn.somerandomstring', 'io.mpv.mkv' is registered and conforms to public.movie
and is known system wide.
Note: The list is far from being complete but it should cover the most used
type of files.
[1]: https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html#//apple_ref/doc/uid/TP40001319-CH202-CHDHIJDE
Fixes: #734
|
| |
|
|
|
| |
The CPU autodetect feature was added in 52.2.100 and is lacking from the
stand-alone version at http://git.videolan.org/?p=libpostproc.git
|
| |
|
|
| |
libav now supports reading ReplayGain values from LAME's Info/XING tag as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, some files appear to have broken mp3 packets, or at
least in a form that libavcodec can't deal with. The audio in the sample
file in question could not be decoded using libavcodec.
The problematic file had variable packet sizes, and the libavcodec
decoder kept printing "mp3: Header missing" for each packet it was fed.
Remuxing with mkvmerge fixes the problem. The mp3 data is probably not
VBR, and remuxing resulted in fixed-size mp3 frames. So I don't know why
the sample file was muxed this way - it might just be incorrect.
The sample file had "libmkv 0.6.4" as MuxingApp (although I could not
get mkvinfo to print this element, maybe the file uses an incorrect
element ID), and "HandBrake 0.9.4" as WritingApp.
Note that the libmpg123 decoder does not have any issues with it. It's
probably more robust, because libmpg123 was made to decode whole mp3
files, not just single frames.
Fixes issue #742.
|
| |
|
|
|
|
|
|
| |
The here documented guarantee might simplify code using this mechanism
a lot, because it becomes unnecessary to invent a separate mechanism to
make the mp_dispatch_queue_process loop exit after processing a dispatch
callback. (Instead, the dispatch callback can set a flag, and the caller
of mp_dispatch_queue_process can check it.)
|
| |
|
|
| |
fixes #741
|
| |
|
|
|
| |
This logs more info that can be used for debugging purposes, in particular
it prints all the AudioChannelDescription in the descriptions array.
|
| |
|
|
| |
This broke with recursive tables.
|
| |
|
|
|
|
| |
This allows client API users and Lua scripts to side-step the pretty
horrible video filter string "language" (although it's back and can't be
avoided when using libavfilter).
|
| |
|
|
|
|
|
|
| |
The wakeup is needed to make mp_dispatch_queue_process() return if
suspension is not needed anymore - which is only the case when the
request count reaches 0.
The assertion added with this commit always has/had to be true.
|
| |
|
|
| |
This can be useful for debugging purposes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closer to the corresponding standard function pthread_cond_timedwait.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this mechanism is similarly "unreliable" as for example
pthread_cond_timedwait(). Trying to target the exact wait time will just
make it more complex.
The main use case for this is for threads which either use the dispatch
centrally and want mp_dispatch_queue_process to do a blocking wait for
new work, or threads which have to implement timers. For the former,
anything is fine, as long as they don't have to do active waiting for
new works. For the former, callers are better off recalculating their
deadline after every call.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is much simpler, leaves fairness isues etc. to the operating
system, and will work better with threading-related debugging tools.
The "trick" to this is that the lock can be acquired and held only while
the queue is in suspend mode. This way we don't need to make sure the
lock is held outside of mp_dispatch_queue_process, which would be quite
messy to get right, because it would have to be in locked state by
default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
mp_dispatch_queue_process() releases the queue->lock mutex while
processing a dispatch callback. But this allowed mp_dispatch_lock() to
grab the "logical" lock represented by queue->locked. Grabbing the
logical lock is not a problem in itself, but it can't be allowed to
happen while the callback is still running.
Fix this by claiming the logical lock while the dispatch callback is
processed. Also make sure that the thread calling mp_dispatch_lock() is
woken up properly.
Fortunately, this didn't matter, because the locking function is unused.
|
| |
|
|
|
| |
Without this, it could happen that both the caller thread and the target
thread sleep.
|
| |
|
|
|
|
|
| |
This was part of osdep/threads.c out of laziness. But it doesn't contain
anything OS dependent. Note that the rest of threads.c actually isn't
all that OS dependent either (just some minor ifdeffery to work around
the lack of clock_gettime() on OSX).
|
| |
|
|
| |
This was subtly change in 5cfb18. Revert the change.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Add the event FD after preinit, remove it before destroy. There's no
need to do it on vo_config, and there's no need to remove the event
FD when vo_config fails.
|
| |
|
|
| |
Group together related functionality.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.
Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)
I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.
In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
|
| |
|
|
|
|
|
|
|
| |
glob() is mandated by POSIX. For the only non-POSIX platform we support,
Windows, we have our own replacement. So the ifdeffery is not needed.
Still leave the checks in the configure scripts, because they have to
decide whether to compile the replacement or not. (Although this could
be special cased to mingw-only, the wscript seems to make this hard.)
|
| |
|
|
| |
For completeness.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Unfortunately, if a VO can't display something as intended, we can just
complain to the user, and leave it at it. But it's still better than
silently displaying things differently with different VOs.
For now, this is used for rotation only. Other things that we should
check includes colorspace and colorlevels stuff.
|
| |
|
|
|
|
|
| |
When using rotation with hw decoding, and the VO does not support
rotation, vf_rotate is attempted to be inserted. This will go wrong, and
after that it can't recover because a vf_scale filter was autoinserted.
Just removing all autoinserted filters before reconfig fixes this.
|
| |
|
|
|
|
| |
The Windows port uses CommandLineToArgvW, which doesn't expand wildcards
in command line arguments. Use glob to expand them instead, but only for
non-option arguments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
glob-win.c wasn't big, so it was easier to rewrite it. The new version
supports Unicode, handles directories properly, sorts the output and
puts all its allocations in the same talloc context to simplify the
implementation of globfree.
Notably, the old glob had error checking code, but didn't do anything
with the errors since the error reporting code was commented out. The
new glob doesn't copy this behaviour. It just treats errors as if there
were no more matching files, which shouldn't matter for mpv, since it
ignores glob errors too.
To match the other Windows I/O helper functions, the definition is moved
to osdep/io.h.
|
| |
|
|
|
|
|
| |
If the VO can't do rotation, insert a filter to do this. Note that this
doesn't reuse the filter insertion code from command.c (used by "vf"
input command), because that would end up more complicated: we don't
even want to change the user filter option.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This turned out much more complicated than I thought. It's not just a
matter of adjusting the texture coordinates, but you also have to
consider separated scaling and panscan clipping, which make everything
complicated.
This actually still doesn't clip 100% correctly, but the bug is only
visible when rotating (or flipping with --vf=flip), and using something
like --video-pan-x/y at the same time.
|
| |
|
|
|
|
| |
For rotation, we assume that the source image will be rotated within the
VO, so the aspect/panscan code needs to calculate its param using
rotated coordinates. VOs which support rotation natively can use this.
|
| |
|
|
|
| |
Shuffle the special cases around so that it looks cleaner. The result
should be equivalent to the code before.
|
| |
|
|
|
| |
Now the rotation hint is propagated everywhere. It just isn't used
anywhere yet.
|
| | |
|
| |
|
|
|
| |
Minor cleanup, so that we can stuff more information into
mp_image_params later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This couldn't rotate by 180°. Add this, and also make the parameter in
degrees, instead of magic numbers.
For now, drop the flipping stuff. You can still flip with --vf=flip or
--vf=mirror. Drop the landscape/portrait stuff - I think this is
something almost nobody will use. If it turns out that we need some of
these things, they can be readded later.
Make it use libavfilter. Its vf_transpose implementation looks pretty
simple, except that it uses slice threading and should be much faster.
|
| |
|
|
|
| |
The previous commit doesn't handle additionally loaded config files,
such as the playback resume mechanism.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Often, user configs set options that are not suitable for encoding.
Usually, playback and encoding are pretty different things, so it makes
sense to keep them strictly separate. There are several possible
solutions. The approach taken by this commit is to basically ignore the
default config settings, and switch to an [encoding] config profile
section instead. This also makes it impossible to have --o in a config
file, because --o enables encode mode.
See github issue #727 for discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix all include statements of the form:
#include "libav.../..."
These come from MPlayer times, when FFmpeg was somehow part of the
MPlayer build tree, and this form was needed to prefer the local files
over system FFmpeg.
In some cases, the include statement wasn't needed or could be replaced
with mpv defined symbols.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not needed anymore. I'm not opposed to having asm, but inline asm is too
much of a pain, and it was planned long ago to eventually get rid fo all
inline asm uses.
For the note, the inline asm use that was removed with the previous
commits was almost worthless. It was confined to video filters, and most
video filtering is now done with libavfilter. Some mpv filters (like
vf_pullup) actually redirect to libavfilter if possible.
If asm is added in the future, it should happen in the form of external
files.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Becomes a bit slower (tested with progressive solid color video only),
but this filter is pretty obscure and I'm not even sure what it's useful
for.
|
| |
|
|
|
|
| |
No change in speed (or even slightly faster, though I tested with
progressive solid color video only), and normally we use libavformat's
vf_pullup anyway.
|
| |
|
|
|
|
|
|
| |
I didn't test the speed, but by default, this filter diverts to
libavfilter already. So this would help only if libavfilter is disabled,
or libavfilter doesn't have vf_noise (like on Libav). For these cases,
we still provide the (possibly but not necessarily) slower C
implementation of vf_noise.
|
| |
|
|
|
|
|
|
| |
This makes it multiple times slower. However, the output format (packed
YUV) isn't handled efficiently by anything to begin with, and I have no
clue we even have this filter. I guess it's one of these filters which
find some use sometimes, but are not of higher importance, which
justifies removing the faster inline asm.
|
| |
|
|
|
| |
Compiled with -O2, the C code runs just as far (or even slightly faster)
then the MMX inline asm.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This can be used to easily extent the status line for one's own needs.
I'm not experienced with lua so a few things could probably be done a
better way.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for the sake of multi-key commands again. This could break:
SPACE ignore
SPACE-SPACE command
while this worked:
SPACE-SPACE command
SPACE ignore
The reason being that if the shorter command was first in the list,
it would obviously match, and searching was stopped.
|
| |
|
|
|
|
| |
This is for the sake of multi-key combinations (see github issue #718).
Now a multi-key sequence isn't matched if any of the previous keys were
actually mapped.
|
| | |
|
| |
|
|
| |
Just in case something adds shift/alt/ctrl state to it.
|
|
