GNOME Bugzilla – Bug 630997
gst-launch: make -e send EOS after error too, so transcoded/muxed streams get finalised properly
Last modified: 2012-05-18 08:15:24 UTC
When I execute this pipeline from the command line... gst-launch -e rtspsrc location=rtsp://192.168.1.211:8109/camera.sdp ! rtpmp4vdepay ! mpeg4videoparse ! mp4mux ! filesink location=myfile ...and send a SIGINT to the process I get a file that is playable because I specified the '-e' which indicates that EOS on shutdown. However, if I execute the same pipeline from the command line and remove the RTSP server (i.e. force a socket error) the process exits without performing an EOS on shutdown. A quick look at the code in "gst-launch.c" confirmed my suspicion that EOS on shutdown is only performed on a SIGINT. What if my application has recorded valuable video data and the network goes down, does this mean I have lost all of that data since the file will not be viewable due to the absence of EOS on shutdown processing on anything that is not a SIGINT?
A socket error in rtspsrc should ideally lead to an EOS event sent downstream too after posting an error message. I guess gst-launch gets the error first and then shuts down the pipeline. Maybe the -e should really always send an EOS event downstream when shutting down the pipeline unless the pipeline is shut down because of EOS. Do you want to provide a patch for that? You should really write some code to do what you want instead of using gst-launch though. That way you can handle errors like this and make it behave like you need it.
Hi Sebastian, I can provide a patch for this. I have been working on one. When I am finished I will attach it to this bug report. Best Regards, Rob Krakora
Not entirely sure what you're asking for: do you think there is a bug in some core functionality here, or some element, or do you just want rtspsrc to send down that eos event on error? Setting NEEDINFO, awaiting your patch.
Ping Robert?
Hello, I have not had time to complete/debug the patch lately. I just changed jobs and have been preoccupied. However, if the rtspsrc element encounters a socket error while a file is being recorded in the pipeline below, gst-launch exists without sending an EOS down the pipeline so that the filesink element "buttons up" the file nicely so that it is playable after gst-launch tears down the pipe line. gst-launch -e rtspsrc location=rtsp://192.168.1.211:8109/camera.sdp ! rtpmp4vdepay ! mpeg4videoparse ! mp4mux ! filesink location=myfile Best Regards, Rob Krakora
any news for this report? still exists?
Ok, so if I understand correctly the request is basically that gst-launch should also force an EOS on the pipeline (and wait for the result) when it catches an error message on the bus. I'm not sure if that's a good idea because when you get an error message on the bus you don't know if the EOS event will ever make it through to the sinks, so waiting for an EOS message could take forever. Also, gst-launch is a tool for debugging purposes, don't use it in any kind of production environment where you have precious data that you can't lose. But then, gst-launch is just a debugging tool, so if it hangs forever trying to force an EOS after an error isn't the end of the world either.
FWIW, neonhttpsrc sends an EOS when the peer resets the socket, i.e., "socket error". This behavior seems quite natural.
So is this a WONTFIX then?
Not really, rtspsrc should send EOS in any case if something goes wrong (socket error or whatever).
O.K. I agree, it should send an EOS. I also agree that gst-launch is a debugging tool. If rtspsrc doe not currently send an EOS when the peer resets the socket then this is a deficiency? I assume that all of the network source elements would want to adhere to a similar paradigm?
*** Bug 651031 has been marked as a duplicate of this bug. ***
commit 6e878031144ace9255998d9b70be47081c9e4915 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri May 18 09:52:09 2012 +0200 launch: improve EOS on shutdown handling When the -e option is selected, also wait for EOS when the pipeline produced an error. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=630997