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

[Michael Niedermayer]

On Mon, Jan 23, 2012 at 04:00:11PM +0100, Michael Niedermayer wrote:
> 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 ?

as this fixes some security issues (deadlocks) and id like to have
this fix in the release and it should receive some testing before
applied

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- 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/d575a3b3/attachment.asc>