diff options
author | wm4 <wm4@nowhere> | 2013-10-01 23:35:51 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2013-10-02 00:36:26 +0200 |
commit | ed9295c250ddfb845e48f123343e7b02326e8920 (patch) | |
tree | d0714b2dddb7b04419a9ed516ff1ad6e180c13b2 /version.sh | |
parent | 94d6babb952f5efd76f92bbf38320563bc860e9c (diff) | |
download | mpv-ed9295c250ddfb845e48f123343e7b02326e8920.tar.bz2 mpv-ed9295c250ddfb845e48f123343e7b02326e8920.tar.xz |
video/out: always support redrawing VO window at any point
Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME,
which means the VO wouldn't redraw OSD and window contents, and the
player would appear frozen to the user. This was a bit stupid, and makes
dealing with some corner cases much harder (think of --keep-open, which
was hard to implement, because the VO gets into this state if there are
no new video frames after a seek reset).
Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME.
There are two aspects of this: First, behavior after a (successful)
vo_reconfig() call, but before any video frame has been displayed.
Second, behavior after a vo_seek_reset().
For the first issue, we define that sending VOCTRL_REDRAW_FRAME after
vo_reconfig() should clear the window with black. This requires minor
changes to some VOs. In particular vaapi makes this horribly
complicated, because OSD rendering is bound to a video surface. We
create a black dummy surface for this purpose.
The second issue is much simpler and works already with most VOs: they
simply redraw whatever has been uploaded previously. The exception is
vdpau, which has a complicated mechanism to track and filter video
frames. The state associated with this mechanism is completely cleared
with vo_seek_reset(), so implementing this to work as expected is not
trivial. For now, we just clear the window with black.
Diffstat (limited to 'version.sh')
0 files changed, 0 insertions, 0 deletions