[FFmpeg-devel] [PATCH] Added QSV based VPP filter - second try

[Sven Dueking]

> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] Im Auftrag
> von wm4
> Gesendet: Donnerstag, 5. November 2015 13:43
> An: ffmpeg-devel at 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" <sven at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel