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

[Michael Niedermayer]

On Tue, Mar 03, 2009 at 09:18:33PM +0100, Nicolas George wrote:
> Le tridi 13 vent?se, an CCXVII, Michael Niedermayer a ?crit?:
> > yes, though its a per device/API question if a thread is needed or if the
> > device/API has buffers that are large enough.
> > 
> > the JACK patch already uses a seperate thread but possibly should use a
> > larger buffer ...
> > 
> > adding a seperate thread to anything that has less than 500ms worth of
> > buffers is welcome. I also suspect&suspected in the past that lack of this
> > is the cause of many issues with capturing with ffmpeg.
> 
> Another solution could be to add generic code that can create a thread for
> any device, and let the user decide for each input if he wants to put it in
> a separate thread.

hmm


> 
> I am not sure I understand what buffer problem you are thinking about. The
> code as I imagine it would be something like that:
> 
> For each thread:
> 
> 	while (1) {
> 	    packet = calloc(...);
> 	    av_read_frame(device, packet);
> 	    message_queue_add(device, packet);
> 	}
> 
> and the main loop:
> 
> 	while (1) {
> 	    message_queue_get(&device, &packet);
> 	    /* do something with the packet */
> 	}
> 
> Then no packets would accumulate anywhere.
> 
> > if by message que you mean the stuff from posix then i must say i would
> > prefer the kind of fifo/ringbuffer i suggested for jack unless i missed some
> > issues with it.
> 
> You mean the SysV msgget/msgctl stuff? I was definitely not thinking of
> them. I just meant the combination of a queue (FIFO) data structure with a
> mutex and a condition (using the pthread vocabulary; any equivalent API
> would do).

I meant this:
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++;
}

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20090303/ea50c6b0/attachment.pgp>