On Fri, 17 Jan 2020, Michael Niedermayer 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.
This patch also fixes ticket #5717 by the way.
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....
With the pthread_cond_timedwait compat patch applied, this should no
longer be an issue.
Regards,
Marton
_______________________________________________
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".
