> -----Ursprüngliche Nachricht----- > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag > von wm4 > Gesendet: Donnerstag, 5. November 2015 13:43 > An: ffmpeg-devel@ffmpeg.org > Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter - second > try > > On Thu, 5 Nov 2015 12:49:50 +0100 > "Sven Dueking" <s...@nablet.com> wrote: > > > > > + } else if (ret == MFX_WRN_DEVICE_BUSY) { > > > > + av_usleep(500); > > > > > > What. Use proper event-based waiting. > > > > That´s the same behavior as we have in the qsv encoder and decoder. > > And as far as I know this is how Intel recommends to handle this. > > That's just ridiculous. Can you send some hate-mail to Intel and tell > them what a bad idea this is? Half a millisecond is an eternity for a > CPU. What if the device is blocked only for 10 microseconds? Then it > will waste time by spending 490 microseconds idly. > > Software engineers recognized that polling is a bad idea half a century > ago. Why can't Intel do this right? > > Or does MFX have some sort of async mode that works without polling? Intel doesn´t recommend 500ms, it´s 1 ms according to the sample. But, the FFMpeg decoder and encoder were changed to 500ms some time ago : https://github.com/FFmpeg/FFmpeg/commit/947c2aa4567782be64411a953a5b294976463e19
I agree with the comments from Ivan, this doesn´t happen in a normal scenario. And I never get this state at all in all my tests. But I can change it back to 1ms, not sure if this makes sense. Btw, thanks again for your review. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
