GNOME Bugzilla – Bug 614805
gst-launch: add --loop argument
Last modified: 2013-07-24 10:56:28 UTC
if --loop is specified, automatically seek to beginning of clip when EOS is received This is useful at least for demo's, because the video clip replays faster than it would if the gst-launch process exited and restarted (and re-auto-constructed the playbin2 pipeline). This patch also exposed some problem in our codec elements. So perhaps it is useful to others too?
Created attachment 157894 [details] [review] add --loop argument
I have a similar patch, but it does a state change cycle instead of a seek to 0 for the looping (useful to detect memory/resource leaks and the like).
(In reply to comment #2) > I have a similar patch, but it does a state change cycle instead of a seek to 0 > for the looping (useful to detect memory/resource leaks and the like). six of one, half dozen of the other ;-) I guess either approach would detect different issues.. but then again a simple python script could do either too.. it's your call whether to merge one or the other (or both or neither)
Tim, would you like to push your patch then?
Maybe we should add something more generic like events syntax of gst-auto-launch instead: https://github.com/tigrux/gst-auto-launch
> Maybe we should add something more generic like events syntax of > gst-auto-launch instead: https://github.com/tigrux/gst-auto-launch Yes, I think that'd be preferable too. However, I think we should default to reading 'commands' from a file or stdin line-by-line (with a line-ending separator maybe) instead of passing them as command line arguments. And the syntax could probably use some more refining, to make it more generic and extensible.
I like the idea of having a --commands=<filename> ('-' for stdin) and one command per line (\n as a command terminator). I think having a normal gst-timestamp (like in the log) would be good: 0:00:01.000000000 command <args> 0:00:02.200000000 command <args> if the timestamp is ommitted, we could assume the same timestamp like prev line. command could be: state {null,ready,paused,playing} event {seek, eos, .... } query {duration, position, ...} property element property name value
Again something similar was requested in Bug #612376.
Someone interested in working on this? Alternatively ges-launch should be able to do looping
I think we need something like gst-launch, but more powerful, written from scratch with that in mind, maybe with some simple scripting foo. I think we should WONTFIX this, esp. if ges-launch can do it.