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

[Martin Storsjö]

On Wed, 12 Jan 2011, Nicolas George wrote:

> Le tridi 23 niv?se, an CCXIX, Martin Storsj? a ?crit?:
> > In this case, it does fall back to usleeping a bit between retries after a 
> > few fast retries
> 
> On embedded devices, these fast then slow retries can noticeably worsen the
> power consumption.
> 
> I have a friend who was recently working on a very-low-consumption very-idle
> embedded device and told me that even waking up every few seconds visibly
> lowered the life expectancy of the battery. Arguably, devices doing
> audio-video related stuff are not that extreme, but still.

Yes, those cases are quite extreme ones. Shorts sleeps still are better 
than busylooping at least.

> > The issue is that most users of ByteIOContext consider it a nonblocking 
> > input, and therefore benefit from handling all of that internally, which 
> > is why this patch was made in the first case.
> 
> Agreed.
> 
> > Another way ahead would be, as user of ByteIOContext, indicate whether it 
> > wants to use it in nonblocking mode or not.
> 
> I knew that AVFormatContext has the AVFMT_FLAG_NONBLOCK flag. I na?vely
> assumed that the lower-level functions on which it relies would necessarily
> have the corresponding flag or API. It seems that I was wrong: apparently,
> AVFMT_FLAG_NONBLOCK is handled in a very chaotic way: a few devices handle
> it, most format do not care at all, even network-related ones; ffmpeg sets
> it on input formats and handles it in a very strange way (and IMHO a wrong
> way too), and sets it on output formats but do not handle it.
> 
> There is definitely something that needs fixing in depth there.
> 
> > The use case I had in mind initially would have made some url protocols 
> > return EAGAIN even while in normal blocking mode
> 
> My immediate reaction would be to say that it is wrong, but there may be
> valid reason that I do not see.

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.

// Martin