trying to get tee working

[Marc]

Hi Marianna,

You are a life saver! ;)

> 
> strsink has a property called "wait-for-connection" (Block the stream
> until a client connects) which is by default true.
> 
>    wait-for-connection : Block the stream until a client connects
>                          flags: læselig, som kan skrives
>                          Boolean. Default: true

Yes I was not realizing this. I guess this is related to the clock that streams are bound to. (not that the sync=false helped me)

> So when you have a tee before strsink it gets full (because srtsink is
> not consuming any buffers).
> 
> Setting it to leaky makes it drop buffers. leaky=1 means drop new
> buffers, leaky=2 means drop old buffers.
> 
> In my pipelines I normally use leaky=2 because then I have a change to
> "catch up".
> 

> 
> Now when I add your demux branch I can see it doesn't work, it seems
> stalled (clock doesn't run, event though it should since
> wait-for-connection=false).
> 
> Making the queues leaky or not didn't make any difference for me.
> 
> And I could see that if I had a tee with a single branch it worked
> (clock runs). But as soon as I add a second branch (even if it is only a
> fakesink) it stalls.

This for me seems to work with one client and with two clients.

gst-launch-1.0 srtsrc uri=srt://:55555?mode=listener passphrase='xxxxxx' ! tee name=t \
    t. ! queue ! srtsink uri=srt://:33333 wait-for-connection=false  \
    t. ! queue ! tsdemux ! video/x-h264 ! h264parse ! mpegtsmux name=mux ! tsparse ! srtsink uri=srt://:33334 wait-for-connection=false

> 
> I played around with settings and found out that making srtsink async=0
> got it to work (No idea why...):

I will make a note of this. I have seen this in other postings as well. So if my source stream changes and I start running into problems, I will give this a try.

> gst-launch-1.0 -vv srtsrc uri=srt://10.10.150.36:5555 ! tee name=t !
> queue \
> 
> ! tsdemux ! h264parse ! mpegtsmux name=mux ! tsparse ! srtsink
> uri=srt://:33334 wait-for-connection=false async=0 \
> 
> t. ! queue ! srtsink uri=srt://:33333 wait-for-connection=false async=0
> --gst-debug=*:3
> 
> 
> And if I look at the debug messages from this pipeline I get about 8
> seconds of this:
> 
> 0:00:08.359881732 25752 0x55c43fab5d20 WARN h264parse
> gsth264parse.c:1490:gst_h264_parse_handle_frame:<h264parse0>
> broken/invalid nal Type: 1 Slice, Size: 6139 will be dropped
> 
> Which explains why it takes ~9seconds for the images to show.
> 
> Why this is happening I don't know...
> 

With this above pipeline with the added wait-for-connection=false, I do not really have this 9s any more luckily. Thanks for these pointers!!! Now I going to try and see if I can archive such a stream on s3 compatible storage.