gst-editor updated for Gtk+ 3, GStreamer 1.0 support in progress

[Robin Haberkorn]

On Tue, 21 Jun 2016 09:37:28 +0300
Sebastian Dröge <sebastian at centricular.com> wrote:

> ...
> 
> If you can express all pipelines that gst-editor can build with
> GstParse, then this seems like a useful solution as it would also
> allow passing it to gst-launch and using it directly in other
> software.
> 
> You should first check that though, maybe there are some cases that
> can't be expressed by GstParse. If my memory of gst-editor is correct,
> then it can.
> 
Will check that. I'm optimistic. If not, I will try to forward-port
GstXML. According to Hannes Bistry, it worked quite well on v0.10 after
some patches he's submitted.

> > Perhaps you might also be interested in maintaining GstParse
> > serialization support as part of upstream. People might find that
> > useful.
> 
> The problem is that you can't serialize a pipeline in general in a
> lossless way, be it with former GstXML or GstParse. There is a lot
> that neither of the two can't express but which you can write in
> actual code.
> 
Well I think that, if the serialization can serialize everything that is
supported by GstParse; that would be a reasonable and documentable
compromise. It could throw warnings for unsupported constructs. If the
serialization is part of gst-editor, it would be sufficient if it can
serialize everything buildable by the editor.

Think about GtkBuilder: Does it allow everything expressible in Gtk+
calls? Not at all. Did that prevent the development of Glade?
Fortunately not. However, serialization is part of Glade, not core
Gtk+.

Another question:

GstXML had a way to extend the serialization of objects (see
"object-saved" signal in Gst 0.10) and deserialization of objects (see
GstXML's "object-loaded" signal). This was used by gst-editor to
persist the node dimensions. Is there currently any way to add custom
data to objects in the gst-launch syntax? If not I could still use a
custom section in my save files.

> Which is also the main reason why gst-editor was considered not too
> useful and abandoned by various people in the past who worked on it,
> it can only build a small subset of all possible pipelines.
> 
Which is better than nothing.

Best regards,
Robin

-- 
Robin Haberkorn
Developer

metraTec GmbH
Niels-Bohr-Str. 5
39106 Magdeburg
Germany

haberkorn at metratec.com
www.metratec.com