[FFmpeg-devel] [PATCH] What is missing for working AVFMT_FLAG_NONBLOCK?

[Michael Niedermayer]

On Tue, Mar 03, 2009 at 11:16:21PM +0100, Nicolas George wrote:
> Le tridi 13 vent?se, an CCXVII, Michael Niedermayer a ?crit?:
> > thread(){
> >     if((uint8_t)(writer_index - reader_index) < RING_SIZE){
> >         write at buffer[writer_index & (RING_SIZE-1)];
> >         writer_index++;
> >     }
> > }
> > 
> > read_packet(){
> >     if(writer_index == reader_index)
> >         return AVERROR(EAGAIN);
> > 
> >     take packet from buffer[reader_index & (RING_SIZE-1)];
> >     buffer[reader_index & (RING_SIZE-1)]= av_new_packet();
> >     reader_index++;
> > }
> 
> That is mostly the same thing that I suggested, apart from two points.
> 
> First, you treat packets as a raw stream of bytes: if thread() runs twice
> before the next time read_packet() is scheduled, it returns only a single
> packet with all the data. I am not sure this is a correct behaviour in all
> cases. But this is very secondary.

well you must misundestand it because this is not what the jack wraper does


> 
> The major point is that I think you are missing one of the point of using
> threads. With this code, you turn in a portable way any blocking source into
> a non-blocking one, even if the underlying devices or libraries do not allow
> it.
> 
> But that is not all: using threads correctly also address the problem of the
> polling / busy-waiting in the main loop.
> 
> The principle is to have a single pthread_cond_t (or any equivalent
> synchronization primitive) for all the sources guarding the condition "there
> is something to read on at least one source". Whenever a thread gets a
> packet from its source, it signals that condition; the main loop, on the
> other side, spends most of its time blocked waiting for the condition. That
> way, the main loop wakes up exactly when there is data to process.

i surely agree but like select() this is unflexible it requires 
pthread_cond_t to be used by all demuxers that can run out of data.
if it can be implemented in a way that this is optional and clean then
it would be an option of course, but it would have to work together
with demuxers that require to be polled regularly.

also it seems to me you overshoot the goal here, threads for sources
that block or have too small buffers are needed, pthread_cond_t 
is not needed it is nice if it can be used cleanly and works reliably
on all platforms we support, ...


> 
> As a side note, assuming that all the source have the same time reference,
> it may be more efficient and/or elegant to have a single thread-to-main
> packet queue, maybe sorted in PTS order instead of FIFO.

lack of volunteers for bikeshed rewrites ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090304/cf5ad21c/attachment.pgp>