[FFmpeg-devel] [PATCH] pthreads: Generic progress lubrication support.

[Reimar Döffinger]

On 23 Jan 2012, at 07:08, Michael Niedermayer <michaelni at gmx.at> wrote:

> Fixes bug118, bug120 and bug125 at least
> 
> Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> ---
> libavcodec/pthread.c |    7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/libavcodec/pthread.c b/libavcodec/pthread.c
> index 070dbff..6ae763d 100644
> --- a/libavcodec/pthread.c
> +++ b/libavcodec/pthread.c
> @@ -366,6 +366,7 @@ static attribute_align_arg void *frame_worker_thread(void *arg)
>     AVCodec *codec = avctx->codec;
> 
>     while (1) {
> +        int i;
>         if (p->state == STATE_INPUT_READY && !fctx->die) {
>             pthread_mutex_lock(&p->mutex);
>             while (p->state == STATE_INPUT_READY && !fctx->die)
> @@ -388,6 +389,12 @@ static attribute_align_arg void *frame_worker_thread(void *arg)
>         p->state = STATE_INPUT_READY;
> 
>         pthread_mutex_lock(&p->progress_mutex);
> +        for (i = 0; i < MAX_BUFFERS; i++)
> +            if (p->progress_used[i]) {
> +                p->progress[i][0] = INT_MAX;
> +                p->progress[i][1] = INT_MAX;
> +            }
> +        pthread_cond_broadcast(&p->progress_cond);

I think this should add a loud warning when encountering these values since IMO it indicates a bug in the decoder.
Also isn't it possible that progress just hasn't been used by the "earlier" thread by the time the "next" thread waits for it?
Then all you would do is change the behaviour to even harder to debug random visual corruption.