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 575814 - flag for EOS on gst-launch when exiting with ctrl-c
flag for EOS on gst-launch when exiting with ctrl-c
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal enhancement
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-18 10:58 UTC by Thiago Sousa Santos
Modified: 2009-03-27 12:48 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
My suggestion (3.66 KB, patch)
2009-03-19 00:55 UTC, Thiago Sousa Santos
none Details | Review
Updated patch (4.78 KB, patch)
2009-03-20 16:11 UTC, Thiago Sousa Santos
none Details | Review
Updated patch (4.76 KB, patch)
2009-03-21 03:05 UTC, Thiago Sousa Santos
none Details | Review
Updated patch (4.85 KB, patch)
2009-03-26 16:13 UTC, Thiago Sousa Santos
committed Details | Review

Description Thiago Sousa Santos 2009-03-18 10:58:34 UTC
When using gst-launch to record from a webcam, pressing ctrl-c just sets the pipeline to null and some muxers (I've tested avimux and qtmux) doesn't properly finish their files because they expect an EOS to do so.

It is proposed that a flag is added in gst-launch, something like '--eos-on-shutdown'. This would force EOS on sources and wait for the sinks to get them before quitting.
Comment 1 Thiago Sousa Santos 2009-03-19 00:55:19 UTC
Created attachment 130930 [details] [review]
My suggestion

This is my proposed patch to enhance it.

One thing I thought about is when the user presses ctrl-c when an EOS is already at the pipeline. What happens when we try to push another one? Is that possible?
Comment 2 Edward Hervey 2009-03-19 08:04:52 UTC
At a glance it looks good.

I think you should store the state of what's been going on.

If --eos-on-shutdown and CTRL-C => send EOS => mark state as having sent EOS
If you press CTRL-C again => see that we've already sent EOS => Do the normal shutdown (current behaviour).
Comment 3 Tim-Philipp Müller 2009-03-19 09:12:22 UTC
Small nitpick and two suggestions:

 - would be nice if you turned the defines into an enum type
   (EventLoopResult or something similar)

 - another PRINT "Waiting for ..." after the send_event()
   would be good, I think

 - how about another PRINT after the last event_loop run to
   tell the user either that we got an EOS message and all
   is well, or something else happened and we didn't shut
   down cleanly?
 
Comment 4 Thiago Sousa Santos 2009-03-20 16:11:44 UTC
Created attachment 131036 [details] [review]
Updated patch

Updated with the suggestions
Comment 5 Thiago Sousa Santos 2009-03-21 03:05:46 UTC
Created attachment 131064 [details] [review]
Updated patch
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-25 20:27:12 UTC
Looks nice. Two comments:

typedef enum _EventLoopResult
{
  NO_ERROR = 0,
  ERROR,
  INTERRUPT
} EventLoopResult;

I wonder how hight the chances are that this clashes with some defines. What about

typedef enum _EventLoopResult
{
  ELR_NO_ERROR = 0,
  ELR_ERROR,
  ELR_INTERRUPT
} EventLoopResult;

also in main, just spell out the variable.
eos_on_shutd -> eos_on_shutdown
Comment 7 Thiago Sousa Santos 2009-03-26 16:13:13 UTC
Created attachment 131442 [details] [review]
Updated patch
Comment 8 Thiago Sousa Santos 2009-03-27 11:40:21 UTC
Committed.

git commit hash:
5fa36d9f3d8d2fddc5171de927f0640f5ef056b4