[FFmpeg-devel] [PATCH 4/4] avformat/udp: do not use thread cancellation when receiving data

[Michael Niedermayer]

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 <cus at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200117/b60ca0e5/attachment.sig>