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

[Nicolas George]

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.

> 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.

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/e306527d/attachment.pgp>