On Thu, 23 Jan 2020 at 08:12, Marton Balint <c...@passwd.hu> wrote: > > > On Wed, 22 Jan 2020, Nicolas George wrote: > > > Marton Balint (12020-01-16): > >> 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. > > > > I don't like this. 0.1 s is less noticeable than 1 s for interactive > > human users, but for applications it may be way too much. > > pthread_cancel is not implemented properly on Win32, also it is generally > not considered a good practice. 0.1 sec delay is still the lesser evil > than a lockup as shown in ticket #5717. > > An alternate approach might be to call shutdown() from the main thread and > hope that this interrupts the recvfrom() call in the receiver thread. It > tends to work for linux, I am not sure how other platforms would react, > what do you think?
I actually had an old patch for that too. On Win32 the shutdown function will cause any existing recv calls in other threads to instantly return with an error code. I havnt tested the patch recently with current ffmpeg master but it should serve as a proof of concept.
avformat-udp-Enable-FIFO-when-using-windows-sockets.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".
