On Sun, Oct 18, 2015 at 10:13:29PM +0200, Nicolas Adenis-Lamarre wrote: > The rtsp protocol requires the client to send a packet at the end of the > connexion. > FFmpeg basic network function check wether the user aborted the > communication and don't send the packet in this case. > So the protocol is not respected. > This commit removes the check. An other possibility would have to add an > extra parameter to these functions to force the packet sending.
When the rt*p code and the connection is correctly functioning then ff_check_interrupt() will return 0 When the code gets stuck due to the network connection or other side failing then ff_check_interrupt() can return non zero if the user application wants to get control back in a last ditch effort before killing the process or thread. Now i do no know enough to say what the problem is exactly maybe this is a bug in the user application and it simply should not use the interrupt callback to terminate things or maybe the application has a good reason why it needs to use this method, in which case maybe the API is too limited to indicate that clean termination is requested instead of imedeate abortion of all transfers. If this is due to limitations of the API then extending the API is welcome but it should be done in a way that doesnt break existing user applications I belive the patch here would break the case where a actual hard and interruption is wanted because maybe all network communication would timeout due to network being down or such [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel