[FFmpeg-cvslog] r26318 - trunk/libavformat/aviobuf.c

[Nicolas George]

Le tridi 23 niv?se, an CCXIX, Martin Storsj? a ?crit?:
> Yes, those cases are quite extreme ones. Shorts sleeps still are better 
> than busylooping at least.

Of course.

> It wasn't particularly valid, only an easy way out.
> 
> While urlprotocols currently are designed to be blocking, the rtsp code 
> tries to receive from many such ones in parallel. Since it can't just try 
> to do a blocking read from one, it initially does a select() on the fd's 
> from all of them, and once a packet is available, it does a blocking read 
> on that one. If we for some reason within the urlprotocol would choose to 
> throw away the packet (e.g. coming from the wrong address/port), the 
> protocol would return EAGAIN to allow the higher level code go back to 
> select() again.
> 
> I fixed that case by doing connect() on the UDP fd instead, so the kernel 
> won't deliver such unwanted packets at all, and we wouldn't run into this 
> situation at all. The really proper solution would be to use real, 
> nonblocking IO in this setup.

I see, the situation looks like quite a pileup of hacks over hacks.

There is something to be done here. I'll think about it some more.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20110112/61b90d37/attachment.pgp>