| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds API to libmpv that lets host applications use the mpv opengl
renderer. This is a more flexible (and possibly more portable) option to
foreign window embedding (via --wid).
This assumes that methods like context sharing and multithreaded OpenGL
rendering are infeasible, and that a way is needed to integrate it with
an application that uses a single thread to render everything.
Add an example that does this with QtQuick/qml. The example is
relatively lazy, but still shows how relatively simple the integration
is. The FBO indirection could probably be avoided, but would require
more work (and would probably lead to worse QtQuick integration, because
it would have to ignore transformations like rotation).
Because this makes mpv directly use the host application's OpenGL
context, there is no platform specific code involved in mpv, except
for hw decoding interop.
main.qml is derived from some Qt example.
The following things are still missing:
- a way to do better video timing
- expose GL renderer options, allow changing them at runtime
- support for color equalizer controls
- support for screenshots
|
|
|
|
|
|
| |
A small refactor; shouldn't change any behavior.
Do this so immediate display can be achieved.
|
| |
|
|
|
|
| |
Fixes #1324.
|
|
|
|
|
|
| |
fixes #1323
Doesn't leak unless we switch video tracks on and off while in fullscreen.
|
|
|
|
|
| |
This is requested oftem, but I don't know if it should be an actual
default binding.
|
|
|
|
|
|
|
|
|
|
| |
The most awesome codec, not.
The actual code for svq3 is actually just the part that checks for
MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is
minor refactoring, that actually improves the code in general.
This is just enough to support the 2 svq3-in-mkv sample files I have.
|
|
|
|
|
|
| |
Still supported, but obviously untested.
You shouldn't use this option anyway.
|
|
|
|
|
|
|
|
| |
There were complaints that a chapter seek past the last chapter was
quitting the player. Change the behavior to what is expected: the last
frame.
If no chapters are available, this still does nothing.
|
|
|
|
|
|
| |
I guess most problems with it have been fixed.
It's still slower than necessary, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not all filter sizes the shaders could handle were in the filter_sizes
list. The shader can handle any multiple of 4 (the sizes 2 and 6 are
special-cased to keep it simple).
Add all possible filter sizes, up to 64. 64 is ridiculously high anyway.
Most of the larger filter sizes are completely useless for upscaling,
but help with the fancy-downscaling option. (Although it would still be
more efficient to use cascaded scalers to handle downscaling better.)
I considered doing something less stupid than the hardcoded array, but
it seems this is still the simplest solution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the convolution scaler shader functions were pre-
instantiated in the shader file. For every filter size, a corresponding
function (with the filter size as suffix) had to be present.
Change this, and make the C code emit the necessary bits.
This means the shader code is much reduced. (Although hopefully it
doesn't make shader compilation faster - it would require a really dumb
compiler if it spends its time on dead code.)
It also makes it more flexible, which is the main goal.
The DEF_SCALER0 stuff is needed because the C code writes the header of
the shader, at a point where scaler macros are not defined yet.
|
|
|
|
|
|
|
|
|
| |
This was a microoptimization for small filters which need 4 or less
weights per sample point. When I originally wrote this code, using a 1D
texture seemed to give a slight speed gain, but now I couldn't measure
any difference.
Remove this to simplify the code.
|
|
|
|
|
|
|
|
|
| |
There's not much of a reason to have the actual convolution code in a
separate function. Merging them actually simplifies the code a bit, and
gets rid of the repetitious macro invocations to define the functions
for each filter size.
There should be no changes in behavior or output.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows uses a heuristic to determine if a window should appear
fullscreen. If the active window's client area covers the whole screen,
the taskbar should move to the bottom of the Z-order, allowing the
window to show through.
Unfortunately, sometimes it doesn't work and the taskbar stays on top of
the "fullscreen" window. ITaskbarList2->MarkFullscreenWindow explicitly
tells the shell that a window wants to be fullscreen, so the taskbar is
always at the bottom of the Z-order while the marked window is active.
This might help with #999. Firefox also uses this interface to fix
fullscreen issues.
|
|
|
|
| |
As suggested in #1321
|
|
|
| |
similar to some of the code deleted in 685b8b7a but simpler
|
| |
|
|
|
|
|
| |
This allows to make mpv wait for file open events at start but close
after it is done playing the first playlist.
|
|
|
|
|
|
|
|
|
|
|
| |
This should clearly be impossible, but it seems to happen with ordered
chapters for a user.
Since I can't tell what the actual bug is and it seems impossible to
know the details without downloading possibly huge files, this is
probably the best we can do.
Should at least partially fix #1319.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It feels strange that seeking past EOF with --keep-open actually leaves
the player at a random position. You can't even unpause, because the
demuxer is in the EOF state, and what you see on screen is just what was
around before the seek.
Improve this by attempting to seek to the last video frame if EOF
happens. We explicitly don't do this if EOF was reached normally to
increase robustness (if the VO got a frame since the last seek, it
obviously means we had normal playback before EOF).
If an error happens when trying to find the last frame (such as not
actually finding a last frame because e.g. the demuxer misbehaves), this
will probably turn your CPU into a heater. There is no logic to prevent
reinitiating the last-frame search if the last-frame search reached EOF.
(Pausing usually prevents that EOF is reached again after a successful
last-frame search.)
Fixes #819.
|
|
|
|
|
|
| |
For better downscaling.
Maybe the list of filter sizes shouldn't be static...
|
|
|
|
|
|
|
|
|
|
|
| |
This gives better results with fancy-downscaling. The issue here is that
fancy-downscalign "extends" the filter radius by some amount, which
requires using a larger filter size and shader. Then most of the filter
is "unused", but some filters still return non-0 coefficients, which
create heavy artifacts. Just clamp them off.
I'm not sure if this is the right solution, but at least it's better
than before.
|
| |
|
|
|
|
|
|
|
| |
Based on patch by Yuriy Kaminskiy [yumkam gmail].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37330 b3059339-0415-0410-9bf9-f77b7e298cf2
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
Previously when using the bundle we used a custom bizarro thing to wait for
events. Just use `--idle` and greatly simplify the code.
|
|
|
|
|
|
|
| |
Also reject anything over INT_MAX; no particular reason for this upper
bound.
Fixes #1317.
|
|
|
| |
/cc @mpv-player/stable
|
|
|
|
| |
Fuck.
|
|
|
|
|
| |
Seems it's actually buggy, beyond the problem that large filter sizes
are required.
|
|
|
|
|
|
| |
Also replace the weights calculations for 8/12/16 with the generic
weight function definition macro. (The weights 2/4/6 follow slightly
different rules.)
|
|
|
|
| |
Instead go through our function loader.
|
|
|
|
|
|
|
| |
This message was added in commit a0acb6ea. But it showed up in all sorts
of inappropriate contexts, such as when opening m3u from an unseekable
http URL, or playing DVDs. So I guess this didn't work out. Disabling it
again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
m3u files are normally just text files with a list of filenames. Nothing
actually mandates that there is a header. Until now, we've rejected such
files, because there's absolutely no way to detect them.
If nothing else claims the file, the extension is ".m3u", and if the
contents of the file look like text, then load it as m3u playlist. The
text heuristic is pretty cheap, but at least it should prevent trying
to load binary data as playlist. (Which would "work", but result in a
catastrophic user experience.)
Due to the text heuristic, UTF-16/32 files will be rejected (unless they
have a header), but I don't care.
|
|
|
| |
Fixes #947
|
|
|
|
| |
fixes #635
|
| |
|
| |
|
| |
|
|
|
|
| |
source: http://spencermortensen.com/articles/bezier-circle/
|
|
|
|
|
|
|
|
| |
Whether we print it as warning or error doesn't really matter; we
continue anyway. (I don't actually know what the implications of running
in non-blocking mode are; for what's it worth, when I tested with
explicitly changing to non-blocking, it seemed to work fine anyway, so
don't change that part.)
|
|
|
|
|
|
| |
ALSA returns "FL" as channel layout when trying to play mono. mpv and
libavresample don't like this; in particular, using libavresample to
convert stereo to "FL" fails.
|
|
|
|
|
|
|
|
|
| |
The flags weren't correctly set, and the mouse cursor remained visible
after leaving menu mode.
This was apparently broken in 0.7.0 too.
Fixes #1316.
|
|
|
|
| |
for #1279 and #1249
|
|\
| |
| | |
gitignore: ignore waf directory on Windows
|
|/
|
|
|
| |
In native Windows, waflib is kept in /waf-1.8.4-* or /waf3-1.8.4-*
instead of /.waf-1.8.4-* and /.waf3-1.8.4-*
|
| |
|
|
|
|
| |
For #1279
|
|
|
|
|
|
|
|
|
|
|
| |
If no-block was given, the device would be opened with SND_PCM_NOBLOCK.
Also, after opening, blocking mode was unconditionally enabled anyway
with snd_pcm_nonblock(). Further, if opening with SND_PCM_NOBLOCK
failed, opening was retried without this flag.
This doesn't make any sense to me, and I've never heard of someone using
this suboption. I suspect it has to do with ancient ALSA bugs or API
caveats. Remove it and simplify the code.
|
|
|
|
|
| |
This fixes the very annoying glitch where the black bars disappear for
a single frame when going fullscreen.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ALSA is crap. It's impossible to make multichannel playback just do the
right thing. dmix (the default on most distros) can do stereo only, and
will refuse to play multichannel. On the other hand, if you try like mpv
(and mplayer) to open a multichannel device (like "surround51" etc.),
this will actually open a hardware device, which will either fail if
dmix is active, or block out dmix if opening succeeds.
This commit falls back to "default" (i.e. dmix) if opening a
multichannel device fails, which is a tiny step towards the right
behavior. (Although fixing it fully is impossible.)
|
|
|
|
| |
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.
|