On Fri, Jan 17, 2020 at 12:30 AM Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote: > > It is not supported by every threading implementation, and the only thing we > > gain with it is an immediate shutdown of receiving packets on close and > > avoiding the poll call before reading the data. > > > > I don't think it is a big issue if it takes 0.1 sec of delay to close an udp > > stream. Back when this was introduced the delay was 1 sec, which was indeed > > noticable. > > > > And anybody who needs performance sensitive UDP should not use the fifo > > buffer > > in the first place, because the kernel can buffer the data much more > > effectively. > > > > Signed-off-by: Marton Balint <c...@passwd.hu> > > --- > > libavformat/udp.c | 57 > > +++++++++++++++++++++++++------------------------------ > > 1 file changed, 26 insertions(+), 31 deletions(-) > > this breaks build on mingw64 > > src/libavformat/udp.c: In function ‘udp_read’: > src/libavformat/udp.c:980:17: error: implicit declaration of function > ‘pthread_cond_timedwait’ [-Werror=implicit-function-declaration] > int err = pthread_cond_timedwait(&s->cond, &s->mutex, &tv); > ^
We could add that to our own w32 pthread wrapper, unfortunately whoever designed pthread_cond_timedwait was on drugs, the absolute timespec is just crazy, instead of a delay in (milli|micro|nano)seconds, so we'll practically undo the math that same function already does to add its timeout to current time. But oh well. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
