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

[Robin Haberkorn]

Hello,

I wanted to inform you that I forked the old gst-editor (GStreamer
pipeline editor) project:

https://github.com/metratec/gst-editor/

This was forked from the abandoned v0.10.3.2 which was last worked on by
Hannes Bistry, supporting Gtk+ 2 and GStreamer 0.10. Originally
gst-editor appeared to be a part of the GStreamer project but was
eventually dropped.

The goal is to update this project to work with recent Gtk+ 3 and
GStreamer 1.0 APIs.

So far, the project builds cleanly on Gtk+ 3 - v3.10.8 at least which
is what I use here on Ubuntu 14.04. The old version did not even run
properly on Gtk+ v2.24, so that makes the fork interesting already.

It is still stuck at GStreamer 0.10, though. I'm starting to port it to
v1.0 APIs now.

There is one major obstacle: GstXML support has been removed in v1.0.
Supposedly it never worked properly anyway. Naturally some way of
persisting/serializing pipelines would be very helpful.

Do you know of any alternative/replacement that I might use? This could
also be code from another project that I would incorporate into the
gst-editor code base for the time being.
The Pipeviz editor has some XML serialization code, but it is broken as
well and could only serve as a reference anyway.

If something like this does not exist, I think I will start working on
serialization support for the GstParse (gst-launch) format. The reason
is that there is already deserialization support and it is maintained by
the community.

Perhaps you might also be interested in maintaining GstParse
serialization support as part of upstream. People might find that
useful.

I hope that this project will generate some interest in the GStreamer
community. A pipeline editor is often asked for. Feel free to take part
in its development.

Best regards,
Robin
--
Robin Haberkorn
Developer

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

[hidden email]
www.metratec.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Sa, 2016-06-18 at 02:26 +0200, Robin Haberkorn wrote:

> 
> There is one major obstacle: GstXML support has been removed in v1.0.
> Supposedly it never worked properly anyway. Naturally some way of
> persisting/serializing pipelines would be very helpful.
>
> Do you know of any alternative/replacement that I might use? This could
> also be code from another project that I would incorporate into the
> gst-editor code base for the time being.
> The Pipeviz editor has some XML serialization code, but it is broken as
> well and could only serve as a reference anyway.
>
> If something like this does not exist, I think I will start working on
> serialization support for the GstParse (gst-launch) format. The reason
> is that there is already deserialization support and it is maintained by
> the community.

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.

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

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.

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Robin Haberkorn]

On Tue, 21 Jun 2016 09:37:28 +0300
Sebastian Dröge <[hidden email]> 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

[hidden email]
www.metratec.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Robin Haberkorn]

Hello again,

the project is now in a state where it compiles and runs against
GStreamer 1.0. It survived some basic testing but is far from being
bug-free.

Loading and saving pipelines is currently disabled. I will work on that
as soon as I have evaluated a few more technical aspects.

Best regards,
Robin

On Sat, 18 Jun 2016 02:26:59 +0200
Robin Haberkorn <[hidden email]> wrote:

> Hello,
>
> I wanted to inform you that I forked the old gst-editor (GStreamer
> pipeline editor) project:
>
> https://github.com/metratec/gst-editor/
>
> This was forked from the abandoned v0.10.3.2 which was last worked on
> by Hannes Bistry, supporting Gtk+ 2 and GStreamer 0.10. Originally
> gst-editor appeared to be a part of the GStreamer project but was
> eventually dropped.
>
> The goal is to update this project to work with recent Gtk+ 3 and
> GStreamer 1.0 APIs.
>
> So far, the project builds cleanly on Gtk+ 3 - v3.10.8 at least which
> is what I use here on Ubuntu 14.04. The old version did not even run
> properly on Gtk+ v2.24, so that makes the fork interesting already.
>
> It is still stuck at GStreamer 0.10, though. I'm starting to port it
> to v1.0 APIs now.
>
> There is one major obstacle: GstXML support has been removed in v1.0.
> Supposedly it never worked properly anyway. Naturally some way of
> persisting/serializing pipelines would be very helpful.
>
> Do you know of any alternative/replacement that I might use? This
> could also be code from another project that I would incorporate into
> the gst-editor code base for the time being.
> The Pipeviz editor has some XML serialization code, but it is broken
> as well and could only serve as a reference anyway.
>
> If something like this does not exist, I think I will start working on
> serialization support for the GstParse (gst-launch) format. The reason
> is that there is already deserialization support and it is maintained
> by the community.
>
> Perhaps you might also be interested in maintaining GstParse
> serialization support as part of upstream. People might find that
> useful.
>
> I hope that this project will generate some interest in the GStreamer
> community. A pipeline editor is often asked for. Feel free to take
> part in its development.
>
> Best regards,
> Robin

--
Robin Haberkorn
Developer

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

[hidden email]
www.metratec.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Di, 2016-06-21 at 19:07 +0200, Robin Haberkorn wrote:

> On Tue, 21 Jun 2016 09:37:28 +0300
> Sebastian Dröge <[hidden email]> 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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Robin Haberkorn]

Hello,

the gst-editor fork will now load and save pipelines again. This is
based on a serialisation to the GstParse/gst-launch syntax.

It can either save plain pipelines (or copy them to the clipboard)
that can e.g. be directly pasted into a terminal for execution with
`gst-launch`; or you can save pipelines in the special *.GEP
(Gst-Editor Pipeline) format which is basically a plain pipeline with
some meta data for node positioning, wrapped in a GKeyFile. GKeyFiles
are used because they provide just enough structure, are easy to read
and are already part of glib.

The serialization code is here:
https://github.com/metratec/gst-editor/blob/master/libs/gst/common/gste-serialize.c

I deliberately kept this generic, so it can be easily copied/ported
into other applications. External applications may also choose to depend
on the libgsteditor library in order to gain serialization support.

Ghost pads are probably still broken -- I do not need them now.

Currently, you can only load pipelines from *.GEP files. However, I'm
planning to implement loading from plain pipelines as well.
Naturally this will require some automagic positioning of the pipeline
nodes. A useful feature in a graph editor anyway.

Best regards,
Robin

On Wed, 22 Jun 2016 01:07:19 +0200
Robin Haberkorn <[hidden email]> wrote:

> Hello again,
>
> the project is now in a state where it compiles and runs against
> GStreamer 1.0. It survived some basic testing but is far from being
> bug-free.
>
> Loading and saving pipelines is currently disabled. I will work on
> that as soon as I have evaluated a few more technical aspects.
>
> Best regards,
> Robin
>
> On Sat, 18 Jun 2016 02:26:59 +0200
> Robin Haberkorn <[hidden email]> wrote:
>
> > Hello,
> >
> > I wanted to inform you that I forked the old gst-editor (GStreamer
> > pipeline editor) project:
> >
> > https://github.com/metratec/gst-editor/
> >
> > This was forked from the abandoned v0.10.3.2 which was last worked
> > on by Hannes Bistry, supporting Gtk+ 2 and GStreamer 0.10.
> > Originally gst-editor appeared to be a part of the GStreamer
> > project but was eventually dropped.
> >
> > The goal is to update this project to work with recent Gtk+ 3 and
> > GStreamer 1.0 APIs.
> >
> > So far, the project builds cleanly on Gtk+ 3 - v3.10.8 at least
> > which is what I use here on Ubuntu 14.04. The old version did not
> > even run properly on Gtk+ v2.24, so that makes the fork interesting
> > already.
> >
> > It is still stuck at GStreamer 0.10, though. I'm starting to port it
> > to v1.0 APIs now.
> >
> > There is one major obstacle: GstXML support has been removed in
> > v1.0. Supposedly it never worked properly anyway. Naturally some
> > way of persisting/serializing pipelines would be very helpful.
> >
> > Do you know of any alternative/replacement that I might use? This
> > could also be code from another project that I would incorporate
> > into the gst-editor code base for the time being.
> > The Pipeviz editor has some XML serialization code, but it is broken
> > as well and could only serve as a reference anyway.
> >
> > If something like this does not exist, I think I will start working
> > on serialization support for the GstParse (gst-launch) format. The
> > reason is that there is already deserialization support and it is
> > maintained by the community.
> >
> > Perhaps you might also be interested in maintaining GstParse
> > serialization support as part of upstream. People might find that
> > useful.
> >
> > I hope that this project will generate some interest in the
> > GStreamer community. A pipeline editor is often asked for. Feel
> > free to take part in its development.
> >
> > Best regards,
> > Robin
>
>
>

--
Robin Haberkorn
Developer

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

[hidden email]
www.metratec.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel