Pushing WebRTC WHIP stream from outside application

[wizenink]

Hello. I'm trying to test the WHIP ingestion option using GStreamer's whipsink.
Checking the network request on the "publish" HTML example, I found that a request to "http://{IP}:{WEBRTC_PORT}/{STREAM_NAME}/whip" is made, using video_codec,audio_codec and video_bitrate parameters.
To test the behaviour, I used the following GStreamer line:
gst-launch-1.0 videotestsrc ! "video/x-raw,size=1920x1080,rate=30" ! videoconvert ! queue ! vp8enc ! rtpvp8pay pt=96 ssrc=2 ! queue ! "application/x-rtp,media=video,encoding-name=VP8,payload=96,clock-rate=90000" ! whipsink whip-endpoint="http://127.0.0.1:8889/streamtest/whip"

I also tried specifiying video_codec,audio_codec and video_bitrate:

gst-launch-1.0 videotestsrc ! "video/x-raw,size=1920x1080,rate=30" ! videoconvert ! queue ! vp8enc ! rtpvp8pay pt=96 ssrc=2 ! queue ! "application/x-rtp,media=video,encoding-name=VP8,payload=96,clock-rate=90000" ! whipsink whip-endpoint="http://127.0.0.1:8889/streamtest/whip?video_codec=h264&audio_codec=none&video_bitrate=10000"

With both of this lines, I get an error 400 from mediamtx. Checking the logs, this shows up:

`
2023/05/23 20:46:43 DEB [WebRTC] [conn 127.0.0.1:42850] POST /streamtest/whip
2023/05/23 20:46:43 DEB [WebRTC] [conn 127.0.0.1:42850] [c->s] POST /streamtest/whip HTTP/1.1
Host: 127.0.0.1:8889
Accept: /
Accept-Encoding: gzip
Content-Length: 1141
Content-Type: application/sdp

v=0
o=- 6837086830670301623 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
a=group:BUNDLE video0
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:DCVz4gG4cvrEfdD/YrvaLpCBt8AY0mAV
a=ice-pwd:TDOT9d73DPgazrKQKBJYD5ZVZ35V17Vp
a=rtcp-mux
a=rtcp-rsize
a=sendonly
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 transport-cc
a=framerate:30
a=ssrc:2 msid:user891105581@host-14ea3e30 webrtctransceiver0
a=ssrc:2 cname:user891105581@host-14ea3e30
a=mid:video0
a=fingerprint:sha-256 CE:14:AA:C3:0A:85:CF:7C:1A:AF:27:28:6F:8C:E0:AC:C8:12:CF:97:E6:7F:1B:B3:34:D5:2A:06:24:66:34:89
a=rtcp-mux-only
a=candidate:1 1 UDP 2015363327 192.168.1.128 43337 typ host
a=candidate:2 1 TCP 1015021823 192.168.1.128 9 typ host tcptype active
a=candidate:3 1 TCP 1010827519 192.168.1.128 36597 typ host tcptype passive
a=candidate:4 1 UDP 2015363583 fe80::979:5011:d5bf:6422 54646 typ host
a=candidate:5 1 TCP 1015022079 fe80::979:5011:d5bf:6422 9 typ host tcptype active
a=candidate:6 1 TCP 1010827775 fe80::979:5011:d5bf:6422 37577 typ host tcptype passive
a=end-of-candidates

2023/05/23 20:46:43 INF [WebRTC] [session 8da363c2] created by 127.0.0.1
2023/05/23 20:46:43 DEB [path streamtest] created
2023/05/23 20:46:43 DEB [path streamtest] destroyed (not in use)
2023/05/23 20:46:43 INF [WebRTC] [session 8da363c2] closed (invalid character 'v' looking for beginning of value)
2023/05/23 20:46:43 DEB [WebRTC] [conn 127.0.0.1:42850] [s->c] HTTP/1.1 400 Bad Request
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Server: mediamtx
`

It seems like the parser is finding an 'v' character where it should not be present, I'm assuming on the SDP offer, in the first line, v=0.

Any clue?

[aler9]

Hello, i checked the code and it seems that WHIP is not implemented correctly: the server expects the WebRTC offer to be in JSON format, while it should be in raw format. This will be fixed ASAP.

[aler9]

This is fixed by #1861. You also need to remove video_codec, audio_codec and video_bitrate from the query, since they are needed by browsers only and have no effect on GStreamer:

gst-launch-1.0 videotestsrc ! "video/x-raw,size=1920x1080,rate=30" \
! videoconvert ! queue ! vp8enc ! rtpvp8pay pt=96 ssrc=2 \
! queue ! "application/x-rtp,media=video,encoding-name=VP8,payload=96,clock-rate=90000" \
! whipsink whip-endpoint="http://127.0.0.1:8889/streamtest/whip"

[bluenviron-bot]

This discussion is being locked automatically because the last update was more than 2 years ago.

Do not use the content of this discussion as reference since it's probably outdated!

The official documentation is the only place in which you can find up-to-date answers.