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.
This commit is contained in:
sjambekar 2021-08-09 12:01:43 +05:30 committed by Philip Langdale
parent acf7ef86d6
commit b692c6599a
1 changed files with 11 additions and 1 deletions

View File

@ -478,7 +478,17 @@ static int reconfig(struct vo *vo, struct mp_image_params *params)
VdpStatus vdp_st;
if (!check_preemption(vo))
return -1;
{
/*
* When prempted, leave the reconfig() immediately
* without reconfiguring the vo_window and without
* initializing the vdpau objects. When recovered
* from preemption, if there is a difference between
* the VD thread parameters and the VO thread parameters
* the reconfig() is triggered again.
*/
return 0;
}
VdpChromaType chroma_type = VDP_CHROMA_TYPE_420;
mp_vdpau_get_format(params->imgfmt, &chroma_type, NULL);