![]() Interesting detail is, that the stack trace of the non-frameskip version shows some system activity I don't really understand - beginning with ntoskrnl.exe!KiPageFault+0x373. Now a heavy workload on many cores would of course cause a minor slowdown per core due to reduced turbo - let's say 10 or 20%. The conversion of a single frame has become ten times slower than before (average roughly ~350ms). The image of the non-frameskip version shows why: Thus, as multiple threads are used, it also should be quick enough for 60FPS, but it isn't! You see that the conversion is pretty quick (average roughly ~35ms) Here's an image of the frameskip version: Comparing the two versions in Concurrency Visualizer, I found a strange issue I don't know the reason of. So as a first countermeasure I skipped the conversion of some frames and got a stable frame rate of ~40 that way. Decoding still is fast enough, but when it comes to YUV/BGRA conversion it is simply not fast enough, even though it's done in 16 threads (one thread per frame on a 16/32 core machine). But with my maximum target - 4K 60FPS, it fails. With common videos (up to 4K 30FPS), it works pretty good. I am writing a video player using ffmpeg (Windows only, Visual Studio 2015, 64 bit compile).
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |