re-listening tcpserversrc?

[fightling]

Hey there!

I'm currently working on an open source live A/V mixer using gstreamer
called voctomix w have some A/V sources which come in over TCP. I'm
using a tcpserversrc to receive a stream that is send with ffmpeg.

When I want to restart ffmpeg (to switch to another content)
tcpserversrc does not seem to react in the logs I've seen.

And reconnecting from a new ffmpeg instance to the same tcpserversrc
also does not work.

I'm quite stuck right now!

Can someone please give me some advice?

--
regards, fightling.

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

[Nicolas Dufresne-5]

Le lundi 18 février 2019 à 18:19 +0100, fightling a écrit :

> Hey there!
>
> I'm currently working on an open source live A/V mixer using gstreamer
> called voctomix w have some A/V sources which come in over TCP. I'm
> using a tcpserversrc to receive a stream that is send with ffmpeg.
>
> When I want to restart ffmpeg (to switch to another content)
> tcpserversrc does not seem to react in the logs I've seen.
>
> And reconnecting from a new ffmpeg instance to the same tcpserversrc
> also does not work.
>
> I'm quite stuck right now!
>
> Can someone please give me some advice?

When the remote client disconnect, tcpserversrc will send EOS message
to your application. Catch this message and restart you pipeline when
this happens. It's a single client server.

Nicolas

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

[fightling]

Hm,

I'm already catching EOS messages by:

   self.pipeline.bus.connect("message::eos", self.on_eos)

but when I quit ffmpeg by Ctrl+C I get no EOS.

I tried to use a gst.watchdog which works. Now I'm stuck at restarting
the relevant part of the pipeline. I don't really want to restart the
whole pipeline because there are some other incoming connections I want
to hold. Actually I have several different sources. Some live (decklink)
and some from ffmpeg over TCP. Live sources shall continue running while
a tcp-source shall be restartable.

Is that possible?

A previous developer tried to use gst.inter* elements but that lead to
A/V sync problems.

Is there a better way to restart tcpserversrc?

On 18.02.19 22:58, Nicolas Dufresne wrote:

> Le lundi 18 février 2019 à 18:19 +0100, fightling a écrit :
>> Hey there!
>>
>> I'm currently working on an open source live A/V mixer using gstreamer
>> called voctomix w have some A/V sources which come in over TCP. I'm
>> using a tcpserversrc to receive a stream that is send with ffmpeg.
>>
>> When I want to restart ffmpeg (to switch to another content)
>> tcpserversrc does not seem to react in the logs I've seen.
>>
>> And reconnecting from a new ffmpeg instance to the same tcpserversrc
>> also does not work.
>>
>> I'm quite stuck right now!
>>
>> Can someone please give me some advice?
>
> When the remote client disconnect, tcpserversrc will send EOS message
> to your application. Catch this message and restart you pipeline when
> this happens. It's a single client server.
>
> Nicolas
>
>
> _______________________________________________
> 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

[MaZderMind]

Hi fightling :)

Am 19.02.19 um 12:53 schrieb fightling:
> I'm already catching EOS messages by:
>
>    self.pipeline.bus.connect("message::eos", self.on_eos)
As far as I understand, the bus is a way for an external Thread to be
notified of Events flowing down the Stream.
When you recieve the Message on the Bus(-Thread), is has already by sent
of the src and processed in the Streaming-Thread driven by the tcpserversrc.

In order to be able to drop the EOS-Event you could use a Pad-Probe
(https://gstreamer.freedesktop.org/documentation/design/probes.htm).

See here for an example how this could be done in python:
https://github.com/voc/voctomix/blob/master/example-scripts/gstreamer/source-nostream-music-from-folder.py#L155-L164

> but when I quit ffmpeg by Ctrl+C I get no EOS.
Here are the relevant lines from gsttcpserversrc.c:
https://github.com/GStreamer/gst-plugins-base/blob/4187242/gst/tcp/gsttcpserversrc.c#L231-L236

Running Voctomix with an Environment-Variable of
`GST_DEBUG=tcpserversrc:5` should give more information about what's
actually happening.

> I tried to use a gst.watchdog which works. Now I'm stuck at restarting
> the relevant part of the pipeline. I don't really want to restart the
> whole pipeline because there are some other incoming connections I want
> to hold. Actually I have several different sources. Some live (decklink)
> and some from ffmpeg over TCP. Live sources shall continue running while
> a tcp-source shall be restartable.
In
https://github.com/voc/voctomix/blob/master/example-scripts/gstreamer/source-nostream-music-from-folder.py#L170-L172
I stopped and restarted only a single Element of the Pipeline (here: an
uridecodebin). The same should be possible with a tcpseversrc.

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

[fightling]

On 19.02.19 13:09, MaZderMind wrote:
> In order to be able to drop the EOS-Event you could use a Pad-Probe
> (https://gstreamer.freedesktop.org/documentation/design/probes.htm).
> See here for an example how this could be done in python:
> https://github.com/voc/voctomix/blob/master/example-scripts/gstreamer/source-nostream-music-from-folder.py#L155-L164

I do that now. With the exception that tcpserversrc.src is a static pad
and so it's easier to set up the probe.

> In
> https://github.com/voc/voctomix/blob/master/example-scripts/gstreamer/source-nostream-music-from-folder.py#L170-L172
> I stopped and restarted only a single Element of the Pipeline (here: an
> uridecodebin). The same should be possible with a tcpseversrc.

I tried that but when I try to reconnect ffmpeg via TCP I get a short
connection:

--
av_interleaved_write_frame(): Broken pipe
Error writing trailer of tcp://localhost:10000: Broken pipe
frame=    2 fps=0.0 q=-0.0 Lsize=       1kB time=00:00:00.58 bitrate=
15.7kbits/s speed=14.5x
video:6075kB audio:109kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown
Conversion failed!
--

On the gstreamer side the demux is getting crazy about the stream:

--
DEBUG TCPAVSource[cam1]: scheduling source restart and dropping EOS
DEBUG TCPAVSource[cam1]: restarting source 'cam1'
DEBUG TCPAVSource[cam1]: scheduling source restart and dropping EOS
ERROR Pipeline: Received Error-Signal on Source-Pipeline
DEBUG Pipeline: Error-Details: #9: matroska-demux.c(4383):
gst_matroska_demux_check_read_size ():
/GstPipeline:pipeline0/GstBin:TCPAVSource-cam1/GstMatroskaDemux:demux-cam1:
reading large block of size 4294967295 not supported; file might be corrupt.
--

Seems that I have to re-initialize that too.

I already tried to pass the EOS signal to inform the demux about that
the stream ends but this lead to no effect.

Do I have to create the right Bin arround tcpserversrc and demux? I'm
currently testing this but no breakthrough until now.

Reconnecting is still a problem.

--
regards, fightling.

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

[MaZderMind]

Hi

Am 20.02.19 um 17:28 schrieb fightling:

> On the gstreamer side the demux is getting crazy about the stream:
>
> --
> DEBUG TCPAVSource[cam1]: scheduling source restart and dropping EOS
> DEBUG TCPAVSource[cam1]: restarting source 'cam1'
> DEBUG TCPAVSource[cam1]: scheduling source restart and dropping EOS
> ERROR Pipeline: Received Error-Signal on Source-Pipeline
> DEBUG Pipeline: Error-Details: #9: matroska-demux.c(4383):
> gst_matroska_demux_check_read_size ():
> /GstPipeline:pipeline0/GstBin:TCPAVSource-cam1/GstMatroskaDemux:demux-cam1:
> reading large block of size 4294967295 not supported; file might be corrupt.

Nice, that's one step further.

> Seems that I have to re-initialize that too.Yes, probably.

> I already tried to pass the EOS signal to inform the demux about that
> the stream ends but this lead to no effect.
>
> Do I have to create the right Bin arround tcpserversrc and demux? I'm
> currently testing this but no breakthrough until now.
Maybe it is enough to also bring the demux-element down to READY and
back up to PLAYING?

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

[fightling]

On 20.02.19 17:36, MaZderMind wrote:
> Maybe it is enough to also bring the demux-element down to READY and
> back up to PLAYING?

Like this?

--
        self.tcpsrc.set_state(Gst.State.READY)
        self.demux.set_state(Gst.State.READY)
        self.demux.set_state(Gst.State.PLAYING)
--

This ends up in:

--
   DEBUG TCPAVSource[cam1]: demuxer added pad w/ caps: audio/x-raw,
format=(string)S16LE, layout=(string)interleaved,
channel-mask=(bitmask)0x0000000000000003, channels=(int)2, rate=(int)48000
   DEBUG TCPAVSource[cam1]: new demuxer-pad is an audio-pad, testing
against configured audio-caps

DEBUG Pipeline: Error-Details: #1: gstbasesrc.c(3055): gst_base_src_loop
():
/GstPipeline:pipeline0/GstBin:TCPAVSource-cam1/GstTCPServerSrc:tcpsrc-cam1:
streaming stopped, reason not-linked (-1)
--

Seems that I have to re-link tcpserversrc.

--
regards, fightling.

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