[FFmpeg-devel] [PATCH] Non-blocking protocols

[Nicolas George]

Le duodi 12 pluvi?se, an CCXIX, Ronald S. Bultje a ?crit?:
> I don't think make test tests network protocols... That's a bug, but
> just saying that make test doesn't do anything useful here...

It tests the ffmpeg tool, which in turn uses the file and possibly pipe
protocols. That is not much, but still something.

> - if we have a non-blocking API, then we should have a library
> function to get FDs and/or poll them. Is that available through
> url_*() API? I believe it is, because rtsp.c uses it, but just want to
> make sure

There is URLProtocol.url_get_file_handle, but it may not be enough, as some
protocols need several file descriptors, and others may need none at all. A
clean interface needs to be implemented very carefully.

> - this is just for protocols, not demuxers, right? Should we introduce

There is already a flag for muxers and demuxers, currently implemented only
by ALSA, OSS, V4L and vfwcap. Unfortunately, the handling is all wrong in
the surrounding tools, which makes, for example "ffmpeg -i file -f alsa
default" fail with strerror(EAGAIN) instead of playing the file.

Hopefully, starting from the bottom would make it possible to correct this.

> a flag to indicate which protocols support non-blocking red/write?

Do we expect that some protocols will never support it?

> This'd be nice for things like webcams and so on also at some point

Webcams can be a bit different: working in non-blocking mode can lead to
dropped frames with some drivers. I think that for devices, running the
device in a separate thread could be a more robust solution. I have very
accurate ideas about how to do that, but had not yet time to implement them.

> Use /**< or ///<, otherwise it documents what's after it, not before.

Done.

> (Please test this by checking the output HTML when running doxygen.)

Do you know how to make a Doxygen comment refer to the several next fields?

> The 100ms needs to become a settable AVOption (in the future).

I agree, but it seems unrelated.

> I like this patch, but removing the loop from the read/write and
> splitting the poll into its own function would be easier in two
> functions.

I did so, and found a bug in the process (it always checked for POLLOUT). I
sent the updated patches.

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-devel/attachments/20110202/df1ec633/attachment.pgp>