Requesting a new tee's src pad temporary pauses the pipeline

[sebasgre]

Hello!

I have been working on this c program for the past weeks and even tho I have learned a lot, I have been hitting a wall lately, and I really cant solve this problem with tee.

So my idea is to have a running pipeline, and on demand add sinks to the app. For what I have been reading around this should be done something like this.

mysrc -> tee -> queue -> fakesink

So when I want to add a new sink, I simply have to request a src_% pad to the tee, connect it to my new bin, in case should be something like this:

tee -> [queue -> flvmux -> rtmpsink ] ([] is a bin I have created)

I have simplified the pipeline to make it easier to explain, but I have been working with different possibilities (having the flvmux placed before the tee for example, and using only one tee, and now I changed to having one tee for audio and another for video and then adding it to the flvmux inside my bin)

The problem is all seems to be working, but when looking at the endpoint (in this case youtube live) I can't see any image even if it says it's receiving data... just weird.

So looking at my debug output, I can see that my pipeline is passing to PAUSED state right after requesting the src pads to the tee. And then after all is elements are in play state, the pipeline changes to PLAYING again. So I'm wondering if that's normal and if it should be like that.

Some code:

Example of how I add the fake sink to a tee:

GstElement *audioFakesink = gst_element_factory_make("fakesink", "main-audio-fakesink");
GstElement *Aqueue = gst_element_factory_make("queue", "fakeAQueue");
mainAudioTee = gst_element_factory_make("tee", "mainAudioTee");
gst_bin_add_many (GST_BIN (pipeline), webrtcbin, mainAudioTee, mainVideoTee, Aqueue, Vqueue,audioFakesink, videoFakesink, NULL);

gst_element_link ( Aqueue, audioFakesink);

GstPad *queueAudioPad = gst_element_get_static_pad (Aqueue, "sink");
g_assert_nonnull (queueAudioPad);

GstPadTemplate *templ = gst_element_class_get_pad_template (GST_ELEMENT_GET_CLASS (mainAudioTee), "src_%u");
GstPad *teeAudioSrcPad = gst_element_request_pad (mainAudioTee, templ, NULL, NULL);
g_assert_nonnull (teeAudioSrcPad);

ret = gst_pad_link (teeAudioSrcPad, queueAudioPad);
g_assert_cmpint (ret, ==, GST_PAD_LINK_OK);

Example of how I add a new source

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

[Tim Müller]

On Sat, 2018-11-24 at 00:57 +0100, Sebastian Greco wrote:

Hi Sebastian,

I admit I only skim-read your post so apologies if I missed something,
but the reason the pipeline temporarily loses its PLAYING state is
likely the addition of the new sink (and setting its state to PAUSED or
PLAYING), not the requesting of the tee pad.

You may want to set the "async" property on the sink to FALSE before
adding it to the already-running pipeline to prevent this.

Cheers
 Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

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

[sebasgre]

Hi Tim!
well even tho you skim-read it you actually hit the problem at the first
try! haha once I put async to false the pipeline continued in PLAYING state.

I'm still having a problem on myt rtmp sink I guess, because I'm not getting
any valid data on the other side... I guess I will have to use some rtmp
server that tells me in more detail what is going on there.

Anyway! that's a problem for another week of debugging ahah

thanks a lot... I need to go to read the doc to know why that changed the
behavior.

Again! Thanks a lot, you saved me tons of hours of headache!

Cheers!



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