More accurate timing in avi playing

[M-HT]

• Have you checked to ensure there aren't other open Pull Requests for the same change?

• Have you added an explanation of what your changes do and why you'd like us to include them?
  Change timing in avi playing to be more accurate. Especially when SDL_Delay has a delay granularity of 10 ms.

• How many dependencies was introduced in this PR? Did the minimal requirement changed, for which platform?

• Have you written new tests for your changes?

• Have you successfully run it with your changes locally?

• Have you tested on following platforms?

  • Win32
  • UWP
  • Linux
  • Android
  • macOS
  • iOS

[palxex]

Closing due to current code work well; and no enhancement saw on low-end platform.

[M-HT]

According to a note in SDL documentation (at least for SDL1) the function SDL_Delay has a delay granularity of at least 10 ms. Which means that on some platforms if you call SDL_Delay(1), it will wait 10ms and not 1ms.
On such platforms, there's a noticable delay between audio and video (mostly when playing 3.avi) - this change fixes it.
You can simulate this by changing SDL_Delay(1); to SDL_Delay(10); in function UTIL_Delay in file util.c.
Of course if you don't want to accept this change, it's up to you - like you said it's not a problem on current platforms, because the granularity of SDL_Delay is lower than 10 ms.

[palxex]

One tester on psp SDL1 said that he see no noticeable different before/after this patch, and also myself on wii. Could you please provide the detail platform that require this patch to work? Then we can reconsider it.

[M-HT]

I encountered the problem on GP2X.
The change is in my fork of sdlpal, where I also have optimizations specific to this platform - so if you don't accept the change, it's not a problem for me.

[palxex]

Another question: this PR not only include the delay 1->0 patch, but also changes waiting time calculating by introducing dwFrameNumber variable, which ++ in every frame. Will it makes that on low-end device( slower than gp2x), frame cannot jump over and makes video/audio mismatch?
Not original avi code author, maybe the question is not sanity, but I need to ensure the accepted code being general for all platforms. Thanks for understanding.

[M-HT]

The code should be ok, unless you used it with a REALLY long playing video file. And in that case, I think that nobody would care about audio/video synchronization.

[palxex]

nobody would care about audio/video synchronization.

This is not a good reason for code change. If the only needed patch is 1->0, please file a new PR that only contains it.

[M-HT]

Just changing 1->0 doesn't fix the issue.
When I say REALLY long playing video file I mean more than one hour long. if that's not enough, you can use uint64_t instead of uint32_t.
I'll also point out that the current code will also desynchronize audio/video with such long files (because rendering doesn't take zero time).
But, like I said before, it's not a problem for me if you don't accept the change.

[palxex]

Video/audio desynchronize was just my assumption that the PR wants to address( which in fact already appears on PSP and Wii, on all avi longer than about 10 sec). Forget it.
@CecilHarvey please review the PR when you have time. I don't have necessary skill on it.

[palxex]

Seems SDL_Delay() always passes the latency parameter to the underlying API, which may introduce additional waiting time, especially on homebrew toolchains. How about directly eliminate the delay call instead of delay(0) in such situation( dwCurrentTime >= dwNextFrameTime )?

[M-HT]

The avi player uses UTIL_Delay, which then calls SDL_Delay. I could eliminate calling UTIL_Delay(0), although the difference would be negligible. However, UTIL_Delay also processes events, which is useful (maybe necessary) even with zero delay. So instead of calling UTIL_Delay(0) I would have to call PAL_ProcessEvent() to process events. I think it's better as it is, but if you want, I'll do the change.

[palxex]

You are correct, please handle it this way. Thank you very much for the reminder.