diff options
author | sjambekar <88648501+sjambekar@users.noreply.github.com> | 2021-08-09 12:01:43 +0530 |
---|---|---|
committer | Philip Langdale <github.philipl@overt.org> | 2021-08-12 11:14:37 -0700 |
commit | b692c6599a6e3a7331f588a5a1457788ef9b4e75 (patch) | |
tree | 4e680e136d201af4bb204435a90390240245bd78 /audio/out/ao_coreaudio_chmap.h | |
parent | acf7ef86d68baf7224e25f4c2ce42b4cd4c35996 (diff) | |
download | mpv-b692c6599a6e3a7331f588a5a1457788ef9b4e75.tar.bz2 mpv-b692c6599a6e3a7331f588a5a1457788ef9b4e75.tar.xz |
vo_vdpau: Don't treat preemption as an error when reconfiguring
When the VT switch out is triggered, the decode thread (VD) falls back
to sw decoding. However, on the VO thread, which is responsible for
handling display preemption and presentation, vo_vdpau.c:reconfig() is
called. The reconfig() function returned -1 when the check_preemption()
returned 0. The vo_reconfig2() (which calls reconfig()) returned -1 in
turn which entered into an error handling path. This led to a series of
functions calls that ultimately set the in_terminate flag to TRUE.
This led the vo_thread to exit which ultimately led to the
MPV application exit.
The fix is to return 0 instead of -1 after the check_preemption() in
the vo_vpdau.c:reconfig(). Returning 0 instead of -1 is not fatal and
does not have any side effects. This is confirmed by testing the VT
switching behaviour. And as far as the frames that are going to the
display are concerned, they are now dropped. Since the display is
preempted, it is okay to drop the frames and continue.
Diffstat (limited to 'audio/out/ao_coreaudio_chmap.h')
0 files changed, 0 insertions, 0 deletions