-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More accurate timing in avi playing #190
base: master
Are you sure you want to change the base?
Conversation
Closing due to current code work well; and no enhancement saw on low-end platform. |
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. |
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. |
I encountered the problem on GP2X. |
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? |
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. |
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. |
Just changing 1->0 doesn't fix the issue. |
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. |
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 )? |
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. |
You are correct, please handle it this way. Thank you very much for the reminder. |
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?