Will still hide playlist items with long enough filenames and osd-font-size
but not as soon.
osc messages should now preserve their scaling with fullscreen toggling and
cycling through audio-only files and files with video.
Closes#4081, #4083, #4102
Requested. The property semantics are a bit muddy due to lack of effort.
Anticipated use is different display of cache status, so it should not
matter anyway.
The delay between call to .resize, which cleared the buffer, and
actually rendering the first video frame, was significant, resulting in
short flicker on navigation and resizing. This was especially visible
when zooming and navigating between images.
Now the clearing is scheduled to happen just before the rendering, which
looks to be good enough even without double buffering.
If vaapi was found, but neither the old or new libavcodec vaapi hwaccel
API, then HAVE_VAAPI_HWACCEL will be defined, but not _OLD or _NEW. The
HAVE_VAAPI_HWACCEL define pretty much exists only for acrobatics with
our own waf dependency checker helper code.
The new API works like the new vaapi API, using generic hwaccel support.
One minor detail is the error message that will be printed if using
non-4:2:0 surfaces (which as far as I can tell is completely broken in
the nVidia drivers and thus not supported by mpv). The HEVC warning
(which is completely broken in the nVidia drivers but should work with
Mesa) had to be added to the generic hwaccel code.
This also trashes display preemption recovery. Fuck that. It never
really worked. If someone complains, I might attempt to add it back
somehow.
This is the 4th iteration of the libavcodec vdpau API (after the
separate decoder API, the manual hwaccel API, and the automatic vdpau
hwaccel API). Fortunately, further iterations will be generic, and not
require much vdpau-specific changes (if any at all).
Might be useful for other backends too. For context_vdpau, resize
handling, presentation, and handling the mapping state becomes somewhat
less awkward.
In some cases, such as when using the libmpv opengl-cb API, or with
certain vo_opengl backends, the main framebuffer is never accessed.
Instead, rendering is done to a FBO that acts as back buffer. This meant
an incorrect/broken bit depth could be used for dithering.
Change it to read the framebuffer depth lazily on the first render call.
Also move the main FBO field out of the GL struct to MPGLContext,
because the renderer's init function does not need to access it anymore.
Useful for testing. Unfortunately, the nVidia EGL driver ignores this,
and returns a GLES 3.2 context anyway (which it is allowed to do). Might
still be useable with ANGLE, which will really give you a GLES 2 context
if you ask for it.
When dumb mode is used (the "simple" rendering path), respect the dither
options. Options should never be ignored (except in GLESv2 mode); either
they should be respected in dumb mode, or they should disable dumb mode.
In this case, the former applies.
This actually fixes the dreaded errors during resizing. It works pretty
much like before, except each surface is reallocated before it's used.
It implies surfaces with the old size remain in the presentation queue
and will be displayed.
Don't assume 0 is an invalid object handle. vdpau with its weird API
design makes all objects indexes, with 0 being a perfectly valid and
common value. You need to use VDP_INVALID_HANDLE, which is not 0.
Don't crash if init fails at vdpau initialization. It's because
mp_vdpau_destroy(NULL) crashes. Simplify it.
Destroy output surface backed FBO before output surface. Also, strictly
bookkeep the map/unmap calls (and unmap surfaces before destroying the
FBO/texture). I can't see a change in the weird errors when resizing the
window, but I guess it's slightly more correct.
Add the GL_WRITE_DISCARD_NV symbol to header_fixes.h, because we might
fail compilation with headers that do not contain the vdpau extension
(well, probably doesn't matter).
The gl_timer_last_us() function could access samples[-1]. Fix by
coercing to unsigned, so the % will put it into index [0,max). The
real value returned in this corner case doesn't mean too much, I
guess.
As the manpage says, this has no value other than adding bugs.
It uses code based on context_x11.c, and basically does very stripped
down context creation (no alpha support etc.). It uses vdpau for
display, and maps vdpau output surfaces as FBOs to render into them.
This might be good to experiment with asynchronous presentation. For
now, it presents synchronously, with a 4 frame delay (which should whack
off A/V sync). The forced 4 frame delay is probably also why interaction
feels slower.
There are some weird vdpau errors on resizing and uninit. No idea what
causes them.
Should have done this 1000 years ago. Now GL backends can use mp_log
macros directly on the MPGLContext, instead of doing stupid things like
for example MP_WARN(ctx->vo, ...).
This is just a pointless refactor with the only goal of making
image_writer_opts.format a number.
The pointless part of it is that instead of using some sort of arbitrary
ID (in place of a file extension string), we use a AV_CODEC_ID_. There
was also some idea of falling back to the libavcodec MJPEG encoder if
mpv was not linked against libjpeg, but this fails. libavcodec insist on
having AV_PIX_FMT_YUVJ420P, which we pretend does not exist, and which
we always map to AV_PIX_FMT_YUV420P (without the J indicating full
range), so encoder init fails. This is pretty dumb, but whatever. The
not-caring factor is raised by the fact that we don't know that we
should convert to full range, because encoders have no proper way to
signal this. (Be reminded that AV_PIX_FMT_YUVJ420P is deprecated.)
The buffer_size may be updated before the process callback is called for
the first time. Or, the connection graph could change, which changes the
latency of the pipeline after mpv's output. Ensure we keep on top of
these changes by registering callbacks to update our latency estimation.
This also will set image=NULL, if the video frame is marked as hwaccel,
and could not be copied to normal RAM. This will probably change the
error message (due to screenshot_get() returning NULL, instead of making
image conversion fail at a later point), but the behavior is the same
anyway.
The function tried to do something clever but ignored the fact that
the middle button followed the left button rather than the right.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
On some DVDs, title number is not necessarily the same as the (first)
PGC number. (Most often they are equal, since there's usually exactly
one PGC per title, which is likely why this issue wasn't noticed
before.) When searching for audio/subtitle metadata, we want to look
at the actual PGC we're about to play. See discussion in issue #4235.
Signed-off-by: wm4 <wm4@nowhere>
This means the subtitles will show as "intended".
For some weird reason, --sub-ass-style-override is the option that
controls style override, which implies it's specific to ASS. While that
seems weird and doesn't always reflect reality, I don't care about that
now.
I guess that's the full extent I still care about nVidia's broken
garbage. In theory, we could always force the video mixer (which is the
only method getting the video data that works), but why bother.
It appears some device can be missing if we filter too many. In
particular, I've seen devices starting with "front" and "sysdefault"
being mapped to different hardware. I conclude that it's not sane trying
to present a nice device list to users in ALSA. It's fucked. (Although
kodi appears to attempt some intense "beautification" of the device
list, which includes parsing parameters from the device name and such.
Well, let's not.)
No other audio API requires such ridiculous acrobatics.
Apparently POLLERR can be set if poll is called while the device is in
the SND_PCM_STATE_PREPARED state. So assume that we can simply call
snd_pcm_status() to check whether the error is because the device went
away (i.e. we expect it to return ENODEV if this happened).
This avoids sporadic device lost warnings and AO reloads. The actual
device lost case is untested.
We have direct rendering with hardware decoding now (so no SSE4 for
memcpy from GPU memory required), and also OpenGL drivers are not so
much of a problem anymore with ANGLE being default.
due to the see-through nature of the title bar and our standard black
window background, the title bar appears dark grey opposed to the
expected light grey.
we change the window background to white but at the same time set the
background of the enclosed view to black. that way the title bar has a
white background and the background of our video stays black in all
cases. this prevents white flashing in some cases when the video is
resized with too heavy render settings.
Probably does much more:
+ add support DVB-T2
* DVB params set to AUTO by default
* MAX_CARDS: 4 -> 16
* DMX_SET_BUFFER_SIZE: 64kb -> 256kb
+ add DTV_CLEAR call before tune
+ add logic from https://github.com/olifre/mpv/commits/dvb-mixed-api-scan
* rename type to delsys
* single playlist per adapter
* card -> adapter
* fix channels order in playlist
* update internal api
* auto fallback to old DVB API on tune
* fix DELSYS_SUPP_MASK value
* remove tone - unused
* add channel mem zeroize in config parser
+ add code from libdvbv5 for detect delivery systems
* SYS_DVBC_ANNEX_AC replaced to SYS_DVBC_ANNEX_A + SYS_DVBC_ANNEX_C
Signed-off-by: wm4 <wm4@nowhere>
