[FFmpeg-devel] [PATCH] udp: do not wait for data from the receiving thread.

Nicolas George nicolas.george at normalesup.org
Thu Mar 15 10:21:46 CET 2012


Le quintidi 25 ventôse, an CCXX, Reimar Döffinger a écrit :
> Well, that was the case originally. But if I remember correctly some
> people decided that it shouldn't be necessary in the first place
> and changed lower level code to be blocking.

I do not remember that discussion. The receive thread for UDP comes from our
side: it was added by the following commit in May last year:

http://git.videolan.org/?p=ffmpeg.git;h=4275602183d35eed9a9b7bbfef57ffc44d3484e7
udp: add a thread into udp.c for receiving data into a circular buffer

which initially did not support non-blocking at all; non-blocking was added
by Michael in December:

http://git.videolan.org/?p=ffmpeg.git;h=9f50dafe9025555f11e66e3b09cf3db2cd53cfb2
udp: support non blocking reads with fifo

but he was unaware of the current design of non-blocking and interrupting.
Apart from that, our retry_transfer_wrapper and udp_read are almost
identical to the ones on the libav side.

Furthermore, the TCP code also still behaves like that.

So if anyone has spoken about changing that design, no one has acted upon
it.

OTOH, while re-reading the code, I realized that udp_read (and tcp_read)
introduce a 100 ms blocking read additionally to the 1 ms sleep in
retry_transfer_wrapper. I must fix my patch accordingly.

> I am not sure whether I am just imagining it, whether there was some
> good reason or whether it was due to some performance/high wakeup
> rate issues.

Maybe you wanted to write about it yourself because you find that design
ugly? I sure do.

Redesigning the protocol reads to eliminate active polling while allowing
interrupts, and allowing selection on multiple handles: maybe that could
constitute a GSoC task, since it is the period to throw wild ideas.

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://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120315/7ac30472/attachment.asc>


More information about the ffmpeg-devel mailing list