Hack treating PVIDEO `size_in` of `0xFFFFFFFF` as end of overlay does not match HW behavior

Bug Description

In #1178 I added a hack that treats size_in values of 0xFFFFFFFF as an indication that the PVIDEO overlay should be torn down. This does not match HW behavior (see test) but was necessary as at least one game (https://xemu.app/titles/57450001/#Ultimate-Beach-Soccer) does not use the stop bit in the NV_PVIDEO_STOP register to tear down the video overlay.

Expected Behavior

On HW, setting size_in to 0xFFFFFFFF is more or less equivalent to asking for the input size to be calculated from the output size using the ds_dx and dt_dy settings.

xemu Version

All versions since v0.7.61 have this hack.

System Information

N/A this is not system dependent.

Additional Context

I started examining the logs for Ultimate Beach Soccer more closely and I do see one thing that strikes me as unusual around the time that I think the video ends (UBS seems to switch from the video to a static screen that contains the same data as the last frame of video so it's not exactly clear when the video stops from observing output alone).

When the Xbox first boots, and when it changes over from the X logo screen to the actual title, there are a series of writes to the PMC register group at address 0x200:

nv2a_reg_write PMC addr 0x200 size 4 val 0x0
nv2a_reg_write PMC addr 0x200 size 4 val 0x0
nv2a_reg_write PMC addr 0x200 size 4 val 0xffffffff
nv2a_reg_write PMC addr 0x200 size 4 val 0xffffffff
nv2a_reg_write PMC addr 0x200 size 4 val 0x0
nv2a_reg_write PMC addr 0x200 size 4 val 0x1000

In this game, I also see this same chain of writes when the video ends. I'm suspicious that this may be reinitializing things in a way that causes the PVIDEO overlay to be torn down.

xemu-project / xemu