After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630997 - gst-launch: make -e send EOS after error too, so transcoded/muxed streams get finalised properly
gst-launch: make -e send EOS after error too, so transcoded/muxed streams get...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal major
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 651031 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-09-30 12:31 UTC by Robert Krakora
Modified: 2012-05-18 08:15 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Robert Krakora 2010-09-30 12:31:03 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?
Comment 1 Sebastian Dröge (slomo) 2010-09-30 14:51:36 UTC
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.
Comment 2 Robert Krakora 2010-09-30 19:27:59 UTC
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
Comment 3 Tim-Philipp Müller 2010-10-07 23:30:42 UTC
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.
Comment 4 Felipe Besoaín Pino 2010-11-20 01:06:25 UTC
Ping Robert?
Comment 5 Robert Krakora 2010-11-22 04:35:55 UTC
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
Comment 6 Fabio Durán Verdugo 2011-01-03 02:03:00 UTC
any news for this report? still exists?
Comment 7 Tim-Philipp Müller 2011-02-04 01:19:22 UTC
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.
Comment 8 David Schleef 2011-02-04 02:02:16 UTC
FWIW, neonhttpsrc sends an EOS when the peer resets the socket, i.e., "socket error".  This behavior seems quite natural.
Comment 9 Tobias Mueller 2011-04-07 15:12:44 UTC
So is this a WONTFIX then?
Comment 10 Sebastian Dröge (slomo) 2011-05-17 08:08:27 UTC
Not really, rtspsrc should send EOS in any case if something goes wrong (socket error or whatever).
Comment 11 Robert Krakora 2011-05-17 11:48:13 UTC
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?
Comment 12 Sebastian Dröge (slomo) 2011-05-25 18:00:13 UTC
*** Bug 651031 has been marked as a duplicate of this bug. ***
Comment 13 Wim Taymans 2012-05-18 07:54:32 UTC
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