>> Any I/O can cause delay. When the user close the window, they want it to
>> close immediately, not in five seconds.
Can you confirm that the problem is blocking io, and more generally
blocking system calls more than just io ? (i mean, we must take no risk to
have to wait, versus doing some non b
sus packet not
mandatory / not required / to abort if it is not so important.
Nicolas
2015-10-20 19:20 GMT+02:00 Michael Niedermayer :
> On Tue, Oct 20, 2015 at 06:16:12PM +0200, Nicolas Adenis-Lamarre wrote:
> > Let's take the example of ffplay in which the code always fails.
>
it could break things at
the beginning, the time, people find where to add correctly the interrupt
check at the good place, not in the low stack.
Nicolas
2015-10-20 15:50 GMT+02:00 Michael Niedermayer :
> On Sun, Oct 18, 2015 at 10:13:29PM +0200, Nicolas Adenis-Lamarre wrote:
>
have to add an
extra parameter to these functions to force the packet sending.
https://trac.ffmpeg.org/ticket/4929
Signed-off-by: Nicolas Adenis-Lamarre
From 415ea8cad8cd4df9c32229918ccb0c84ca2c1c4a Mon Sep 17 00:00:00 2001
From: Nicolas Adenis-Lamarre
Date: Sun, 18 Oct 2015 22:02:47 +0200
Su
When a client close a rtsp connexion, it is supposed to send the TEARDOWN
packet according to
​https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol to tell to the
server to stop the streaming.
ffmpeg doesn't (controlled by wireshark, works with some other soft), while
i guess it worked at a g
