[FFmpeg-devel] [PATCH] allow rtsp reading to be non blocking

[elupus]

"Luca Abeni" <lucabe72 at email.it> wrote in message 
news:1192270210.2240.10.camel at localhost.localdomain...
> Hi all,
>
> On Fri, 2007-10-12 at 00:14 +0200, Michael Niedermayer wrote:
>> On Sat, Oct 06, 2007 at 01:33:50AM +0200, elupus wrote:
>> > Hi,
>> >
>> > rtsp_eintr.txt: is a resend of a previous patch (which I first thought
>> > didn't get applied, then that it did, then figured out it didn't).
>> > rtsp_eagain.txt: A patch to make rtsp reading non blocking. It relies 
>> > on
>> > the previous patch to work.
>>
>> fearless rtsp maintainer luca, ping!
>> is it good/bad/applied/reject/... ?
> I think the email was for Luca B, but I had a look at the patches
> anyway :)
>
> I think the first one (rtsp_eintr.txt) looks good.
>
> The second one (rtsp_eagain.txt) is good in theory, but I think it is
> not complete: as far as I know, the rtp input sockets are not set as
> non-blocking, so the block of code added by the patch will be used only
> if the 100ms timeout fires (so, the read operation is not really "non
> blocking").
> I think that a call to ff_socket_nonblock() should be added to then open
> function (maybe to udp_open()?) if AVFMT_FLAG_NONBLOCK is set.
>
> When is this patch needed? How has it been tested?
>
>
> That said, I am not (and I do not want to be) the rtsp maintainer...
>
>
> Luca


Not really needed. As one can accomplish the same with the timeout's sorta. 
But it's a cleaner way to get away from ffmpeg blocking forever on stalled 
rtsp/rtp udp streams. I've tested it successfully in our player in xbmc.
I kinda assumed the sockets where set to be nonblocking alread due to the 
way the select was done on them, and it has worked reasonably well. Also 
aren't a socket read required to be nonblocking if select has returned that 
they are readable? Maybe not, didn't check the specs.

/Joakim