Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-02 Thread Clément Bœsch
On Wed, Dec 02, 2015 at 03:13:33PM +0100, Nicolas George wrote: > Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > > because concurrent read/write accesses on the fifo needs to be locked? > > No, of course not. I was talking about the fifo itself, not the threadmessage API. > > > I

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-02 Thread Nicolas George
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > - there is a large queue of packets, almost filled > - there is one fast sender filling the queue (the demuxer) > - there is a bunch of slow readers reading from the queue (the decoders) > - the sender "receives" a seek event from the

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-02 Thread Clément Bœsch
On Tue, Dec 01, 2015 at 06:49:29PM +0100, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > > Ah. Well then the user can not do it himself since he has no way of > > acquiring the queue lock (AVThreadMessageQueue is opaque) > > Yes, but why does it matter, if

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-02 Thread Nicolas George
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > because concurrent read/write accesses on the fifo needs to be locked? No, of course not. > I don't understand... *I* do not understand what you need, what you want to do with this API. To discard all elements, just read them until

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-01 Thread Nicolas George
Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > Ah. Well then the user can not do it himself since he has no way of > acquiring the queue lock (AVThreadMessageQueue is opaque) Yes, but why does it matter, if the elements are to be discarded anyway. Ah, I think I see a point: this

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-01 Thread Nicolas George
Le decadi 10 frimaire, an CCXXIV, Clement Boesch a écrit : > From: Clément Bœsch > > --- > libavutil/threadmessage.c | 37 ++--- > libavutil/threadmessage.h | 21 ++--- > 2 files changed, 52 insertions(+), 6 deletions(-) >

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-01 Thread Clément Bœsch
On Tue, Dec 01, 2015 at 05:11:06PM +0100, Nicolas George wrote: > Le decadi 10 frimaire, an CCXXIV, Clement Boesch a écrit : > > From: Clément Bœsch > > > > --- > > libavutil/threadmessage.c | 37 ++--- > > libavutil/threadmessage.h | 21

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-01 Thread Nicolas George
Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > Your suggestion is twice smaller. I guess I was not clear enough: I was not asking about merits of this implementations over yours, but about the usefulness of the function for the application compared to reading and discarding each

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-12-01 Thread Clément Bœsch
On Tue, Dec 01, 2015 at 05:34:39PM +0100, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > > Your suggestion is twice smaller. > > I guess I was not clear enough: I was not asking about merits of this > implementations over yours, but about the usefulness of

[FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

2015-11-30 Thread Clément Bœsch
From: Clément Bœsch --- libavutil/threadmessage.c | 37 ++--- libavutil/threadmessage.h | 21 ++--- 2 files changed, 52 insertions(+), 6 deletions(-) diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c index