On Fri, 17 Jan 2020 at 18:44, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> 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 I had an old patch for adding pthread_cond_timedwait wrapper for win32. Haven't checked if it still applies but its attached if it is useful.
avutil-thread-Add-pthread_cond_timedwait-function.patch
Description: Binary data
_______________________________________________ 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".
