Nicolas George george at nsup.org wrote: >> libavformat/udp.c | 133 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 129 insertions(+), 4 deletions(-)
>Missing documentation update. fixed. >> - while(1) { >> + for(;;) { >Stray change. Portability. You don't know how a compiler other than clang or gcc will optimize or not optimize "while (1) { }". >> + if (!(h->flags & AVIO_FLAG_NONBLOCK)) { >This looks suspicious: blocking/nonblocking is a property of the protocol as >seen by the calling application, it should not apply in a thread used >internally. See below. The thread should work as original non-thread code. >> + ret = sendto (s->udp_fd, buf, size, 0, >> + (struct sockaddr *) &s->dest_addr, >Style: no spaces after function names and casts. It is not my code. This block from static int udp_write(URLContext *h, const uint8_t *buf, int size) >> + av_usleep(s->packet_gap); >Not very reliable: if the task gets unscheduled for some time, it will be >added to the gap and never catch, possibly causing playback hiccups. A >system with a kind of rate control would probably be better. Want reliable delay ? Spin in a loop polling dogettimeofday() in kernel w/o task switch. Otherwise the only thing we have is usleep() . No more options available to make a delay in user space: all of them cause task switch with unpredicted return time after delay (preemtable kernel, you knows). If all goes right and a system is not overloaded the gap between packets will be as set (and tcpdump with -ttt prove this). Also, we have a sendto() syscall (preemption again), the UDP socket buffer, a network device TX ring and many other things like "backpressure" on an ethernet switch port that will cause the delay be more than specified. >> + /* >> + Create thread in case of: >> + 1. Input and circular_buffer_size is set >> + 2. Output and packet_gap and circular_buffer_size is set >> + */ >UDP sockets can be read+write; in this case, two threads are needed. The UDP socket are mostly read or mostly write. The thread will handle the most part of socket communication, no need to make a thread for handle some packets. Fixed version of the patch in attachment.
udp.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel