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

Hendrik Leppkes h.leppkes at gmail.com
Fri Jan 17 09:44:16 EET 2020


On Fri, Jan 17, 2020 at 12:30 AM Michael Niedermayer
<michael at 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 <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);
>                  ^

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


More information about the ffmpeg-devel mailing list