| Commit message (Collapse) | Author | Age |
|
|
|
| |
Probably doesn't matter much in practice.
|
|
|
|
| |
Even thouhg it was printed in verbose mode only, it was annoying.
|
|
|
|
| |
This was made the default a while ago.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was completely breaking any low-level caching. Change it so that at
least demuxer caching will work.
Do this by using the metadata cache mechanism to funnel through the menu
commands.
For some incomprehensible reason, I had to reorder the events (which
affects their delivery priority), or they would be ignored. Probably
some crap about the event state being cleared before it could be
delivered. I don't give a shit.
All this code sucks. It would probably be better to let discnav.c access
the menu event "queue" directly, and to synchronize access with a mutex,
instead of going through all the caching layers, making things
complicated and slow.
|
|
|
|
|
|
|
|
|
|
| |
If the user has LEFT/RIGHT/etc. bound in his input.conf, then these were
overriding the menu keys in dvdnav mode.
This hack works because the dvdnav crap happens to be the only user of
MP_INPUT_ON_TOP. If it finds a default key binding in the dvdnav menu
section, it will use that, instead of continuing search and possibly
finding the user key bindings meant for normal playback.
|
| |
|
|
|
|
| |
This is a fix attempt for #1279 and #1249.
|
| |
|
| |
|
|
|
|
|
|
|
| |
They interfere.
It turns out that commit b6ca4a48 actually broke this in weird ways, but
this solution is better anyway.
|
| |
|
|
|
|
| |
Oops.
|
|
|
|
|
|
|
|
|
|
|
| |
This was required by vf_pp, which was just removed.
vf_dlopen has this stuff in its API. This API is considered stable, so
the related fields are not removed from it. But the fields are always 0
now, so there's no point in keeping the example program around.
vf_pullup.c did some extremely awkward passthrough of this information,
but didn't actually use it.
|
|
|
|
|
|
|
|
|
| |
This is an ancient filter, and we assume it's not useful anymore.
If you really want this, it's still available in libavfilter (e.g. via
--vf=lavfi=[pp...]). The disadvantage is that mpv doesn't pass through
QP information to libavfilter. (This was probably the reason vf_pp still
was part of mpv - it was slightly easier to pass QP internally.)
|
|
|
|
| |
This is basically cosmetic; it was leaking the old handler functions.
|
| |
|
|
|
|
|
|
| |
This wasn't done before because there was no advantage in "abstracting"
it. This changed, and putting this into its own files is better than
messing it into gl_common.c/h.
|
|
|
|
|
|
|
|
|
| |
Same as with the previous commits.
In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as
well. But since it's always GLX in practice, so we're fine with this.
Remove the gl_hwdec.mpgl field - it's unused now.
|
|
|
|
| |
Same as with the VDA change.
|
|
|
|
|
|
|
|
|
| |
Basically, don't access the vo field.
There's also no reason anymore to access MPGLContext. We still need to
access loaded GL functions though, so add a field for that to gl_hwdec.
Untested.
|
|
|
|
| |
Removes the dependency from the Cocoa backend in case we are not using
it but still wanna use VDA GL introp.
|
|
|
|
|
|
| |
This just kept adding bindings to the input section, rather than
defining it. One bad effect was that mp.remove_key_binding() in Lua
didn't work.
|
|
|
|
|
|
| |
This fixes using the mpv:// custom protocol on Yosemite were apparently
we receive an url which is automatically urlencoded by the system.
/cc mpv-player/stable
|
|
|
|
|
| |
LuaJIT ships with a broken .pc file on OS X (see #1110), and leaving
Lua52 last was done only to improve libquvi interoperability.
|
| |
|
|
|
|
|
|
| |
This should allow lauching a mk3d file directly from the Finder.
Fixes #1311
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is simply not allowed, and doing it triggered an assertion. It's
still not allowed, because the terminal and related functionality is a
global resource, and there doesn't seem to be a sane way to manage the
signal handlers.
But be a bit nicer, and just the terminal if it's already in use.
Note that terminal _output_ happens anyway. This becomes usable with
this commit. To facilitate logging-only usage further, also explicitly
disable terminal input, so that "terminal=yes" can be used for logging
without much interference with other things. (It'll still overwrite some
signal handlers, though.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always set the viewport on entry. The way the viewport is tracked is a
bit complicated in my opinion, and in fact it doesn't even reduce the
number of GL calls. Setting it on entry is actually redundant if video
covers the screen fully, because the handle_pass() unconditionally sets
it anyway, but avoiding it would complicate the cases gl->Clear() is
actually needed.
Add a fbo argument to gl_video_render_frame(). This allows you to render
into a FBO rather than the default framebuffer. It will be useful for
providing an API to render on an external GL context. (If that will
actually be added.)
|
|
|
|
|
|
|
|
| |
Seems like a waste not to print this.
Anyone with enough technical knowledge to have use for the exact error
can map the number back to the GL symbol, so don't bother to convert it
to a symbol.
|
|
|
|
|
|
| |
So the OSC will still appear when using --no-input-default-bindings. It
also means it may override a user's mouse_move binding, but I guess
users who don't want the OSC should just use the --no-osc option.
|
|
|
|
|
| |
luaL_error() doesn't support %.*s, because it uses Lua's own format
string mechanism that just looks like the C one. Just drop this part.
|
|
|
|
|
| |
This is "better", although nobody seems to know how this API is supposed
to work at all.
|
|
|
|
|
|
|
| |
The player thinks an error happened because no audio or video was played
after finishing the file, but this obviously makes no sense with stream
dumping. (error_playing follows the client API convention that negative
values are errors.)
|
|
|
|
|
| |
A rather big oversight, because a log produced with the client API will
not contain the mpv version at all otherwise.
|
| |
|
| |
|
|
|
|
|
|
| |
Fixes #1202
/cc @mpv-player/stable
|
|
|
|
|
| |
Fixes commit 52c51149. It broke multichannel (or possibly everything)
for ao_alsa, ao_oss, ao_sndio.
|
|
|
| |
fixes #1302
|
|
|
| |
Should hopefully fix #1249 and #1279
|
|
|
|
|
|
|
|
|
|
| |
Channel amp otpions were not copied correctly: it copied the size of a
pointer to struct chmap, not the struct itself. Since mp_chmap is
currently 9 bytes, this meant the last channel entry was not copied
correctly on 64 bit systems, leading to very strange failures. It could
be triggered especially when using the client API, because the client
API always copies options on access (mpv command line options tend to
work directly on options).
|
|
|
|
|
| |
This was relevant for --af and --vo (both use this option type, and have
deprecated aliases).
|
|
|
|
|
| |
The min=-1 case was never used, and the channel map must always be valid
(or in some cases, invalid but empty).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).
Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)
Fixes #1306.
|
|
|
|
|
|
|
| |
All of these are already the defaults.
One exception is glDepthMask(), which is enabled by default. But if the
framebuffer has no depth buffer anyway, it shouldn't make a difference.
|
|
|
|
| |
Fixes #1307.
|
|
|
|
|
|
|
|
|
| |
There is no guarantee that closestMatch returned by IsFormatSupported
is actually a WAVEFORMATEXTENSIBLE.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd370876%28v=vs.85%29.aspx
We should therefore not blindly treat it as such.
|
|
|
|
|
|
|
|
|
|
|
| |
Before it used whatever was in ao->format and changed the bits even
though this might have nothing to do with the actual WAVEFORMAT
negotiated with WASAPI.
For example, if the initial ao->format was a float and we had set the
WAVEFORMAT to s24, this would create a non-existent float24 format.
Worse, it might put an u16 into ao->format when WAVEFORMAT described s16.
WASAPI doesn't support unsigned at all as far as I can tell.
|
|
|
|
| |
also remove bogus ao_format
|
|
|
|
|
|
|
|
|
|
| |
This was based on old WAVEFORMATEX restrictions
http://msdn.microsoft.com/en-us/library/windows/hardware/ff538799%28v=vs.85%29.aspx
With the new WAVEFORMATEXTENSIBLE, this is no longer a problem. and we
can have s32 or float32 so we need to actually check / set these correctly.
fixes #1287
|