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

[Benoit Fouet]

Ramiro Polla wrote:
> Hi,
>
> Benoit Fouet wrote:
>   
>> Hi,
>>
>> here is a patch to $subj
>>
>> what i'm trying to do is having v4l2 working
>>
>> this raises a question to me: how can we wait for the driver to give us
>> a frame. I think we should wait somewhere, depending on the framerate we
>> want.
>>   
>>     
>
> To try and finish frame rate emulation [1], I've analyzed all grab 
> devices except bktr and audio_beos.
> v4l, v4l2, dv1394, vfw32, oss will block themselves until there's a 
> valid frame.
> vfw32 has some issues on Windows 98 (as in returning invalid frame if 
> called too frequently).
> There really is no need for frame rate emulation in those devices unless 
> you want to drop frames, so it'd be best to just remove their frame rate 
> emulation code.
>
> x11grab can give a valid frame at any time, so it should require rate 
> emulation, but IMHO it should be done in the user app, not the demuxer.
> gdi32 gives invalid frames if called too frequently, so it must use rate 
> emulation.
>
> The best thing IMO is to make realtime grabbing in separate threads. It 
> requires many changes in ffmpeg though. It's been suggested to make 
> libavgrab [2], and I'm working on this too.
>
>   

ok

> Anyways, this is a hasty report. I have many exams this week, so I'll 
> only look further on the weekend. I really should go back to studying now =)
>
> [...]
>   

indeed :)

>> -        if (av_read_frame(is, &pkt) < 0) {
>> +        if ((ret=av_read_frame(is, &pkt)) < 0) {
>> +            if (ret != AVERROR(EAGAIN))
>>   
>>     
>
> Won't this busy-wait?
>
>   

yes, but the purpose of this thread was mainly to understand what was
wrong :)

-- 
Ben
Purple Labs S.A.
www.purplelabs.com