[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).

[Nicolas George]

Le quintidi 15 vent?se, an CCXVIII, Michael Niedermayer a ?crit?:
> i dont understand you, libavdevice/jack_audio.c for example alraedy uses
> a seperate thread (its the way how jack is supposed to be used it seems)
> and without any AVThreadInfo

I was thinking of a generic solution: code in the library that can run any
device in a separate thread without requiring any change at all in the
various devices.

Jack can run in its own thread because is has specific code for it. It does
not require the thread_info field because it has it in the priv_data->client
field (the structure is opaque, but looking into it confirms that there are
thread-related fields).

What I have in mind is this:

Currently, av_read_packet does this:

	ret= s->iformat->read_packet(s, pkt);

what it could do instead is:

	if (s->thread_info) {
	    if (!s->thread_info->running)
		start_thread(s);
	    ret = queue_get(s->thread_info->packet_queue);
	} else {
	    ret= s->iformat->read_packet(s, pkt);
	}

Thus, running a device in its own thread requires only filling the
thread_info field.

 From the application's point of view, this device is still blocking, but
now, it is also insensible to polling irregularities: if the application is
blocked in another device, or spends a little too much time encoding a
particularly complex frame, it will not drop any data, just queue it.

(Some care must be taken not to clog the memory with queued data, tough, but
that is a detail.)

Regards,

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