Le nonidi 29 vendémiaire, an CCXXIV, Nicolas Adenis-Lamarre a écrit : > Probably i misunderstood again, but, > I don't understand however in which case an application would use a > callback to avoid any io at all. > For example, i don't understand why ffplay, when a user close the window, > choose to avoid any io at all.
Any I/O can cause delay. When the user close the window, they want it to close immediately, not in five seconds. Even a tenth of a second gives a noticeable lag, it is not annoying in itself bug will cause the user to unconsciously consider the program badly finished. > in ffplay.c, would it be ok to change > static int decode_interrupt_cb(void *ctx) { return ctx->abort_request; } > by > static int decode_interrupt_cb(void *ctx) { return 0; } > ? > (i don't think so) Look at the code: static void stream_close(VideoState *is) { /* XXX: use a special url_shutdown call to abort parse cleanly */ is->abort_request = 1; SDL_WaitThread(is->read_tid, NULL); The author was well aware of the issue, but interrupting the network flow is simpler. Note that it should not matter: the teardown packet is required by the protocol, but the closure is also transmitted by other means (probably TCP RST or ICMP, depending on the transport layer used), and if the server does not take it into account, blame it for being stupid. > * change the user application to not return 1 from the callback > => i could, but i'm afraid that even ffplay which is a part of ffmpeg has > the problem. As you can see, a correct implementation of the shutdown would be appreciated. IMHO, the best way of doing so would be: - queue an immediate display of having taken the user's request into account; - start clean shutdown; - wait a configurable amount of time and revert to interrupting the I/O. 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. > 2015-10-20 19:20 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>: Please remember not to top-post on this list; if you do not know what it means, look it up. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel