[FFmpeg-devel] [PATCH] handle EAGAIN case in ffmpeg.c

[Luca Abeni]

Hi,

Ramiro Ribeiro Polla wrote:
[...]
>> Ramiro Polla wrote:
>> [...]
>>   
>>> The best thing IMO is to make realtime grabbing in separate threads.
>>>     
>> This can be true for some grabbing interfaces. But if you use v4l2 a 
>> single thread can do the work (as a matter of fact, ffmpeg is perfectly 
>> able to grab v4l2 video and oss audio, with perfect A/V synch). The 
>> trick is that v4l2 provides a timestamp for each captured frame (so, if 
>> ffmpeg blocks while reading another input - for example the audio - and 
>> reads a frame "too late", it can still know when the frame was sampled, 
>> and can synchronize it with the audio).
> 
> But does that block ffmpeg too?
Yes, when reading video ffmpeg blocks until the next video frame is 
ready, and when reading audio it blocks until some audio data is ready.
But if you can associate exact timestamps to video frames (as v4l2 
allows you to do), blocking for a reasonable time is not a problem from 
the practical point of view.

> What I'm going for (like Michael said)
> is that no input should block ffmpeg, so that it can keep 
> demuxing/decoding/encoding/muxing other stuff while it's waiting.
This is surely more elegant, and I think it is the best solution in some 
situations. But I suspect non-blocking input can create problems in 
other cases. This is why I believe that the availability of the 
AVFMT_FLAG_NONBLOCK flag is the correct solution.

Anyway, the point of my reply was not about blocking vs non-blocking 
input... I just wanted to say that if the grabbing API is designed well 
enough (and v4l2 is ok from this point of view) it is possible to grab 
audio and video in the same thread with good A/V synch and without any 
problem (as ffmpeg currently does... ;-)


				Luca