| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
In theory, vo_opengl supports operation without framebuffers. But this
has been broken for a while now (commit cc00b3ff is a contender). It
crashed because it unconditionally called gl->BindFramebuffer() (which
is NULL if framebuffers are missing).
Since this function is actually only called to set the default
framebuffer, the simplest way to deal with this is to provide a dummy
function, insteas of uglifying the code with additional if branches.
|
|
|
|
| |
Let's see who complains...
|
|
|
|
|
|
| |
The result isn't quite what I imagined, because the A-point is never
marked as a seek point (so you can't jump between A and B), but it's
still slightly better than before.
|
|
|
|
|
|
|
| |
I think that's expected; mpv shouldn't draw anything while no video is
active. This doesn't blend transparently, though.
Also document the vo_opengl_cb thing.
|
|
|
|
|
| |
This mainly affects the black bars that are drawn if the window and
video aspect ratios mismatch.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After being bitten by this, I decided that this mostly unnecessary
requirement sucks.
Allowing this makes it easier to use libmpv, because it can be set after
mpv_initialize(). The latest reasonable time an API user can set this
variable is before actually loading a file.
The previous 2 commits make sure nothing bad can happen if the option is
changed at runtime even if a VO is active. The Cocoa backend should be
fine and doesn't need a change.
|
|
|
|
| |
See previous and next commit.
|
|
|
|
| |
For the purpose of making "--wid" setable at any time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|