On 3/31/2013 7:42 AM, Александр Рухлов wrote:
timeBeginPeriod() + timeGetTime() +...+ Sleep() + timeEndPeriod()
http://msdn.microsoft.com/ru-RU/library/windows/desktop/dd757624%28v=vs.85%29.aspx
Note that you should not set timeBeginPeriod frequently, one per process
is best if you can manage it. In the past I've seen PCs+BIOS lose a
little bit of time off of their real time clock when calling
timeBeginPeriod() so they get way out of sync if you call then frequently.
Here are some still relevant links to timing issues in Windows:
http://blogs.msdn.com/b/mediasdkstuff/archive/2009/07/02/why-are-the-multimedia-timer-apis-timesetevent-not-as-accurate-as-i-would-expect.aspx
http://www.gamedev.net/page/resources/_/technical/game-programming/timing-pitfalls-and-solutions-r2086
On top of the timing function calls, you may need to raise the priority
of the thread that calls Sleep() to something time critical. It was
pretty much a necessity with Windows XP and earlier. If you didn't,
there is no guarantee that the thread that called Sleep() would regain
CPU immediately after the sleep period was finished. Once a
non-time-critical thread yields the CPU, the OS has no special reason to
reschedule it ahead of any other thread. When the Sleep period finished,
the sleeping thread has to get back in line with all the other threads.
The rules are different for time critical threads, the can get the CPU
back ahead of the rest of the pack. The Windows thread scheduler saw
some changes for Vista and later, I'm not as familiar with the behavior
there, so I don't know if Microsoft improved that situation.
--Johno
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
