Commit Graph

203 Commits

Author SHA1 Message Date
wm4 c9963c1368 vo: fix typo in comment 2020-02-09 18:32:28 +01:00
wm4 7bb3f53cf5 command, vo: add a mechanism for runtime DPI scale changes
Follow up to commit a58585d5e0. It turned out that the OSX backend
needs this.
2020-01-09 19:13:42 +01:00
wm4 8e620c8e76 command: add property returning hidpi scale 2019-12-20 13:00:39 +01:00
wm4 2a4d7c4aa8 command, vo: remove old option change notification mechanisms
These all have been replaced recently.

There was a leftover in window.swift. It couldn't have done anything
useful in the current state of the code, so drop these lines.
2019-12-17 23:18:17 +01:00
Philip Langdale 61b8e1d436 wayland: update Maximize and Minimize handling to use new options
I wanted to get this done quickly as I introduced the new VOCTRL
behaviour for minimize and maximize and it was immediately made
legacy, so best to purge it before anyone gets confused.

I did not sort out fullscreen as that's more involved and not something
I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN
usage with the new option change mechanism as that seemed simple
enough.
2019-12-01 09:39:51 +08:00
wm4 40c2f2eeb0 command: change window-minimized/window-maximized to options
Unfortunately, this breaks window state reporting for all VOs which
supported it. This can be fixed later (for x11 in the next commit).
2019-11-29 13:56:58 +01:00
wm4 4e4252f916 x11: use new option stuff to implement fullscreen
- remove VOCTRL_FULLSCREEN and VOCTRL_GET_FULLSCREEN
- have your own m_config_cache for the fullscreen option
  (vo->opts_cache cannot be used because you lose per-option change
  notifications, and it'd be a mess anyway)
- use VOCTRL_VO_OPTS_CHANGED to update it
  (it's used for convenience)
- when updating it, check for the fullscreen option
  (wasn't sure how to do it best; currently, it compares the raw
  option pointers, but this could be changed)
- do not send VO_EVENT_FULLSCREEN_STATE on FS change
- instead write the option on FS change
  (assign in opt. struct + m_config_cache_write_opt)
2019-11-29 13:56:58 +01:00
Philip Langdale c2bd3b1ecc command: add `window-maximized` and make `window-minimized` settable
If we want to implement window pseudo-decorations via OSC, we need a
way to tell the vo to minimize and maximize the window. Today, we have
minimized as a read-only property, and no property for maximized.

Let's made minimized settable and add a maximized property to go with
it. In turn, that requires us to add VOCTRLs for minimizing or
maximizing a window, and an additional WIN_STATE to indicate a
maximized window.
2019-11-29 16:56:20 +08:00
dudemanguy e0895e097b Revert "vo: add support for externally driven renderloop and make wayland use it"
The externally driven renderloop was originally added for the wayland
context (to make display sync somewhat work), but it has a lot of issues
with mpv's internal structure. A different approach should be used.

This reverts commit a743fef837.
2019-10-10 17:41:19 +00:00
sfan5 508e35881e context_android: move common code to a separate file
In preparation for a Vulkan Android context.
This also replaces querying for EGL_WIDTH and EGL_HEIGHT
with equivalent ANativeWindow calls.
2019-09-27 00:05:06 +03:00
wm4 257534ed18 vo: remove unused equalizer control remains
Equalizer control was redone in 03cf150ff3 (over 2 years
ago). Ever since, the equalizer control structs and the GET voctrl have
been unused. Only the SET voctrl is still used as notification mechanism
(actually a bad hack to avoid some further option change handling
complexity).

Remove the unused parts.
2019-09-20 00:45:17 +02:00
wm4 f4ce3b8bb9 vo, vo_gpu, glx: correct GLX_OML_sync_control usage
I misunderstood how this extension works. If I understand it correctly
now, it's worse than I thought. They key thing is that the (ust, msc,
sbc) tripple is not for a single swap event. Instead, (ust, msc) run
independently from sbc. Assuming a CFR display/compositor, this means
you can at best know the vsync phase and frequency, but not the exact
time a sbc changed value.

There is GLX_INTEL_swap_event, which might work as expected, but it has
no EGL equivalent (while GLX_OML_sync_control does, in theory).

Redo the context_glx sync code. Now it's either more correct or less
correct. I wanted to add proper skip detection (if a vsync gets skipped
due to rendering taking too long and other problems), but it turned out
to be too complex, so only some unused fields in vo.h are left of it.
The "generic" skip detection has to do.

The vsync_duration field is also unused by vo.c.

Actually this seems to be an improvement. In cases where the flip call
timing is off, but the real driver-level timing apparently still works,
this will not report vsync skips or higher vsync jitter anymore. I could
observe this with screenshots and fullscreen switching. On the other
hand, maybe it just introduces an A/V offset or so.

Why the fuck can't there be a proper API for retrieving these
statistics? I'm not even asking for much.
2018-12-06 10:32:27 +01:00
wm4 b1ba7de34d vo: use a struct for vsync feedback stuff
So new useless stuff can be easily added.
2018-12-06 10:30:25 +01:00
wm4 83884fdf03 vo_gpu: glx: use GLX_OML_sync_control for better vsync reporting
Use the extension to compute the (hopefully correct) video delay and
vsync phase.

This is very fuzzy, because the latency will suddenly be applied after
some frames have already been shown. This means there _will_ be "jumps"
in the time accounting, which can lead to strange effects at start of
playback (such as making initial "dropped" etc. frames worse). The only
reasonable way to fix this would be running a few dummy frame swaps at
start of playback until the latency is known. The same happens when
unpausing.

This only affects display-sync mode.

Correct function was not confirmed. It only "looks right". I don't have
the equipment to make scientifically correct measurements.

A potentially bad thing is that we trust the timestamps we're receiving.
Out of bounds timestamps could wreak havoc. On the other hand, this will
probably cause the higher level code to panic and just disable DS.

As a further caveat, this makes a bunch of assumptions about UST
timestamps. If there are delayed frames (i.e. we skipped one or more
vsyncs), the latency logic is mostly reset. There is no attempt to make
the vo.c skipped vsync logic to use this. Also, the latency computation
determines a vsync duration, and there's no effort to reconcile or share
the vo.c logic for determining vsync duration.
2018-12-06 10:30:14 +01:00
wm4 0ab3184526 encode: get rid of the output packet queue
Until recently, ao_lavc and vo_lavc started encoding whenever the core
happened to send them data. Since audio and video are not initialized at
the same time, and the muxer was not necessarily opened when the first
encoder started to produce data, the resulting packets were put into a
queue. As soon as the muxer was opened, the queue was flushed.

Change this to make the core wait with sending data until all encoders
are initialized. This has the advantage that we don't need to queue up
the packets.
2018-05-03 01:08:44 +03:00
wm4 958053ff56 vo_lavc: explicitly skip redraw and repeated frames
The user won't want to have those in the video (I think). The core can
sporadically issue redraws, which is what you want for actual playback,
but not in encode mode. vo_lavc can explicitly detect those and skip
them. It only requires switching to a more advanced internal VO API.

The comments in vo.h are because vo_lavc draws to one of the images in
order to render OSD. This is OK, but might come as a surprise to whoever
calls draw_frame, so document it. (Current callers are OK with it.)
2018-05-03 01:08:44 +03:00
wm4 8135e25600 vo: add vo_reconfig2()
1. I want to get away from mp_image_params (maybe).
2. For encoding mode, it's convenient to get the nominal_fps, which is
   a mp_image field, and not in mp_image_params.
2018-04-29 02:21:32 +03:00
wm4 76844c9c51 vo: move DR helper code to a separate source file
So it can be reused by vo_libmpv.c, which needs to use it in a slightly
different way.
2018-04-29 02:21:32 +03:00
wm4 290341c777 vo: pass through framedrop flag differently
There is some sort-of awkwardness here, because option access needs to
happen in a synchronized manner, and the framedrop flag is not in the VO
option struct. Remove the mp_read_option_raw() call and the awkward
change notification via VO_EVENT_WIN_STATE from command.c, and pass it
through as new vo_frame flag.
2018-03-15 23:13:53 -07:00
wm4 b037121430 client API: deprecate opengl-cb API and introduce a replacement API
The purpose of the new API is to make it useable with other APIs than
OpenGL, especially D3D11 and vulkan. In theory it's now possible to
support other vo_gpu backends, as well as backends that don't use the
vo_gpu code at all.

This also aims to get rid of the dumb mpv_get_sub_api() function. The
life cycle of the new mpv_render_context is a bit different from
mpv_opengl_cb_context, and you explicitly create/destroy the new
context, instead of calling init/uninit on an object returned by
mpv_get_sub_api().

In other to make the render API generic, it's annoyingly EGL style, and
requires you to pass in API-specific objects to generic functions. This
is to avoid explicit objects like the internal ra API has, because that
sounds more complicated and annoying for an API that's supposed to never
change.

The opengl_cb API will continue to exist for a bit longer, but
internally there are already a few tradeoffs, like reduced
thread-safety.

Mostly untested. Seems to work fine with mpc-qt.
2018-02-28 00:55:06 -08:00
Aman Gupta 288ed66a35 video: rename VO_CAP_NOREDRAW to VO_CAP_NORETAIN 2018-02-17 23:01:47 -08:00
Akemi c5e4538bc4 cocoa-cb: initial implementation via opengl-cb API
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739,
#2392, #2217
2018-02-12 04:49:15 -08:00
wm4 9f595f3a80 vo_gpu: make screenshots use the GL renderer
Using the GL renderer for color conversion will make sure screenshots
will use the same conversion as normal video rendering. It can do this
for all types of screenshots.

The logic when to write 16 bit PNGs changes. To approximate the old
behavior, we decide by looking whether the source video format has more
than 8 bits per component. We apply this logic even for window
screenshots. Also, 16 bit PNGs now always include an unused alpha
channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no
RGB064. RGB48 is 3 bytes and usually not supported by GPUs for
rendering, so we have to use RGBA64, which forces an alpha channel.

Will break for users who use --target-trc and similar options.

I considered creating a new gl_video context, but it could double GPU
memory use, so I didn't.

This uses FBOs instead of glGetTexImage(), because that increases the
chance it could work on GLES (e.g. ANGLE). Untested. No support for the
Vulkan and D3D11 backends yet.

Fixes #5498. Also fixes #5240, because the code for reading back is not
used with the new code path.
2018-02-11 17:45:51 -08:00
Akemi 828f38e10d video: change some remaining vo_opengl mentions to vo_gpu 2018-01-20 14:43:49 -08:00
sfan5 0030e049cd player: add internal `vo-resize` command
Intended to be used with the properties from previous commit.
2017-12-27 14:29:15 -07:00
Rostislav Pehlivanov a743fef837 vo: add support for externally driven renderloop and make wayland use it
Fixes display-sync (though if you change virtual desktops you'll need to seek
to re-enable display-sync) partially under wayland.

As an advantage, rendering is completely disabled if you change desktops or
alt+tab so you lose no performance if you leave mpv running elsewhere as long
as it isn't visible.

This could also be ported to other VOs which supports it.
2017-12-05 08:26:24 +00:00
Aman Gupta 6f0fdac6f1 vo: add VO_CAP_NOREDRAW for upcoming vo_mediacodec_embed
MediaCodec uses a fixed number of output buffers to hold frames, and
expects that output buffers will be released as soon as possible. Once
rendered, the underlying frame is automatically released and cannot be
reused or rerendered.

The new VO_CAP_NOREDRAW forces mpv to release frames immediately after
they are rendered or dropped, to ensure that MediaCodec decoder does not
run out of buffers and stall out.
2017-10-09 18:36:54 +02:00
Rostislav Pehlivanov 68f9ee7e0b wayland_common: rewrite from scratch
The wayland code was written more than 4 years ago when wayland wasn't
even at version 1.0. This commit rewrites everything in a more modern way,
switches to using the new xdg v6 shell interface which solves a lot of bugs
and makes mpv tiling-friedly, adds support for drag and drop, adds support
for touchscreens, adds support for KDE's server decorations protocol,
and finally adds support for the new idle-inhibitor protocol.

It does not yet use the frame callback as a main rendering loop driver,
this will happen with a later commit.
2017-10-03 19:36:02 +01:00
Niklas Haas 3faf1fb0a4
vo: avoid putting large voctrl_performance_data on stack
This is around 512 kB, which is just way too much. Heap-allocate it
instead. Also cut down the max pass count to 64, since 128 was
unrealistically high even for vo_opengl.
2017-09-11 18:20:18 +02:00
Niklas Haas 71c25df5e6
vo_opengl: refactor timer_pool_measure (again)
Instead of relying on power-of-two buffer sizes and unsigned overflow,
make this code more robust (and also cleaner).

Why can't C get a real modulo operator?
2017-09-11 02:42:50 +02:00
Niklas Haas 1da53248ab
vo_opengl: refactor/fix mp_pass_perf code
This was needlessly complicated and prone to breakage, because even the
references to the ring buffer could end up getting invalidated and
containing garbage data on e.g. shader cache flush. For much the same
reason why we can't keep around the *timer_pool, we're also forced to
hard-copy the entire sample buffer per pass per frame.

Not a huge deal, though. This is, what, a few kB per frame? We have more
pressing CPU performance concerns anyway.

Also simplified/fixed some other code.
2017-09-11 00:35:23 +02:00
wm4 03cf150ff3 video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.

This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.

Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.

vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.

See commit 96b906a51d for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 17:01:35 +02:00
wm4 d2bdb72b69 options: add a thread-safe way to notify option updates
So far, we had a thread-safe way to read options, but no option update
notification mechanism. Everything was funneled though the main thread's
central mp_option_change_callback() function. For example, if the
panscan options were changed, the function called vo_control() with
VOCTRL_SET_PANSCAN to manually notify the VO thread of updates. This
worked, but's pretty inconvenient. Most of these problems come from the
fact that MPlayer was written as a single-threaded program.

This commit works towards a more flexible mechanism. It adds an update
callback to m_config_cache (the thing that is already used for
thread-safe access of global options).

This alone would still be rather inconvenient, at least in context of
VOs. Add another mechanism on top of it that uses mp_dispatch_queue, and
takes care of some annoying synchronization issues. We extend
mp_dispatch_queue itself to make this easier and slightly more
efficient.

As a first application, use this to reimplement certain VO scaling and
renderer options. The update_opts() function translates these to the
"old" VOCTRLs, though.

An annoyingly subtle issue is that m_config_cache's destructor now
releases pending notifications, and must be released before the
associated dispatch queue. Otherwise, it could happen that option
updates during e.g. VO destruction queue or run stale entries, which is
not expected.

Rather untested. The singly-linked list code in dispatch.c is probably
buggy, and I bet some aspects about synchronization are not entirely
sane.
2017-08-22 15:50:33 +02:00
wm4 64d56114ed vo_opengl: add direct rendering support
Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it
does.

This reminds of the MPlayer -dr flag, but the implementation is
completely different. It's the same basic concept: letting the decoder
render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't
try to go through filters (libavfilter doesn't support this anyway).
Unless a filter can work in-place, DR will be silently disabled. MPlayer
had very complex semantics about buffer types and management (which
apparently nobody ever understood) and weird restrictions that mostly
limited it to mpeg2 style codecs. The mpv code does not do any of this,
and just lets the decoder allocate an arbitrary number of untyped
images. (No MPlayer code was used.)

Parts of the code based on work by atomnuker (starting point for the
generic code) and haasn (some GL definitions, some basic PBO code, and
correct fencing).
2017-07-24 04:32:55 +02:00
Niklas Haas dd78cc6fe7 vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:

1. mpv users can now introspect the vo_opengl passes, which is something
   that has been requested multiple times.

2. performance data is now measured per-pass, which helps both
   development and debugging.

3. since adding more passes is cheap, we can now report information for
   more passes (e.g. the blit pass, and the osd pass). Note: we also
   switch to nanosecond scale, to be able to measure these passes
   better.

4. `--user-shaders` authors can now describe their own passes, helping
   users both identify which user shaders are active at any given time
   as well as helping shader authors identify performance issues.

5. the timing data per pass is now exported as a full list of samples,
   so projects like Argon-/mpv-stats can immediately read out all of the
   samples and render a graph without having to manually poll this
   option constantly.

Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.

Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.

The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-07-01 00:58:27 +02:00
wm4 0e09533c73 vo.c, vo.h, vo_null.c: change license to LGPL
Most contributors have agreed. vo.c requires a "driver" entry for each
video output - we assume that if someone who didn't agree to LGPL added
a line, it's fine for vo.c to be LGPL anyway. If the affected video
output is not disabled at compilation time, the resulting binary will be
GPL anyway.

One problem are the changes by Nick Kurshev (usually using "nick" as SVN
username). He could not be reached. I believe all changes to his files
are actually gone, but here is a detailed listing:

fa1d5742bc: nick introduces a new VO API. It was removed in 64bedd9683.
Some of this was replaced by VOCTRLs are introduced in 7c51652a1b,
obviously replacing at least some functionality by his API.

b587a3d642: nick adds a vo_tune_info_t struct. Removed in 64bedd9683
too.

9caad2c29a: nick adds some VOCTRLs, which were silently removed in
8cc5ba5ab8 (they became unused probably with the VIDIX removal).

340183b0e9: nick adds VO-based screenshots, which got removed in
2f4b840f62. Strangely the same name was introduced in 01cf896a2f again,
but this is a coincidence and worked differently (also it was removed
yet again in 2858232220).

104c125e6d: nick adds an option for "direct rendering". It was renamed
in 6403904ae9 and fully removed in e48b21dd87.

5ddd8e92a1: nick adds code to check the VO driver preinit arg to every
single VO driver. The argument itself and any possibly remaining code
associated with it was removed in 1f5ffe7d30.

f6878753fb: nick adds header inclusion guards. We assume this is not
relevant for copyright.

Some of nick's code was merely moved to other files, such as the
equalizer stuff added in 555c676683 and moved in 4db72f6a80 and
12579136ff, and don't affect copyright of these files anymore.

Other notes:

fef7b17c34: a patch by someone who wasn't asked for relicensing added a
symbol that was removed again in 1b09f4633.

4a8a46fafd: author probably didn't agree to LGPL, but the function
signature was changed later on anyway, and nothing of this is left.

7b25afd742: the same author adds a symbol to what is vo.h today, which
this relicensing commit removes, as it was unused. (It's not clear
whether the mere symbol is copyrightable, but no need to take a risk.)

3a406e94d7, 9dd8f241ac: slave mode things by someone who couldn't be
reached. This aspect of the old slave mode was completely removed.

bbeb54d80a: patch by someone who was not asked, but the added code was
completely removed again.
2017-05-10 15:06:20 +02:00
wm4 1a2319f3e4 options: remove deprecated sub-option handling for --vo and --ao
Long planned. Leads to some sanity.

There still are some rather gross things. Especially g_groups is ugly,
and a hack that can hopefully be removed. (There is a plan for it, but
whether it's implemented depends on how much energy is left.)
2016-11-25 21:17:25 +01:00
wm4 17733bd5b8 vo_opengl: make frame reupload logic more robust
It's not that easy to decide whether a frame needs to be
reuploaded/rerendered. Using unique frame IDs for input makes it
slightly easier and more robust. This also removes the use of video PTS
in the interpolation path.

This should also avoid reuploading the video frame if it's just redrawn
in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 16:25:40 +01:00
wm4 e6291697e3 vo_opengl_cb: don't wait for redrawn frames
This also removes some extra waiting if no video is active, at least in
theory.

Also clarify the vo_frame flag comments for redraw/repeat.
2016-10-05 12:34:47 +02:00
wm4 caa14e3d45 x11: fix external fullscreen update
On x11, you can change the fullscreen via the window manager and without
mpv's involvement. In these cases, the internal fullscreen flag has to
be updated.

The hack used for this didn't really work properly. Change it
accordingly. The important thing is that the shadow copy of the option
is updated. This is still not really ideal.

Fixes #3570.
2016-09-23 12:09:48 +02:00
wm4 9179e8ed21 vo: add a unique frame_id to vo_frame
We think that this allows simpler logic than using the redraw and repeat
fields. Not used yet.
2016-09-22 20:16:44 +02:00
wm4 b8ade7c99b player, ao, vo: don't call mp_input_wakeup() directly
Currently, calling mp_input_wakeup() will wake up the core thread (also
called the playloop). This seems odd, but currently the core indeed
calls mp_input_wait() when it has nothing more to do. It's done this way
because MPlayer used input_ctx as central "mainloop".

This is probably going to change. Remove direct calls to this function,
and replace it with mp_wakeup_core() calls. ao and vo are changed to use
opaque callbacks and not use input_ctx for this purpose. Other code
already uses opaque callbacks, or has legitimate reasons to use
input_ctx directly (such as sending actual user input).
2016-09-16 14:37:48 +02:00
wm4 876ec446f3 vo: change defines to an enum
(They're flags, so it still doesn't make sense to actually name the enum
and use it as a type.)
2016-09-12 20:05:48 +02:00
wm4 7177ef3e1c vo: remove unused VOCTRL_GET_PANSCAN
It was used to determine whether the VO supports VOCTRL_SET_PANSCAN.
With all those changes to property semantics this became unnecessary,
and its only use was dropped at some point.
2016-09-08 18:59:21 +02:00
wm4 633eb30cbe options: add automagic hack for handling sub-option deprecations
I decided that it's too much work to convert all the VO/AOs to the new
option system manually at once. So here's a shitty hack instead, which
achieves almost the same thing. (The only user-visible difference is
that e.g. --vo=name:help will list the sub-options normally, instead of
showing them as deprecation placeholders. Also, the sub-option parser
will verify each option normally, instead of deferring to the global
option parser.)

Another advantage is that once we drop the deprecated options,
converting the remaining things will be easier, because we obviously
don't need to add the compatibility hacks.

Using this mechanism is separate in the next commit to keep the diff
noise down.
2016-09-05 21:26:39 +02:00
wm4 4ab860cddc options: add a mechanism to make sub-option replacement slightly easier
Instead of requiring each VO or AO to manually add members to MPOpts and
the global option table, make it possible to register them automatically
via vo_driver/ao_driver.global_opts members. This avoids modifying
options.c/options.h every time, including having to duplicate the exact
ifdeffery used to enable a driver.
2016-09-05 21:04:17 +02:00
wm4 cd7c7d0841 command: remove vo-cmdline
With the recent vo_opengl changes it doesn't do anything anymore.
I don't think a deprecation period is necessary, because the command
was always marked as experimental.
2016-09-02 21:21:47 +02:00
wm4 849480d0c9 vo_opengl: deprecate sub-options, add them as global options
vo_opengl sub-option were always rather annoying to handle. It seems
better to make them global options instead. This is simpler and easier
to use. The only disadvantage we are aware of is that it's not clear
that many/all of these new global options work with vo_opengl only.

--vo=opengl-hq is also deprecated.

There is extensive compatibility with the old behavior. One exception is
that --vo-defaults will not apply to opengl-hq (though with opengl it
still works). vo-cmdline is also dysfunctional and will be removed in a
following commit.

These changes also affect opengl-cb.

The update mechanism is still rather inefficient: it requires syncing
with the VO after each option change, rather than batching updates.
There's also no granularity (video.c just updates "everything", and if
auto-ICC profiles are enabled, vo_opengl.c will fetch them on each
update).

Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 21:21:47 +02:00
wm4 2c917219cf vo: use new option update mechanism
This is still rather basic.

run_reconfig() and run_control() update the options because it's needed
for panscan (and other video scaling options), and fullscreen, border,
ontop updates. In the old model, these options could be accessed only
while both playback thread and VO threads were locked  (i.e. during
synchronous calls like vo_control()), so this should be sufficient in
order not to miss any updates. In the future, a more fine-grained update
mechanism could be added to handle these updates "exactly".

x11_common.c contains an evil hack, as I see no reasonable way to handle
this properly. The VO thread can't "lock" the main thread, so this is
not simple.
2016-09-02 15:50:54 +02:00
wm4 af103aebd7 player: update Windows playback state asynchronously
Doing this required synchronizing with the VO thread, which could lead
to audio dropouts if the VO was frozen (which can happen in practice if
e.g. an opengl_cb user is not doing what the API demands).

Add a way to send asynchronous VOCTRLs, and use that for the playback
state. In theory, it would be better to make this status update a
several function and to "merge" several queued update, but that would be
slightly more effort/code, and the update is so infrequent that the
merging would never happen anyway.

The change to vo_destroy() is to make sure all queued asynchronous
reuqests are finished before making the vo_thread exit.

Even though it's only used on MS Windows, it's run on any platform with
any VO, which makes this worse.
2016-08-20 14:46:38 +02:00