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);
^
cc1: some warnings being treated as errors
make: *** [libavformat/udp.o] Error 1
make: *** Waiting for unfinished jobs....
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: PGP signature
_______________________________________________ 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".
