[FFmpeg-devel] [PATCH 1/3] Non-blocking protocols: flag and documentation

[Nicolas George]

Le sextidi 16 pluvi?se, an CCXIX, Ronald S. Bultje a ?crit?:
> I'm basically willing to apply this, I'm wondering if we need a flag
> to indicate which URLProtocols support non-blocking opening. Anyone
> have opinions on this? Or should we just assume it'll always be
> supported for all protocols? (Does file/pipe/etc. support it now?)

My humble opinion, in three points:

- Hopefully, all protocols that can possibly have non-blocking operations
  implemented should get them in a reasonable time. At least, since you
  approved the principle, I intend to work on the protocols I know and can
  test (UDP, pipe, HTTP).

- The file protocol will probably never get non-blocking: AFAIK, since Unix
  does not support non-blocking reads on plain files, it would require
  either forking a background process/thread or using signal-driven IO, and
  we probably do not want any of that.

- On the other hand, Unix has survived for many years by silently ignoring
  O_NONBLOCK on plain files.

So, in conclusion, I do not know whether it is necessary.

> Question: udp.c is still a mess, could you consider cleaning that up also?

I intend to look at it and try to implement non-blocking read/writes. But I
never managed to get anything working with multicast, so I will probably not
touch this part.

> Also, I know this has nothing to do with before your patch, but a
> quick grep shows:
> libavformat/rtsp.c:                        ret =
> url_read(rtsp_st->rtp_handle, buf, buf_size);
> libavformat/rtsp.c:        ret = url_read(in, recvbuf, sizeof(recvbuf));
> libavformat/sapdec.c:        ret = url_read(sap->ann_fd, recvbuf,
> sizeof(recvbuf) - 1);
> libavformat/sapdec.c:        ret = url_read(sap->ann_fd, recvbuf,
> sizeof(recvbuf));
> 
> These seem ... questionable, and might need review. Particularly the
> one in the RTP punching code in rtsp.c is questionable and looks
> unsafe/wrong. Is anyone interested in fixing these up and moving them
> up to url_read_complete() or otherwise making sure they are safe?

Concerning sapdec, sap->ann_fd seems to be UDP. As UDP is packet-based,
url_read will read one single packet; in fact, calling url_read_complete on
a packet-based protocol would probably be wrong.

But this raises disturbing questions: stream-based protocols and
packet-based protocols behave in a very different manner with regard to
reads, especially partial reads. It certainly needs more thought, and then
at least documentation.

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