gst-rtsp-server shared media when client is requesting separate RTSP sessions for audio and video streams

[Mihael Brenko]

Hi all,

 

I’ve encountered an issue when testing our gst-rtsp-server based implementation with one VMS.

We have an audio/video pipeline in gst-rtsp-server, and the GstRTSPMediaFactory is configured to be shared.

This is working fine with majority of clients which receive both audio and video streams when doing RTSP requests.

However, one VMS client is doing separate RTSP sessions for getting audio and video streams using the same URL.

So instead of doing this:

1. DESCRIBE /media
2. SETUP /media/stream=0
3. SETUP /media/stream=1
4. PLAY /media

It does this:

1. First session DESCRIBE /media
2. First session SETUP /media/stream=0
3. First session PLAY /media
4. Second session DESCRIBE /media
5. Second session SETUP /media/stream=1
6. Second session PLAY /media

And the end results is that it will only receive audio or video (based on which SETUP request comes first).

If we set the GstRTSPMediaFactory shared property to false, then the problematic VMS receives both audio and video.

Also, if GstRTSPMediaFactory shared property is true and we start the audio and video stream using some other client which behaves ok, as long as those streams are left open the problematic VMS will manage to establish both audio and video streams.

From my perspective this looks like some kind of problem with shared media.

My question is, is there some additional handling we need to do in case when we use shared media and we want to support the use case where RTSP clients can request only video or only audio stream with it?

Or can this be considered a bug?

 

Regards,

MIHAEL BRENKO
TEAM LEADER / DEVELOPMENT ENGINEER
ZENITEL

Tel: [phone]
[hidden email]

ZENITEL MARINE MED. OFFICE

PERMANI 28, HR-HR-51213 Jurdani, Croatia
Switchboard: [phone], Fax: [phone]
www.zenitel.com

Newsletter | LinkedIn | Facebook | Twitter

DISCLAIMER:
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
No employee of Zenitel has the authority to conclude via e-mail any binding contract without an explicit written consent of their supervisor, and Zenitel does not take responsibility for it’s content, and will not enter into an agreement, without this written consent.

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