H.264 RTSP test stream over udpsink & udpsrc

[Rafał Kozik]

Hi,

I am working on displaying a H.264 RTSP stream in Chrome. It works very well when I use a test stream generated by gst-rtsp-server

gst-rtsp-launch -p 8558 "videotestsrc ! x264enc aud=false ! rtph264pay name=pay0"

and this Janus  configuration:

[rtsp-test]

type = rtsp

id = 99

description = RTSP Test

audio = no

video = yes

url=rtsp://localhost:8558/test

However, finally I will have an RTP stream sent to the RTSP server. So I wanted to test it with the following commands:

gst-launch-1.0 -v videotestsrc ! x264enc aud=false ! rtph264pay ! udpsink host=127.0.0.1 port=5001

gst-rtsp-launch -p 8558 "( udpsrc name=pay0 port=5001 caps=\"application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=96\" )"

But it doesn't work. Janus server doesn't show any warnings, just "WebRTC media is now available". Chrome console doesn't display any warnings either. I can see in Wireshark that RTP stream is being sent from Janus server to the browser. So I compared SDPs received by Janus Javascript client. This one I got when everything was working ok:

v=0

o=- 1516196977147479 1 IN IP4 172.17.0.8

s=Mountpoint 131841

t=0 0

a=group:BUNDLE video

a=msid-semantic: WMS janus

m=video 9 UDP/TLS/RTP/SAVPF 96

c=IN IP4 172.17.0.8

a=sendonly

a=mid:video

a=rtcp-mux

a=ice-ufrag:P3d6

a=ice-pwd:holpSuZgvwdSHiIfSajgCx

a=ice-options:trickle

a=fingerprint:sha-256 D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38

a=setup:actpass

a=rtpmap:96 H264/90000

a=fmtp:96 packetization-mode=1;profile-level-id=42c015;sprop-parameter-sets=Z0LAFdkBQfsBagwCC0oAAAMAAgAAAwB5HixckA==,aMuMsg==

a=rtcp-fb:96 nack

a=rtcp-fb:96 goog-remb

a=ssrc:2640041175 cname:janusvideo

a=ssrc:2640041175 msid:janus janusv0

a=ssrc:2640041175 mslabel:janus

a=ssrc:2640041175 label:janusv0

a=candidate:1 1 udp 2013266431 172.17.0.8 59797 typ host

a=candidate:2 1 udp 2013266431 10.0.2.5 44970 typ host

a=end-of-candidates

And this one when I added udpsink and udpsrc:

v=0

o=- 1516197514486623 1 IN IP4 172.17.0.8

s=Mountpoint 131841

t=0 0

a=group:BUNDLE video

a=msid-semantic: WMS janus

m=video 9 UDP/TLS/RTP/SAVPF 96

c=IN IP4 172.17.0.8

a=sendonly

a=mid:video

a=rtcp-mux

a=ice-ufrag:eunW

a=ice-pwd:SqX4FdM0txn2AtX4kKwKJ0

a=ice-options:trickle

a=fingerprint:sha-256 D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38

a=setup:actpass

a=rtpmap:96 H264/90000

a=fmtp:96 

a=rtcp-fb:96 nack

a=rtcp-fb:96 goog-remb

a=ssrc:2011230882 cname:janusvideo

a=ssrc:2011230882 msid:janus janusv0

a=ssrc:2011230882 mslabel:janus

a=ssrc:2011230882 label:janusv0

a=candidate:1 1 udp 2013266431 172.17.0.8 44404 typ host

a=candidate:2 1 udp 2013266431 10.0.2.5 44647 typ host

a=end-of-candidates

I made differences bold. I think that only this difference matters: a=fmtp:96 vs a=fmtp:96 packetization-mode=1;profile-level-id=42c015;sprop-parameter-sets=Z0LAFdkBQfsBagwCC0oAAAMAAgAAAwB5HixckA==,aMuMsg==. So I created those commands to force those settings:

gst-launch-1.0 -v videotestsrc ! x264enc aud=false ! rtph264pay ! capssetter caps='application/x-rtp,packetization-mode=1,profile-level-id=42c015,sprop-parameter-sets="Z0LAFdkBQfsBagwCC0oAAAMAAgAAAwB5HixckA==,aMuMsg=="' ! udpsink host=127.0.0.1 port=5001

gst-rtsp-launch -p 8558 "( udpsrc name=pay0 port=5001 caps=\"application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=96, packetization-mode=1, profile-level-id=42c015, sprop-parameter-sets=\\\"Z0LAFdkBQfsBagwCC0oAAAMAAgAAAwB5HixckA\\\=\\\=\\\,aMuMsg\\\=\\\=\\\"\"\" )"

It got better, because now I can see at least some vertical green and black stripes. But it is not the stream I wanted, so I checked the SDP once again and packetization-mode=1 was still missing: a=fmtp:96 profile-level-id=42c015;sprop-parameter-sets=Z0LAFdkBQfsBagwCC0oAAAMAAgAAAwB5HixckA==,aMuMsg==. I am not sure if this missing packetization-mode=1 in the SDP is the root cause of the problem, but I don't have other ideas. I also tried other settings from this post https://github.com/meetecho/janus-gateway/issues/1123#issuecomment-355214342 but with no luck.

Can you help me with this problem?

Rafał

[Fabrizio Bertone]

Hi,

Do you have to send the rtp stream to the rtsp server?

Send the rtp stream directly to janus is not an option?

Fabrizio

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rafał Kozik]

I was thinking about it, then I could manually specify all parameters in Janus config file. But I work with a robot that has many video streams that are configured dynamically and it is much easier to manage simple RTSP urls than a bunch of stream parameters.

[Fabrizio Bertone]

What do you mean by many streams configured dinamically? Are they rtp or rtsp? Can you make some examples?

[Rafał Kozik]

For example, I get information from a robot that there is a rtsp://172.17.0.8:8001/camera stream available. Now I can add this stream as a new entry in Janus server configuration and start playing it in a browser. I don't need to know anything else about this stream, url is enough. If I used RTP only, I'd need to send more information from robot (profile-level-id, etc).

[Fabrizio Bertone]

Ok, so you already have rtsp that as you said works.

Why are you trying to send rtp to rtsp? It was just a test for curiosity or you have also this case?

I guess you have to set some parameters in gstreamer but I don’t know it so I can’t help with that.

In my experience I have solved some rtsp-related problems by putting an rtsp proxy (from live555 media) between the original source and janus but I don’t know if it will add a profile-id if it doesn’t find it in the first place.

[Lorenzo Miniero]

Profile-id can be overwritten by the Janus streaming plugin if you set the videofmtp property in the RTSP mountpoint.

L.

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Fabrizio Bertone]

Wow really?

I had to modify the js to change it in the SDP on the fly.

This would have been so much simpler!

Always something new to learn :D

[Rafał Kozik]

I found the reason - x264enc uses downstream plugins to set its profile (not obvious). In this case case 

gst-rtsp-launch -p 8558 "videotestsrc ! x264enc aud=false ! rtph264pay name=pay0"

RTSP server probably adds something to the pipeline that forces Baseline profile. If it is executed like this

gst-launch-1.0 -v videotestsrc ! x264enc aud=false ! rtph264pay ! udpsink host=127.0.0.1 port=5001

x264enc uses High profile, which is not supported by browsers. Those commands work fine:

gst-launch-1.0 -v videotestsrc ! x264enc aud=false ! video/x-h264, profile=baseline ! rtph264pay ! udpsink host=127.0.0.1 port=5001

gst-rtsp-launchh -p 8558 "( udpsrc name=pay0 port=5001 caps=\"application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=96, profile-level-id=428014\" )"

profile-level-id contains information about the profile: https://stackoverflow.com/questions/22960928/identify-h264-profile-and-level-from-profile-level-id-in-sdp

Rafał

[Fabrizio Bertone]

FYI it is usually safe to use a level of 3.0 (0x1e) or 3.1 (0x1f) => profile-level-id=42xx1f

but you should probably anyways enforce a level also in the encoder itself because you are only enforcing the profile baseline

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.