Raspberry pi videowall using gstreamer - questions stability GstNet and how to debug

[reinzor]

Hi All,

Use case:

I recently started a new project: building a video wall using a farm of
Raspberry Pi zero's using gstreamer:

https://github.com/reinzor/videowall

The application is a server / client system and the principle is as follows:

The server provides the net time using the NetTimeProvider of the GstNet
library and sends meta-information (filenames, base_time, etc) via multicast
to all the clients. The clients have a NetClientClock as clock provider for
their own pipelines. The principle works and I am able to play videos
synchronously over the network where I use my laptop as a server and several
Raspberry pi zeros as clients.

Problem:

However, sometimes, the client players do not start playing. This occurs
once every 5 times or so. When I send a request for a new video with an
update base time, it mostly works again.

Question:

- Is there a way I can obtain more information why the client players are
not starting? (I am already setting GST_DEBUG=1)
- The players are wrapped in a GTK window
(https://github.com/reinzor/videowall/blob/master/src/videowall/players/player.py#L102)
and the GTK loop is handling the Glib events in a separate thread
(https://github.com/reinzor/videowall/blob/master/src/videowall/players/player.py#L56),
is this the right way to do it?
- On every new play request, I am re-creating the total pipeline because
changing the location property of the filesrc seem to be very unstable. What
is the recommended way to do this?

Thanks in advance,

Rein



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

[James Cameron]

G'day,

Your failure every five times sounds like a race condition between
GTK+ and GStreamer.  Either of them could win the race; with the
Gtk.DrawingArea not realised at the time the GStreamer sink window is,
or vice versa.  Looking at player.py briefly, the things I notice are;

1.  you aren't calling enable_sync_message_emission, or connecting to the
sync-message::element signal, to catch the prepare-window-handler
message and calling set_window_handle there if the XID is known,

2.  you aren't connecting to the realize signal of the Gtk.DrawingArea
to catch the XID, and calling set_window_handle there if the sink is
known,

3.  you are polling for state changes to a local variable instead of
using Gst.Pipeline::get_state with a timeout.

4.  you are using "import threading"; which is something that I've not
found necessary.

Hope that helps.  I've nothing to say about changing location of
filesrc.

On Wed, Aug 29, 2018 at 09:09:35AM -0500, reinzor wrote:

> Hi All,
>
> Use case:
>
> I recently started a new project: building a video wall using a farm of
> Raspberry Pi zero's using gstreamer:
>
> https://github.com/reinzor/videowall
>
> The application is a server / client system and the principle is as follows:
>
> The server provides the net time using the NetTimeProvider of the GstNet
> library and sends meta-information (filenames, base_time, etc) via multicast
> to all the clients. The clients have a NetClientClock as clock provider for
> their own pipelines. The principle works and I am able to play videos
> synchronously over the network where I use my laptop as a server and several
> Raspberry pi zeros as clients.
>
> Problem:
>
> However, sometimes, the client players do not start playing. This occurs
> once every 5 times or so. When I send a request for a new video with an
> update base time, it mostly works again.
>
> Question:
>
> - Is there a way I can obtain more information why the client players are
> not starting? (I am already setting GST_DEBUG=1)
> - The players are wrapped in a GTK window
> (https://github.com/reinzor/videowall/blob/master/src/videowall/players/player.py#L102)
> and the GTK loop is handling the Glib events in a separate thread
> (https://github.com/reinzor/videowall/blob/master/src/videowall/players/player.py#L56),
> is this the right way to do it?
> - On every new play request, I am re-creating the total pipeline because
> changing the location property of the filesrc seem to be very unstable. What
> is the recommended way to do this?
>
> Thanks in advance,
>
> Rein
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[reinzor]

Sorry for the late reply. But thanks for your suggestions. I am working on an updated player now.

On Thu, Aug 30, 2018 at 4:00 AM James Cameron <[hidden email]> wrote:

G'day,

Your failure every five times sounds like a race condition between
GTK+ and GStreamer.  Either of them could win the race; with the
Gtk.DrawingArea not realised at the time the GStreamer sink window is,
or vice versa.  Looking at player.py briefly, the things I notice are;

1.  you aren't calling enable_sync_message_emission, or connecting to the
sync-message::element signal, to catch the prepare-window-handler
message and calling set_window_handle there if the XID is known,

2.  you aren't connecting to the realize signal of the Gtk.DrawingArea
to catch the XID, and calling set_window_handle there if the sink is
known,

3.  you are polling for state changes to a local variable instead of
using Gst.Pipeline::get_state with a timeout.

4.  you are using "import threading"; which is something that I've not
found necessary.

Hope that helps.  I've nothing to say about changing location of
filesrc.

On Wed, Aug 29, 2018 at 09:09:35AM -0500, reinzor wrote:
> Hi All,
>
> Use case:
>
> I recently started a new project: building a video wall using a farm of
> Raspberry Pi zero's using gstreamer:
>
> https://github.com/reinzor/videowall
>
> The application is a server / client system and the principle is as follows:
>
> The server provides the net time using the NetTimeProvider of the GstNet
> library and sends meta-information (filenames, base_time, etc) via multicast
> to all the clients. The clients have a NetClientClock as clock provider for
> their own pipelines. The principle works and I am able to play videos
> synchronously over the network where I use my laptop as a server and several
> Raspberry pi zeros as clients.
>
> Problem:
>
> However, sometimes, the client players do not start playing. This occurs
> once every 5 times or so. When I send a request for a new video with an
> update base time, it mostly works again.
>
> Question:
>
> - Is there a way I can obtain more information why the client players are
> not starting? (I am already setting GST_DEBUG=1)
> - The players are wrapped in a GTK window
> (https://github.com/reinzor/videowall/blob/master/src/videowall/players/player.py#L102)
> and the GTK loop is handling the Glib events in a separate thread
> (https://github.com/reinzor/videowall/blob/master/src/videowall/players/player.py#L56),
> is this the right way to do it?
> - On every new play request, I am re-creating the total pipeline because
> changing the location property of the filesrc seem to be very unstable. What
> is the recommended way to do this?
>
> Thanks in advance,
>
> Rein
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
James Cameron
http://quozl.netrek.org/

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