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

Michael Niedermayer michaelni
Wed Mar 4 00:16:20 CET 2009

On Tue, Mar 03, 2009 at 11:03:13PM +0100, Luca Abeni wrote:
> Hi Michael,
> Michael Niedermayer wrote:
> [...]
> >> I was not suggesting usleep(0) (which, of course, is not better than 
> >> sched_yield()): I was just wondering if we might be able to predict when 
> >> the next frame will be available, and to usleep() for the right amount 
> >> of time... Anyway, this can be committed in a second time (if worth), 
> >> after your patch is committed.
> > 
> > what my oppinion is, is that its not the user applications job to guess
> > this, thats also why i considerd sched_yield() more correct than
> > usleep(something).
> Well, I am not sure if I agree here (it would be nice to have a syscall 
> that behaves as you describe, but I do not think sched_yield() does 
> this) but the discussion risks to go off-topic.
> Just one last proposal: instead of "usleep(10000)", with 10000 being an 
> arbitrary constant, we probably can use a smarter constant. If all the 
> streams have frames with a fixed duration (and I think this assumption 
> is reasonable for live inputs) and t_min is the minimum frame duration, 
> we can do usleep(t_min / 2).
> This should ensure that we do not have overruns on any input, and should 
> avoid too many useless polls.
> Just an idea... If you think this is overkilling, or does not make 
> sense, just ignore it.

the correct way to do it (ohh well the kernel should do this ...)
is to

(static) int t=1000;

if(all demuxers returned EAGAIN){
        t+= t>>3;
        t-= t>>3;
constants might have to be finetuned, maybe some divide by the number of
demuxers is needed in there ...

patch welcome, iam too disgusted by POSIX ATM

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20090304/17afc344/attachment.pgp>

More information about the ffmpeg-devel mailing list