Unable to see UDP stream in Firefox

353 views
Skip to first unread message

ex

unread,
Jul 20, 2017, 10:01:24 AM7/20/17
to meetecho-janus
Hi, I'm trying to directly broadcast a audio/video stream sent to my computer through the UDP port 1203. 

I was able to view the stream when I use FFmpeg or GStreamer to loop it to an RTP port 5004 with a command similar to: 
ffmpeg -i udp://@:1203?fifo_size=1000000 -map 0:0 -an -c:v libvpx -deadline realtime -f rtp rtp://10.40.3.20:5004

This worked when my stream configuration is
[livestream test]
type = rtp
id = 1
description = livestream test
audio = no
video = yes
videoport = 5004
videopt = 126
videortpmap = VP8/90000

However, having this extra FFmpeg process is tough on the CPU, so I want to be able to broadcast the stream from port 1203 directly. Right now I'm just trying to get the video to work, and the stream is encoded as h.264. The following stream configuration does not work:

[livestream test]
type = rtp
id = 1
description = livestream test
audio = no
video = yes
videoport = 1203
videopt = 126
videortpmap = H264/90000
videofmtp = profile-level-id=42e01f\;packetization-mode=1

When I start Janus, it logs that it is getting a new video stream, although it repeats this many many times. When I try to start the stream, I get this error: 
[ERR] [ice.c:janus_ice_send_thread:3572] [4504163381813386] Got 6399 SRTP/SRTCP errors in the last few seconds (last error: err_status_replay_old)

Thank you for any information you can provide.

Lorenzo Miniero

unread,
Jul 20, 2017, 10:04:12 AM7/20/17
to meetecho-janus
The RTP you're sending is invalid, possibly repeating SSRC+timestamp+seqnumber combinations, and that breaks the SRTP encryption as it seen as a replay which is not allowed for security reasons. FFmpeg probably fixes those for you before sending them to Janus.

L.

Lorenzo Miniero

unread,
Jul 20, 2017, 10:04:53 AM7/20/17
to meetecho-janus
Or actually, maybe you're not sending RTP at all, but raw frames? That won't work: the Streaming plugin needs RTP packets.

L.

ex

unread,
Jul 20, 2017, 10:17:23 AM7/20/17
to meetecho-janus
I see, that was my main question, whether the plugin required RTP packets. In other words I would have to repackage it and bind to another port? Can you offer some options for computationally cheap ways to do this?

Thank you for you help.

Lorenzo Miniero

unread,
Jul 20, 2017, 10:31:15 AM7/20/17
to meetecho-janus
Is the stream you get on port 1023 already encoded (e.g., vp8 or h264) or raw frames? If it's raw frames, then just RTP won't help you, as you'll still need something to encode the frames to something the browser can decode. If it's encoded already, both Ffmpeg and Gstreamer (and I guess others) have ways to just pass the frames along, and only split and packetize RTP. Can't remember the exact commands/flags (someone else might, especially in the respective communities), but it is possible.

L.

ex

unread,
Jul 20, 2017, 11:08:59 AM7/20/17
to meetecho-janus
The frames are encoded to h264 already, I was wondering if there was a way to eliminate the extra step of processing it using FFmpeg/Gstreamer, I suppose not?

Lorenzo Miniero

unread,
Jul 20, 2017, 11:13:15 AM7/20/17
to meetecho-janus
If by processing you mean transcoding, yes. As I said, both tools allow you to handle an encoded stream and only packetize it in RTP and restream via UDP. That's a very lightweight process, so I wouldn't worry of the load that extra step would add. Check this example to see, for instance, how Gstreamer can use h264parse and rtph264pay to do something like this: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=44675
Anyway, I'm not an expert on this, so you may want to do your own research on the proper ways about how these tools can help you achieve this.

L.
Reply all
Reply to author
Forward
0 new messages