After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759862 - Input selector hangs with tee element and live rtspsrc
Input selector hangs with tee element and live rtspsrc
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-25 15:25 UTC by Tapas Kumar Kundu
Modified: 2018-11-03 13:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dummy program to reproduce this bug easily (23.42 KB, text/plain)
2015-12-25 15:25 UTC, Tapas Kumar Kundu
Details
logs collected with GST_DEBUG=4 for dummy test program. (2.38 MB, application/msword)
2015-12-28 16:57 UTC, Tapas Kumar Kundu
Details

Description Tapas Kumar Kundu 2015-12-25 15:25:39 UTC
Created attachment 317876 [details]
dummy program to reproduce this bug easily

Steps to reproduce:

write a program for pipeline like

audio rtspsrc ----------------------->|
                                      |                             |--->live_queue-->rtmpsink
ip cam1 --------->|                   |-flvmux-->mixing_queue->tee--|
ip cam2 --------->|                   |                             |--->record_queue-->fakesink
ip cam3 --------->|--inputselector--->|
ip cam4 --------->|
ip cam5 --------->|



It always hangs after switching ip cameras for 2-3 times. 
Error message comes as "RTMP send error". Please note that we are using rtmpsink with sync=true and async=true. 

However, The pipeline works in following cases:

1) if I don't use "tee" and connect mixing_queue to rtmpsink directly then pipeline works fine. 
2) if replace rtmpsink with filesink and fakesink with shmsrc in above pipeline then it works fine. 

I attached a dummy program which can help you to reproduce this bug on your side.
Comment 1 Tapas Kumar Kundu 2015-12-25 15:28:11 UTC
Marking it as blocker because this cause tee element to be unusable with rtmpsink and input-selector.
Comment 2 Tapas Kumar Kundu 2015-12-25 15:47:42 UTC
audio
rtspsrc -------------------->|
                             |                      
ip cam1 -->|                 |->flvmux->queue->tee->|->queue->rtmpsink
ip cam2 -->|                 |                      |->queue->fakesink      
ip cam3 -->|--inputselector->|
ip cam4 -->|  
ip cam5 -->|



Comment #1 has some text issue with pipeline diagram . So I am writing it again
Comment 3 Tapas Kumar Kundu 2015-12-25 15:50:37 UTC
(In reply to Tapas Kumar Kundu from comment #0)

> However, The pipeline works in following cases:
> 
> 1) if I don't use "tee" and connect mixing_queue to rtmpsink directly then
> pipeline works fine. 
> 2) if replace rtmpsink with filesink and fakesink with shmsrc in above
> pipeline then it works fine. 
  3) New case: It doesn't happen even with both rtmpsink and fakesink if I don't change active pad of input-selector element. 
> 
> I attached a dummy program which can help you to reproduce this bug on your
> side.
Comment 4 Sebastian Dröge (slomo) 2015-12-26 10:52:43 UTC
Does it even work without a tee and rtmpsink when changing the active pad of the input-selector a lot of times?

My guess is that the problem here is that input-selector produces discontinuous output... and RTMP is very picky about such things. Also you will likely have to re-encode the video (with a single encoder for all streams) as RTMP also does not like changes of the video codec parameters in the middle of the stream.
Comment 5 Tapas Kumar Kundu 2015-12-26 14:57:25 UTC
(In reply to Sebastian Dröge (slomo) from comment #4)
> Does it even work without a tee and rtmpsink when changing the active pad of
> the input-selector a lot of times?
> 
Yes. It works fine.

> RTMP also does not like changes of the video codec parameters in
> the middle of the stream.

There is no change of codec params in the middle of streaming although we are switching cameras. All camera has same model and they are sending same format of video with same bitrates.
Comment 6 Tapas Kumar Kundu 2015-12-26 15:01:18 UTC
(In reply to Sebastian Dröge (slomo) from comment #4)
> Does it even work without a tee and rtmpsink when changing the active pad of
> the input-selector a lot of times?
> 


You can refer to my comment #3 for the use cases where it works fine. I tested it for 2 hours for each case.
Comment 7 Sebastian Dröge (slomo) 2015-12-28 08:38:29 UTC
Do you get any errors from rtmpsink or librtmp? Or can you confirm that data flow just stops somewhere in GStreamer for whatever reason?

It's non-trivial to reproduce this without having your setup, even if you provided a testcase.
Comment 8 Tapas Kumar Kundu 2015-12-28 16:57:23 UTC
Created attachment 317973 [details]
logs collected with GST_DEBUG=4 for dummy test program.

(In reply to Sebastian Dröge (slomo) from comment #7)
> Do you get any errors from rtmpsink or librtmp? Or can you confirm that data
> flow just stops somewhere in GStreamer for whatever reason?
> 
> It's non-trivial to reproduce this without having your setup, even if you
> provided a testcase.


Here is the error log with GST_DEBUG=4. 

You can search for "startcam" to see exact line where camera switch happened.
Comment 9 GStreamer system administrator 2018-11-03 13:44:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/340.