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

[Nicolas George]

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.

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

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090303/abb6a7e5/attachment.pgp>