This is a minor precaution, because in some cases the number of shader
programs can already hit 10. (chroma merging + separated cscale/scale +
+ sub blending (interpolated) + sub blending (non-interpolated)
+ output (interpolated) + output (non-interpolated) + OSD)
This has a number of user-visible changes:
1. A new flag blend-subtitles (default on for opengl-hq) to control this
behavior.
2. The OSD itself will not be color managed or affected by
gamma controls. To get subtitle CMS/gamma, blend-subtitles must be
used.
3. When enabled, this will make subtitles be cleanly interpolated by
:interpolation, and also dithered etc. (just like the normal output).
Signed-off-by: wm4 <wm4@nowhere>
Bilinear scaling is not a suitable default for something named "hq"; the
whole reason this was done in the past was because cscale used to be
obscenely slow. This is no longer the case, with cscale being nearly
free.
Handling this perfectly with VapourSynth is probably not possible: you
either need to tell it the total number of input frames in advance, or
deliver an infinite stream. With playback, EOF can happen at an
unpredictable point, for which the VapourSynth API has no mechanism at
all. We handle EOF by returning an error to the filter, which will the
filter return all pending frame callbacks.
We still can try to handle it approximately: if the filter requests a
frame past EOF, then send it an error. This seems to work relatively
well with filters which don't request future frames.
With the previous commit, we have no need anymore to check a part of an
extension string (for ignoring a prefix). So check the extension string
properly, instead of just using the broken old strstr() method, which
could accidentally ignore prefixes or suffixes. Do this by extending
the check to whether the extension name is properly delimited by spaces
or string start/end.
Instead of somehow looking for the substring "_swap_control" and trying
to several arbitrary function names, do it cleanly. The old approach has
the problem that it's not very exact, and may even load a pointer to a
function which doesn't exist. (Some GL implementations like Mesa return
function pointers even the functions which don't exist, and calling them
crashes.)
I couldn't find any evidence that glXSwapInterval, wglSwapIntervalSGI,
or wglSwapInterval actually exist, so don't include them. They were
carried over from MPlayer times.
To make diagnostics easier, print a warning in verbose mode if the
function could not be loaded.
Drop support for GL_EXT_framebuffer_object. It has 2 problems: semantics
might be slightly different from the "proper" GL_ARB_framebuffer_object
extension (but is likely completely untested), and also our extension
loader is too dumb to load the same group of function pointers
represented by different extensions only once.
When not receiving frame callbacks, we should not draw anything to avoid
blocking the OpenGL renderer. We do this by extending gl context api, by
introducing new optional function 'is_active', that indicates whether
OpenGL renderers should draw or not.
This fixes issue #249.
Define frame callback logic in wayland_common.c
As this should be used by opengl renderer as well.
Preferably drawing should be skipped entierly when no frame callbacks
are received. However, for now only swap buffers is skipped.
Like FFmpeg/Libav do. It seems not all code can actually deal with this
situation, so it's better to shift the special-cases to code which needs
it (possibly OSD code; screenshots of 0x0 windows would just fail).
I guess we don't really care whether this particular function succeeds.
If it fails, it must be completely broken anyway and it would not matter
much to us.
Unlike other VOs, this rendered OSD even while no VO was created
(because the renderer lives as long as the API user wants). Change this,
and refactor the code so that the OSD object is accessible only while
the VO is created.
(There is a short time where the OSD can still be accessed even after VO
destruction - this is not a race condition, though it's inelegant and
unfortunately unavoidable.)
gl_video_set_options() didn't update it, so the default value set on
initialization was used. Fix by always setting the clear color before
the clear command; it's slightly easier to follow too.
Codecs for hardware acceleration are not blacklisted, but whitelisted.
Also, if this emssage is printed, the codec might not have any hardware
acceleration support in the first place.
Trying to handle such video is almost worthless, but it was requested by
at least 2 users.
If there are no timestamps, enable byte seeking by setting
ts_resets_possible. Use the video FPS (wherever it comes from) and the
audio samplerate for timing. The latter was already done by making the
first packet emit DTS=0; remove this again and do it "properly" in a
higher level.
Normally, the size of an mage plane is assumed to be stride*height. But
in theory, if stride is larger than width*bpp, the last line might not
be padded, simply because it's not necessary. FFmpeg's or mpv's image
allocators always guarantee that this padding exists (it wastes some
insignificant memory for avoiding such subtle issues), but some other
libraries might not.
I suspect one such case might be Xv via vo_xv (see #1698), although my X
server appears to provide full padding. In any case, it can't harm.
There's literally no reason why these functions have to be inline (they
might be performance critical, but then the function call overhead isn't
going to matter at all).
Uninline them and move them to mp_image.c. Drop the header file and fix
all uses of it.
For some reason there were two points in the code where it warned
against non-monotonic video PTS. The one in video.c triggered on PTS
going backwards or making large jumps forwards, while dec_video.c
triggered on PTS going backwards or PTS not changing. Merge them into a
single check, which warns against all cases.
There was a somewhat obscure optimization in the OSD and subtitle
rendering path: if only the position of the sub-images changed, and not
the actual image data, uploading of the image data could be skipped. In
theory, this could speed up things like scrolling subtitles.
But it turns out that even in the rare cases subtitles have such scrolls
or axis-aligned movement, modern libass rarely signals this kind of
change. Possibly this is because of sub-pixel handling and such, which
break this.
As such, it's a worthless optimization and just introduces additional
complexity and subtle bugs (especially in cases libass does the
opposite: incorrectly signaling a position change only, which happened
before). Remove this optimization, and rename bitmap_pos_id to
change_id.
This played e.g. a 1264x722 file as 1264x720. There was some code which
dropped the aspect ratio if the video (in original resolution) wasn't
scaled by more than 4 pixels. Commit 5f3c3f8c introduced this (although
I'm not really sure what the code replaced by it did).
Just remove this "feature".
We now update uniforms every time, so we should try to reduce the number
of uniforms to avoid performance penalties. (Originally, some caching
was planned, but it looks like it would be too complicated to implement
compared to the expected gains.)
OPT_REPLACED can't specify option values or multiple options. Change to
OPT_REMOVED. Also, target-prim doesn't have an srgb option. BT.709 uses
sRGB primaries, so use it instead.
The default scaling was a slight bit too low, which could cause buffer
underruns in some cases.
This should improve the result when using tscale filters other than
oversample. The oversample case should be unaffected.
This adds extra debugging output for buffer underruns, to help track
down possible queueing issues. It also inverts the numberic output for
tscale=oversample to make more sense, without changing the logic.
This moves the color management code out of pass_render_main (which is
now dedicated solely to up/downscaling and hence renamed pass_scale_main)
and into a new function, which gets called from pass_draw_to_screen
instead.
This makes more sense from a logical standpoint, and also means that we
interpolate in linear RGB, before color management - rather than after
it, which is significantly better for color accuracy and probably also
interpolation quality.
This replaces the old smoothmotion code by a more flexible tscale
option, which essentially allows any scaler to be used for interpolating
frames. (The actual "smoothmotion" scaler which behaves identical to the
old code does not currently exist, but it will be re-added in a later commit)
The only odd thing is that larger filters require a larger queue size
offset, which is currently set dynamically as it introduces some issues
when pausing or framestepping. Filters with a lower radius are not
affected as much, so this is identical to the old smoothmotion if the
smoothmotion interpolator is used.
Also the size is now a simple #define that can easily be changed later.
This is done for smoothmotion, which might want to blend more than 4
frames at once, depending on the setting.
Niklas Haas
wm4
Jari Vetoniemi
James Ross-Gowan