| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This significantly reduces the amount of noticeable flashing when using
tscale kernels with negative lobes, by cutting them off completely.
I'm not sure if this has any negative effects. It needs a bit of
subjective testing over a period of time, so I just made it an option.
Fixes #2155.
|
|
|
|
| |
And add an option to enable it.
|
|
|
|
| |
Most likely doesn't matter much.
|
|
|
|
|
| |
This is a cosmetic change, because the value is exactly the same. (The
old code just duplicates the logic, sort of.)
|
|
|
|
|
| |
The OSD overlay wasn't initialized, so it remained solid black until the
first time a subtitle line or an OSD element became visible.
|
|
|
|
|
|
|
| |
All hwdec backends now use a single pixel format, and the format is
always checked.
Also, the init_decoder callback is now mandatory.
|
|
|
|
|
|
|
|
|
|
|
| |
Since vo_rpi uses MMAL for video output, which is completely
independent from the GLES overlay, we can just not redraw the
GLES screen if subtitles do not change.
(As a furhter optimization, the dispmanx overlay could be removed
if nothing is visible. But I'm not sure if adding and removing the
overlay frequently is a good idea for performance, so this could
just as well go the other way.)
|
|
|
|
|
|
|
|
| |
Slightly faster than using the dispmanx mess (perhaps to a large amount
due to the rather stupid C-only unoptimized ASS->RGBA blending code).
Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI
backend.
|
|
|
|
| |
To be used by vo_rpi.c. No functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This affects vo_opengl_cb in particular: it'll most likely auto-load
VDA, and then the VideoToolbox decoder won't work. And everything fails.
This is mainly caused by FFmpeg using separate pixfmts for the _same_
thing (CVPixelBuffers), simply because libavcodec's architecture demands
that hwaccel backends are selected by pixfmts. (Which makes no sense,
but now we have the mess.)
So instead of duplicating FFmpeg's misdesign, just change the format to
our own canonical one on the image output by the decoder. Now the GL
interop code is exactly the same for VDA and VT, and we use the VT name
only.
|
|
|
|
| |
Can happen in obscure situations and with hw decoding disabled.
|
|
|
|
| |
Apparently this is sufficient.
|
|
|
|
| |
Small bug, much pain.
|
|
|
|
| |
It's unnecessary and slow. Doesn't help too much, though.
|
|
|
|
|
|
|
| |
We must not use the frame PTS in any case. In this case, it fails
because nothing sets it up to wake up. This typically caused the player
to apparently "pause", until something else waked it up, like moving the
mouse and other events.
|
|
|
|
| |
Fixes #503
|
|
|
|
|
|
|
|
| |
This VO is special because it normally doesn't block on vsync, but can
be made to do so. Supposedly the MMAL video output API merely sets a
"current frame" field when sending an output frame, and the firmware
will pick up whatever frame that field is set to at the time of a
vsync.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If this mode is enabled, the player tries to strictly synchronize video
to display refresh. It will adjust playback speed to match the display,
so if you play 23.976 fps video on a 24 Hz screen, playback speed is
increased by approximately 1/1000. Audio wll be resampled to keep up
with playback.
This is different from the default sync mode, which will sync video to
audio, with the consequence that video might skip or repeat a frame once
in a while to make video keep up with audio.
This is still unpolished. There are some major problems as well; in
particular, mkv VFR files won't work well. The reason is that Matroska
is terrible and rounds timestamps to milliseconds. This makes it rather
hard to guess the framerate of a section of video that is playing. We
could probably fix this by just accepting jittery timestamps (instead
of explicitly disabling the sync code in this case), but I'm not ready
to accept such a solution yet.
Another issue is that we are extremely reliant on OS video and audio
APIs working in an expected manner, which of course is not too often
the case. Consequently, the new sync mode is a bit fragile.
|
|
|
|
|
|
|
| |
While the "old" libavcodec vdpau API is not deprecated (only the very-
old API is), it's still relatively complicated code that badly
duplicates the much simpler newer vdpau code. It exists only for the
sake of older FFmpeg releases; get rid of it.
|
|
|
|
|
| |
This will happen when input EOF is reached but output frames remain
to be shown.
|
|
|
|
|
|
|
|
| |
VDA is being deprecated in OS X 10.11 so this is needed to keep hwdec working.
The code needs libavcodec support which was added recently (to FFmpeg git,
libav doesn't support it).
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Pretty stupid: vo_get_vsync_interval() returns a negative value if the
display FPS is unknown (e.g. xrandr not compiled), and the comparison
whether the value is below 0 fails later because it's assigned to an
unsigned int.
Regression since commit e3d85ad4.
Also, fix some comments in vo.c.
|
|
|
|
|
|
|
|
| |
When full_redraw is set, we always need to take the draw_image path. If
it's not set, we can try VOCTRL_REDRAW_FRAME (and fallback to draw_image
if that fails).
Fixes #2184.
|
|
|
|
|
|
|
|
|
| |
The jpeg-optimize and jpeg-baseline options were undocumented, and
they're also pretty useless. There's no reason to ever change them.
Also, don't write jpeg baseline images. This just makes compression
worse for the sake of rather questionable compatibility with ancient
decoders.
|
|
|
|
|
|
| |
If the framedrop count happens to be incremented with
vo_increment_drop_count() during rendering, these increments were
counted twice, because these events also set in->dropped_frame.
|
|
|
|
| |
No functional changes.
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A user complains that it leads to the dxva driver failing, leading to
messages like this:
[ffmpeg/video] h264: Failed to execute: 0x8007000e
[ffmpeg/video] h264: hardware accelerator failed to decode picture
Reportedly, this happens only with vo_direct3d, not with vo_opengl. The
only difference is that vo_direct3d attempts to share the D3D device
with the decoder. Possibly the error is that the device in the VO is not
created with D3DCREATE_MULTITHREADED. Change this.
Probably fixes #2178.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually
use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context,
using WCHAR instead is more portable.
This affects only non-MinGW parts, so not all uses of wchar_t need to
be changed. For example, terminal-win.c won't be used on Midipix at
all. (Most of io.c won't either, so the search & replace here is more
than necessary, but also not harmful.)
(Midipix is not useable yet, so this is just preparation.)
|
|
|
|
|
| |
They are not entirely full-featured in GLES 2, but they appear to
provide all we need. Thus we can enable them.
|
| |
|
|
|
|
| |
Reverse engineered from tvservice.c.
|
|
|
|
|
|
| |
Instead of special-casing hwdec in the place where the video textures
are used, just set the textures in the image upload function. The
renderer code doesn't need to know whether hwdec interop is used at all.
|
|
|
|
|
|
|
|
|
|
| |
This detected whether an OpenGL context still provided legacy OpenGL if
the OpenGL version is modern (>= 3.0). This was actually only needed for
vo_opengl_old, because it relied on legacy functions. Since it's gone,
this code isn't needed either.
(Also, the removed comment about OpenGL 3.0 was wrong: you could just
query GL_CONTEXT_FLAGS and see if the forward compatible bit was set.)
|
|
|
|
|
| |
This resulted in wrong behavior for values of scale-param1 between 0.0
and 0.5 (not inclusive).
|
|
|
|
|
|
| |
Only do it when the number of threads is autodetected, as more than 16
threads are still considered not recommended. (libavcodec prints a
warning.)
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit fb8d15836695e883355c5ec6ff8463e7bbf39461.
Reallocating the FBOs on every resize is very slow. It affects resizing
the window, as well as changing the video size itself with e.g.
panscan. Since the original change was done based on a single user
complaint, but the change itself caused a lot of complaints, we decided
to just revert it.
|
|
|
|
| |
In particular, get rid of the EUSERBROKEN message.
|
|
|
|
|
|
|
|
|
|
| |
Instead of calling it "future frames" and adding or subtracting 1 from
it, always call it "requested frames". This simplifies it a bit.
MPContext.next_frames had 2 added to it; this was mainly to ensure a
minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2;
together with the other changes, this can be the exact size of the
array.
|
|
|
|
|
| |
This was requested multiple times by users, and it's not hard to
implement and/or maintain.
|
|
|
|
|
| |
This was supposed to have changed back when oversample was reintroduced
in 3007250. Fixes #2155.
|
|
|
|
|
|
|
|
|
| |
This was requested by someone.
All code was written by myself; some minor changes by 2 contributors who
agreed to general LGPL relicensing. 1 line of code is by someone unknown
who possibly wasn't asked (setting the "display_fps" variable), and
which can be reasonably ignored as it makes up only 0.1% of the file.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I still have no idea why this is needed, maybe some weird off-by-one
in some shitty driver? Either way, the difference for a working setup
shouldn't be too major, the most noticeable effect would be somewhat worse
performance when resizing the video during playback with interpolation
enabled using the mouse.
That's a specific enough side effect for me to not care as much about it.
Fixes #1814.
|
|
|
|
|
|
| |
Generates too much discussion and confusion.
Fixes #2051.
|
|
|
|
|
|
|
|
| |
There are some situations when redrawing is requested, but the current
frame was deleted. This could happen when switching e.g. hw decoding
mid-stream.
Separate uploading/drawing and fix the condition.
|
|
|
|
|
|
|
| |
Just avoid some code duplication. Also, gl_video_set_options() having a
queue size output parameter is weird at best. While I don't appreciate
that this commit suddenly requires gl_video.c to deal with vo.c directly
in a special case, it's simply the best place to put this function.
|
|
|
|
|
|
| |
That was 2 too many.
Also fix a documentation comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VO will be provided with future frames even if the format changes
mid-stream. This caused a crash if these frames were actually used (i.e.
interpolation mode was enabled).
Fixes a crash when deinterlacing is toggled during playback, and the
deinterlacer changes the stream format (as it can happen e.g. if the
decoder outputs nv12, which in turn happens with hw decoding).
(On a side note, future frames are always non-NULL. Also, the current
frame is of course always in the correct format.)
|
|
|
|
| |
Appears to be required by some hardware. Whatever.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vaQueryImageFormats() returns a randomly ordered list - so we shouldn't
assume the first format on the list which works is the best. This
effectively switches to nv12 instead of yuv420p on some drivers.
We handle this by reusing va_to_imgfmt[], and ordering it by preference.
We hardcode that GPUs prefer nv12 pver yuv420p. In theory we could do
complicated probing (allocate dummy surface + use vaDeriveImage on it,
then retrieve the FourCC) - but all things which could break assumption
in the future are not supported yet (like 10 bit or 4:4:4), so this is
fine.
|
|
|
|
|
|
| |
This reverts commit d660e67be9cc7d79d81e0c09c2720ea6d0a35e3a.
Fixes #2123.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes problems with --vo=opengl:interpolation. The issue here is that
vo_opengl retains more surfaces than what was preallocated for the
decoder. Until now, we just explicitly failed to decode frames for which
no additional surfaces are available. Since modern drivers usually are
fine with not "registering" surfaces before the decoder is created, just
allow allocating additional surfaces if needed.
(We also could probably recreate the HW decoder, since the HW decoder
should be stateless. But let's try to avoid raising the overall
complexity of the code.)
|
|
|
|
|
| |
After recent changes, there is no reason why gl_video_set_image() should
exist anymore. So merge it back into gl_video_upload_image().
|
|
|
|
|
|
|
| |
The interlaced frame test needs to be aware that the input mpi might be
NULL - this happens at the end of a stream when the input frames have
all been submitted but frames still need to be drained from the
decoder.
|
|
|
|
|
|
|
|
|
| |
Outputting the detected OpenGL features was useless and redundant with
the extension loading output.
Also, remove MPGL_CAP_3D_TEX from OpenGL(ES) 3.0. This block didn't
include the glTexImage3D function, so that was pointless and couldn't
have worked. The OpenGL 2.1 block does it correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VDPAU has explicit support for rotating surfaces, and it is far less
expensive than using the normal rotation filter (which would require
reading video frames back into system memory), it is desirable to
implement the VO rotation capability.
To do this, we need to render the video frames to an output surface,
without rotation, and then render from that surface to the final
output surface to apply the rotation. It is important that the
intermediate surface is the same size as the final one (only not
rotated) so that hqscaling can be applied if requested by the user.
(hqscaling is a mixer capability and so takes effect when the video
surface is rendered to an output surface)
Finally, we must remember to explicitly clear the final output
surface as VDPAU only auto-clears output surfaces when rendering video
surfaces.
|
|
|
|
| |
Closes #2102.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, vdpau decoded frames are passed directly to a suitable
vo (vo_vdpau or vo_opengl) without ever touching system memory. This
is efficient for output purposes, but prevents any of the regular
filters from being used with such frames.
This new filter implements a read-back step to pull the frames back
into system memory where they can be acted on by other filters.
Eventually the frames will be sent to the vo as if they were normal
software-decoded frames.
Note that a vdpau compatible vo must still be used to ensure that
the decoder is properly initialised.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Fixes #2111.
|
|
|
|
| |
Leave the libavfilter wrapper only.
|
|