Graphical tool to show/manipulate pipelines

[TheGiamig]

Hi, I'm thinking about a tool for create, manipulate and monitor pipelines.
In general my approach is to instance a "wrapper" object for each element in
the pipeline and discover some information about it so I can perform some
logics (eg. connect to weel-known signals as new-pad) and display a
graphical representation of element and pads links.
At the moment I'm interest to display the content of a single bin at a time.
If the pipeline contains a bin the user may double-click on it to display
the content.

The first problem in the design is related to dynamic behaviours, like pads
linked at runtime.
Sometimes pads seems to me not an actual problem because my wrapper  can
receive a notification when a pad is added, and then when the pad is linked.
In the other hand, request pads can be linked "silently" and I can't find a
way to receive a notification without modify or subclass original elements.

Any pointer and idea are welcome.
Thanks





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[fightling]

Have you tried to use GST_DEBUG_DUMP_DOT_DIR? It's not exactly what you
want but I use it to monitor pipelines at run time.

See also:

https://gstreamer.freedesktop.org/documentation/tutorials/basic/debugging-tools.html

On 07.03.19 12:55, TheGiamig wrote:

> Hi, I'm thinking about a tool for create, manipulate and monitor pipelines.
> In general my approach is to instance a "wrapper" object for each element in
> the pipeline and discover some information about it so I can perform some
> logics (eg. connect to weel-known signals as new-pad) and display a
> graphical representation of element and pads links.
> At the moment I'm interest to display the content of a single bin at a time.
> If the pipeline contains a bin the user may double-click on it to display
> the content.
>
> The first problem in the design is related to dynamic behaviours, like pads
> linked at runtime.
> Sometimes pads seems to me not an actual problem because my wrapper  can
> receive a notification when a pad is added, and then when the pad is linked.
> In the other hand, request pads can be linked "silently" and I can't find a
> way to receive a notification without modify or subclass original elements.
>
> Any pointer and idea are welcome.
> Thanks
>
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

--
regards, fightling.

[hidden email]
[hidden email]
@fightling
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[TheGiamig]

fightling wrote
> Have you tried to use GST_DEBUG_DUMP_DOT_DIR? It's not exactly what you
> want but I use it to monitor pipelines at run time.
>
> See also:
>
> https://gstreamer.freedesktop.org/documentation/tutorials/basic/debugging-tools.html

Yeah I know the dot file feature but I'm looking for an interactive tool,
not just a debugger.
Thanks



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[dabrain34]

Hello,

You can have a look to two projects providing a graphical approach to
GStreamer:


https://github.com/virinext/pipeviz

https://github.com/loganek/gst-debugger

I'm contributing to the first project.

Best regards.





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[TheGiamig]

dabrain34 wrote

> Hello,
>
> You can have a look to two projects providing a graphical approach to
> GStreamer:
>
> https://github.com/virinext/pipeviz
>
> https://github.com/loganek/gst-debugger
>
> I'm contributing to the first project.
>
> Best regards.
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

pipeviz is more or less what I'm looking for.. but some dynamic spects I'm
interested are'nt managed.
As far as I can understand reading the code, sometimes pad are'nt managed at
all, so eg. I can't create a pipeline with a demux.
I known, sometimes pads requires some code to be connected, but I'm thinking
to write some "standard actions" (and maybe "custom actions" in a future).
So graphically one can attach an action like "connect to element x" to the
new-pad signal, or something.

Request pads in pipeviz are managed yes, but statically: one can request a
pad so is available to be linked to other element. But I need to known at
runtime if a request pad is created so the graphics can be updated. That
signal cannot be fired by the element itself because I cannot modify or
subclass every possible element available in the plugins, just to add that
feature.

So I wonder if there is a way at core level to receive a "new-req" signal,
or if there is another (better?) way to achieve my goal (may be subclassing
at runtime thanks to some glib magics..).

I hope my english is good enough to explain my request.
Thanks





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[TheGiamig]

Just right now I'm reading the GstElement docs and there is two signals,
"pad-added" and "pad-removed".. seems to me I found what I'm looking for!

I can connect to them in my wrapper object and do something when signaled.
I wonder the diffference between "pad-added" and "new-pad" signal available
from some elements.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[TheGiamig]

TheGiamig wrote

> Just right now I'm reading the GstElement docs and there is two signals,
> "pad-added" and "pad-removed".. seems to me I found what I'm looking for!
>
> I can connect to them in my wrapper object and do something when signaled.
> I wonder the diffference between "pad-added" and "new-pad" signal
> available
> from some elements.
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


Sorry, I did a bit of confusion.
The "new-pad" signal does'nt exists, the actual name is "pad-added", so
forget about "new-pad" :)

Not sure if the "pad-added" signal is fired also after a request pad.
gst-inspect tee for example don't say nothing about that signal..









--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[TheGiamig]

After some tests I realized that pad-added is fired when a request pad is
created.
So the lack of signal is just in the gst-inspect output. Also tee emits
correctly the signal.

I think I can go further and start implementing.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[dabrain34]

Hello,

I'm happy to see that you'd like to participate to this project.
As you noticed, yes this project does not support dynamic pad such in a
demuxer in a correct way yet.
I'm having an idea also of a wrapper which allows to abstract the graphical
and the gstreamer part.

Right now the graphical part is the exact representation of the gstreamer
pipeline which should be more decorrelate.

Regarding demuxer which are the most important because dynamic element we
need to support, most of them trigger the "no-more-pads" signal too.
So we could imagine to trigger a play and wait for this signal to create and
draw the pads related to the element.

Please feel free to provide design document or branch related to your
implementation.

Best regards.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[sk_gst]

Also try having a look at Gst-Shark provided by RidgeRun.  Might be useful in
analysing individal elements in a pipeline



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel