[FFmpeg-devel] [PATCH] handle EAGAIN case in ffmpeg.c
Wed Sep 12 17:03:09 CEST 2007
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... ;-)
More information about the ffmpeg-devel