[FFmpeg-devel] [PATCH] rtsp protocol : teardown packet not sent

[Nicolas Adenis-Lamarre]

>> 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 blocking io)
tearing is just a packet to send. No answer has to be waited. And if it's
not done, it's not dramatic, it's just better.
Sending the message in a non blocking manner could be accepted by ffmpeg
team ? I thing it's a very short io, sending just to the linux net stack a
packet. (no network wait). It seems to fail only if the net stack is
already filled as far as i understand.

http://linux.die.net/man/2/send
*: send man pageMSG_DONTWAIT* (since Linux 2.2) Enables nonblocking
operation; if the operation would block, *EAGAIN* or *EWOULDBLOCK* is
returned (this can also be enabled using the *O_NONBLOCK* flag with
the *F_SETFL
fcntl*(2)).)

I don't understand why the close must be done before the windows closure.
Why not closing the window first, then close the protocol (but being sure
it will not stuck for ever).

>> if the server does not take it into account, blame it for being stupid.
I agree the server is stupid. However, if one does, i guess it's based on a
software available to many places.
And the server programmers would tell i don't respect the protocol. But i
definitively agree with that point.

>> All this is necessary because there are various causes for blocking; if
>> ffplay is stuck waiting for more data in the middle of a packet header
but
>> the network went down, interrupting the I/O is the only solution.
tearing packet is not a packet for which you have to wait something in
feedback. (it's only a write ; and i think it's possible to make it non
blocking generating an EAGAIN to ignore or to test a second time before
giving up.)

Nicolas