These commands are counterparts of sub_add/sub_remove/sub_reload which
work for external audio file.
Signed-off-by: wm4 <wm4@nowhere>
(minor simplification)
Basically, the declared option name and the name passed to the
parse_obj_settings_list() must be the same.
Fixes the issue addressed in #1550, but differently.
These were derived from dividing our assumed video gamut (1.961) by some
typical screen values (2.2 for dimly lit and 2.4 for pitch black):
1.961/2.4 = 0.8170833333333334 ~= 0.8
1.961/2.2 = 0.8913636363636364 ~= 0.9
Before this, enabling :gamma in combination with :sigmoid and probably a few
other things results in ugly artifacts because the video isn't clamped until
after the :gamma was applied (or at all, if the cms_matrix is unused).
Previously we let the user use the audio device ID, but this is not persistent
and can change when plugging in new devices. That of course made it quite
worthless for storing it as a user setting for GUIs, or for user scripts.
In theory getting the kAudioDevicePropertyDeviceUID can fail but it doesn't
on any of my devices, so I'm leaving the error reporting quite high and see if
someone complains.
At least the opengl-hq VO allocates additional resources when
downscaling a lot, which is just a waste.
Also see #1547 (although I doubt that this is the cause; if it is,
a real fix will be required).
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)
This also requires every hwdec backend to identify itself (see hwdec.h
changes).
This does what it's documented to do.
The implementation reuses the code in mpv_detach_destroy(). Due to the
way async requests currently work, just sending a synchronous dummy
request (like a "ignore" command) would be enough to ensure
synchronization, but this code will continue to work even if this
changes.
The line "ctx->event_mask = 0;" is removed, but it shouldn't be needed.
(If a client is somehow very slow to terminate, this could silence an
annoying queue overflow message, but all in all it does nothing.)
Calling mpv_wait_async_requests() and mpv_wait_event() concurrently is
in theory allowed, so change pthread_cond_signal() to
pthread_cond_broadcast() to avoid missed wakeups.
As requested in issue #1542.
Resizing was happening before reconfig, so src_rect_rot was outdated and
didn't include the rotation. This resulted in corrupted rendering on
initial display, which fixed itself after the first time the window was
somehow resized.
This fixes usage when the bundle is used on the same machine that Python/Cython
was compiled on. It doesn't fix the harder problem of packaging a full Python
installation in the mpv app bundle (and I'm not sure we actually want that).
Fixes#1549
Might fix behavior with mkv files that use ordered chapters and have
cover art tags. In my opinion, this should actually have worked (because
cover art pseudo-tracks are strictly appended), but I don't have a
sample file to test at hand.
Opening the stream and opening the demuxer are both done asynchronously,
meaning the player reacts to client API requests. They also can
potentially take a while. Thus it's better to process outstanding
property changes, so that change events are sent for properties that
were changed during opening.
In particular, this would fix the sending the initial change event. It
was easily missed because MPV_EVENT_FILE_LOADED usually triggered it,
but the actual property could change only later, because audio
initialization really is kind of asynchronous to it.
This probably fixes#1544.
I guess this was supposed to be some sort of optimization, but even
though it probably works, it's pretty meaningless and I couldn't measure
a difference. One special case killed.
This reverts commit 7b3feecbc2.
It's broken, hr-seek never ends at a video position before seek pts.
Not sure what I was thinking, although it did work anyway when
artificially forcing a video frame to display before seek pts.
At least there is _some_ problem if this happens. It would mean that
audio is playing slower than video. Normally, video is synced to audio,
so if audio stops playback completely, video will not advance at all.
But using things like --autosync, it's well possible that this kind of
desync happens.
Move the update_avsync_before_frame() call further down. Moving it
closer to where the time_frame value is used (and which the function
updates) should make the code more readable. With this change, there's
no need anymore to reset the time_frame value on the video reconfig
path.
Move the update_avsync_after_frame() up. Now no meaningful amount of
time passes since the previous get_relative_time() call anymore, and the
second one can be removed.
FFmpeg and Libav have the stupid practice of replacing and deprecating
API symbols on the same day. So with FFmpeg git, this is useless and
will print a compile time warning, while it's required with all stable
releases, and might lead to decoding errors with xvid/avi (apparently).
Add a comment before someone writes a patch and I have to explain it all
over again.
A small simplification. Couldn't be done before, because it was also
used by the OSD code, which required disjoint quads in a single draw
call.
Also mess with the unrelated code in gl_osd.c to simplify it a little
as well.
Now it shows one of:
- "Subtitles hidden" (sub-visibility=no)
- "Subtitles visible" (sub-visibility=yes, sub!=no)
- "Subtitles visible (but no subtitles selected)" (otherwise)
It should be a bit more self-explanatory than before. On the other hand,
I have no clue about UI issues.
This also gets close to what's reasonably possible with the OSD
expansion string syntax, which is why it looks so awful.
Hardware decoding/displaying with vo_opengl is done by replacing the
normal video textures with textures provided by the hardware decoding
API OpenGL interop code. Often, this changes the format (vaglx and vdpau
return RGBA, vda returns packed YUV).
If the format is changed, there was a chance (or at least a higher
potential for bugs) that the shader generation code could be confused by
the mismatch of formats, and would create incorrect conversions.
Simplify this by requiring the hwdec interop driver to set the format it
will return to us. This affects all fields, not just some (done by
replacing the format with the value of the converted_imgfmt field in
init_format), in particular fields like colorlevels.
Currently, no hwdec interop driver does anything sophisticated, and the
win is mostly from the mp_image_params_guess_csp() function, which will
reset fields like colorlevels to expected value if RGBA is used.
Reduces the size of gl_video.c a bit further.
This also uses a separate vertex array object for OSD elements, so the
video one can be simplified slightly.
OSD shader generation is still in gl_video.c, which leads to the strange
additional parameter to mpgl_osd_init(). The issue is that video
parameters influence the OSD shader (????), and also OSD needs to go
through the screen colormanagement.
Useful if we want to reduce the size of gl_video.c further.
To some degree this emulates traditional glDrawArrays() usage. It also
leaves a loophole for avoiding a reupload every time by leaving
ptr==NULL, although this is unused for now.
default_tex_params() and texture_size() are each called only once, so
move inline/reimplement them at the caller.
image_dw/dh were unused. texture_w/h, image_format, and component_bits
were rarely used, and can be replaced. Regroup some other fields.
Rename surface_num to surface_idx, because the former sounded like a
count, and not an index. Move fbosurface_next() closer to its callers
too.
Move the DebugMessageCallback() code to gl_utils.c (also simplify it
by always setting the callback, instead of only when it changes).
This is somewhat messy, because fbotex_init() itself was depending on
some gl_video parameters unrelated to FBO creation (like what scaler was
in use - what the fuck did this check do in this function?), so this
commit does a bit more than moving code around. In particular, the FBO
for the separate scaling intermediate step now always uses GL_NEAREST
sampling, and all FBOs are destroyed/recreated on renderer
reinitialization.
This also moves the function matrix_ortho2d() - trivial enough not to
put it into a separate commit.
Windows Intel drivers seem to reject some (AFAIK) valid GLSL. Make them
happy.
<rossy> GL_RENDERER='Intel(R) HD Graphics 4400'
<rossy> GL_VERSION='3.0.0 - Build 10.18.14.4080'
<rossy> GL_SHADING_LANGUAGE_VERSION='1.30 - Build 10.18.14.4080'
...into its own functions. The central playloop function is still too
big, but looks much cleaner now.
No changes in functionality. The code moved to handle_playback_restart()
is unindented by 1 level and moving it out of the if condition around.
The if condition is inverted and early-exits from the function. Also
some comments are changed.
mpctx->audio_delay always has the same value as opts->audio_delay. (This
was not the case a long time ago, when the audio-delay property didn't
actually write to opts->audio_delay. I think.)
Handles stupid boilerplate OpenGL requires you to handle. It's the same
code as in gl_video.c, although if no VAOs are available, the fallback
code rebinds them on every draw call instead of just once.
gl_common.c contained the function loader (which is big) and additional
utility functions (not so big, but will grow when moving more out of
gl_video.c). Just split them. There are no changes other than some
modifications to comments.
