[FFmpeg-devel] [PATCH] Fix a bug in ff_thread_report_progress in updating progress[field].

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 8:05 PM, Wan-Teh Chang <wtc-at-google.com at ffmpeg.org>
wrote:

> On Tue, Mar 1, 2016 at 7:44 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> > Hi,
> >
> > On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang <
> wtc-at-google.com at 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