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

[Sebastian Dröge]

On Di, 2016-06-21 at 19:07 +0200, Robin Haberkorn wrote:
> 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.

It should support everything you need, yes. GstParse I mean.

> > > 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+.

The bigger problem is that you will be able to "serialize" every
pipeline. Just that deserializing it will produce something that does
not work very well.

This is mostly because a pipeline is not just the pipeline graph
itself, but also all code that manages it at runtime. Just think of
pipelines having pad probes that dynamically change the topology.

However having gst-editor serialize a pipeline by itself seems like a
good and useful idea. Just not having generic API for doing that on a
generic pipeline (as the results usually won't work).

> 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.

No, that's not possible.

-- 

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160622/4e01ecf9/attachment.sig>