On Sat, 22 Oct 2016 22:06:22 -0400 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> Hi, > > On Sat, Oct 22, 2016 at 3:02 PM, Michael Niedermayer <mich...@niedermayer.cc > > wrote: > > > This decreases the number of FPU state violations in fate on x86-64 from > > 309 to 79 > > > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/pthread_frame.c | 3 +++ > > libavcodec/utils.c | 2 ++ > > 2 files changed, 5 insertions(+) > > > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c > > index 7ef5e9f..b6c6027 100644 > > --- a/libavcodec/pthread_frame.c > > +++ b/libavcodec/pthread_frame.c > > @@ -473,6 +473,9 @@ void ff_thread_report_progress(ThreadFrame *f, int n, > > int field) > > PerThreadContext *p; > > volatile int *progress = f->progress ? (int*)f->progress->data : NULL; > > > > + if (n >= INT_MAX) > > + emms_c(); > > > I don't like how INT_MAX is becoming more and more like a magic number. > This should probably be a new function that is called upon frame (or field) > decoding completion (or abort), where part of what it does is to set > progress to INT_MAX. Indeed, this looks very strange. Also the ">" in the ">=" is redundant, why isn't it "=="? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
