Hi, On Tue, Mar 1, 2016 at 8:05 PM, Wan-Teh Chang <wtc-at-google....@ffmpeg.org> wrote:
> On Tue, Mar 1, 2016 at 7:44 AM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > Hi, > > > > On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang < > wtc-at-google....@ffmpeg.org> > > wrote: > > > >> By the way, I'm also wondering why ff_thread_report_progress is > >> sometimes called with progress[field] >= n? I saw it happen when I ran > >> make fate-h264, but did not investigate it. > > > > I don't know, which sample (test name) specifically? > > The attached ff_thread_report_progress.txt file is a patch for ffmpeg > that counts the fast and slow code paths in ff_thread_report_progress > and ff_thread_await_progress, and prints the counters at the end. > > I ran "make fate-h264 THREADS=4". Here are the results, which show > that the fast code path (progress[field] >= n) was taken in > ff_thread_report_progress. I think I mis-read the question. We don't care if progress[field] == n, that's a logical thing that can happen in many cases. We care only if progress[field] > n, which would be an actual race. It's only logical that the fast code path is taken if progress[field] == n, and this can happen for all sort of reasons, none of which are pathological or worth spending time on. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
