>> 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
