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

[Michael Niedermayer]

On Mon, Jan 23, 2012 at 08:58:05AM +0100, Reimar Döffinger wrote:
> 
> 
> 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.

Iam not sure how to detect that the progress was increased from the
max the decoder would normally set because the code doesnt know the
max.
And it seems overkill to add code for exporting the max just for the
warning IMHO
but ideas are welcome ..


> 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.

I hope we dont have any decoders that behave that way. But yes one
could write a decoder behaving like this.

especially field interlaced formats should be tested with this if
someone has time ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120123/50478fb7/attachment.asc>