summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-07-12 03:30:52 +0200
committerwm4 <wm4@nowhere>2019-09-19 20:37:05 +0200
commite265c07547a4db87dde0dcdfdb25ef2e33659d38 (patch)
tree27ce9b9654fa9ca068d0d00858ffdaa7ebdb59fc
parent82f2613adee9d18ad9baba6da42ba94c5dbbccbb (diff)
downloadmpv-e265c07547a4db87dde0dcdfdb25ef2e33659d38.tar.bz2
mpv-e265c07547a4db87dde0dcdfdb25ef2e33659d38.tar.xz
vo: fix missed option updates under rare circumstances
Dear diary, today I fixed a shitty bug that was all my fault because I made a horrible mess. (Except it was a horrible mess before I even touched this shit, but let's not blame others.) Sometimes, updates to VO option that control video sizing (like panscan) didn't update the screen correctly. They were delayed until the next option change or so. It turns out that if the option update happens at the "same" time as a VOCTRL, update_opts() doesn't actually notify the vo_driver of the change. This in turn happened because run_control() called m_config_cache_update(). The latter function returns true if the options changed since the last call, and update_opts() also calls it (on the same config cache) for the same purpose. The update_opts() call, which is triggered by a third mechanism, comes later, but the cache update call will return false (as it should). Basically, given the config API, you can't act differently on multiple update calls and expect it to work. The skipped handling in update_opts() meant that the notification required to apply the changed option wasn't run. Fix this by simply calling update_opts() directly instead. Now there's only 1 m_config_cache_update() call on this specific instance. Fix the call in run_reconfig() too, so the previous sentence isn't a lie (but it probably doesn't make a difference in practice due to certain details). I'm not sure how I even ran into this sort-of race condition. The VOCTRL that messed up the option update was VOCTRL_UPDATE_PLAYBACK_STATE, which happens semi-regularly. Why this config cache shit and all the other shit? Rediscovering this crap wasn't pleasant. It's a bunch of hacks that became necessary when the ancient MPlayer architecture made it hard to move the VO to a separate thread. All the VO code typically accesses vo->opts (whose fields all used to be global variables in MPlayer). The frontend changes these on user input. Putting locking around all the options would be a nightmare, and keeping a copy of the options in the thread was much simpler. You need a way to propagate option changes, notify the thread, and update the local copy too. And the result of these thoughts was the config cache mechanism. In this specific case, the relevant cache update call in update_opts() triggers a VOCTRL_SET_PANSCAN to the VO driver, which isn't related to its former function anymore. Instead, it causes the VO driver to update the video sizing/placing options, which the generic VO code can't do. (Mostly because the VO driver includes the windowing stuff and is responsible for resizing etc. itself.) VOCTRLs sent by the frontend are even worse. MPlayer had no real runtime option change mechanism. Some options were vaguely duplicated by properties, so you could effectively change those options at runtime. Each of these options had its own VOCTRL, which still exist today, e.g. VOCTRL_FULLSCREEN, or VOCTRL_ONTOP. I tried to make all options runtime changeable, and to unify properties with options. But I couldn't be bothered with updating all VO drivers to listen to option changes directly, because that would be pretty tedious. So the property code is still all there and sends the old VOCTRLs. But of course you need to sync up the options, which is why the run_control() code did that. (Unrelated: VO_EVENT_FULLSCREEN_STATE is the worst shithack of them all. Currently, only the frontend can actually write to options (for awful reasons), so if the fullscreen state changes due to outside interaction, the VO driver can't update the corresponding option fields. So the VO notifies the frontend with said VO_EVENT_, and the frontend then sends VOCTRL_GET_FULLSCREEN, and updates the global copy of the option with the value returned by that. I still like to think the situation is not that bad considering the monstrous effort of converting single-threaded code that had hundreds of options in global variables to multi-threaded code with no global variables at all.)
-rw-r--r--video/out/vo.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/video/out/vo.c b/video/out/vo.c
index 0d4ed140ae..a094885112 100644
--- a/video/out/vo.c
+++ b/video/out/vo.c
@@ -580,7 +580,7 @@ static void run_reconfig(void *p)
MP_VERBOSE(vo, "reconfig to %s\n", mp_image_params_to_str(params));
- m_config_cache_update(vo->opts_cache);
+ update_opts(vo);
mp_image_params_get_dsize(params, &vo->dwidth, &vo->dheight);
@@ -634,7 +634,7 @@ static void run_control(void *p)
struct vo *vo = pp[0];
int request = (intptr_t)pp[1];
void *data = pp[2];
- m_config_cache_update(vo->opts_cache);
+ update_opts(vo);
int ret = vo->driver->control(vo, request, data);
if (pp[3])
*(int *)pp[3] = ret;