MP_NOPTS_VALUE (basically INT64_MIN) is basically an special timestamp
value that means "unset" or "unknown". Its exact value is internal, and
should never be returned or interpreted by any API.
So return "no" instead (what is also what the parser accepts).
Commit d38bc531 is incorrect: the 50ms queue-ahead value and the flip
queue offset have different functions. The latter is about calling
flip_page in advance, so the change attempted to show video frames 50ms
in advance on all VOs.
The change was for vo_opengl_cb, but that can be handled differently.
These actually are harmless. Even if the data the reader is working on
is essentially random, it's treated like untrusted input data, so there
should be no harm.
But it upsets tools like valgrind.
Probably fixes#1329.
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.
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.
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.
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
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.
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.
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.
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.
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>
