Hacker News Reader

Comment by peterangular | Hacker News Reader

Having to look into this professionally for local/remote streaming solutions and came across this paper in the last couple of weeks which has been a huge help to understanding my use case:

http://lup.lub.lu.se/luur/download?func=downloadFile&recordO...

One of the most useful/interesting use cases to me is the ability to have a PTP encrypted stream without having to go through weird IoT PKI hoops.

Ninja edit: If anyone has experience with Janus and/or WebRTC on edge devices I would very much like to talk as I could really use a solid consultant in this realm.

View on HN

I do WebRTC on Edge/IoT devices (mostly MIPS/ARM devices running Linux). Customers are mostly teleoperations (robotics) and security cameras.

Most customers run an MCU/SFU on a server, but then just a WebRTC client on the device. We do simulcast on the device to an SFU, and then distribute from there. Happy to answer questions here or directly.

I don't want to be disrespectful and sell other stuff on this thread though. I like seeing people realize how great Janus is :) don't want to distract from that conversation!

I'm concerned in targeting things like Janus etc to the MIPS architecture for streaming over WebRTC because typically I only see MIPS on legacy devices in my world. How does MIPS handle this stuff?

PS: I know that Amazon has a product in the space and we're vetting AWS as our cloud provider due to it's diverse product offering. I've been looking at opensource solutions due to vendor lock-in but would love to hear if you have any experience with the Amazon offering!

I wrote the Amazon offering! By design I implemented the same PeerConnection API, I really didn't want their to be vendor lock-in. I included a 'signaling client' in-tree, but you can do your own easily. The end goal is to get that AWS implementation running on 'true' embedded devices. We are going to switch to mbedtls soon, and we are working on getting it on FreeRTOS.

I also wrote Pion WebRTC, the Amazon offering is just a re-implementation of that in C. Just trying to decouple media pipelines and transport. I think WebRTC is a really great protocol, hopefully we can get software to match it :)

MIPS is still alive in the IP camera world. There exist very cheap SoC's (e.g. the Ingenic T20 - http://www.ingenic.com.cn/en/?product/id/14.html ), tailored towards making cheap network camera's (~ €20 retail price for the full camera). I guess at that price point, the ARM license fee does become visible in the bill of materials.

Incidentally the Allwinner F1C100s used in this business card (https://www.thirtythreeforty.net/posts/2019/12/my-business-c..., https://news.ycombinator.com/item?id=21871026) contains an ARM9 series core clocked at 900MHz alongside 32MB of on-die DDR1, is designed for dashcam-type applications (SDIO, LCD, USB2 OTG, no PHY) and the author of the linked article was able to buy them for $1.42 each.

I've long been curious about MIPS from a hobbyist/tinkerer/maker perspective and would be very interested to know what silicon I might select at a similar price point.

Are there resources you might recommend on using WebRTC for the teleoperations use case?

BTW, here's the best I found so far (in terms of how simple it makes everything):

https://pypi.org/project/rtcbot/

If you are interested in cross-compiling the WebRTC implementation so it runs directly from within edge devices, Janus might be one of the best options out there.

Kurento offers a variety of features apart from WebRTC, but it is more intended to be cloud-deployed as an independent media server, you could think of it as a "proxy/bridge" that distributes media between producers (like RTSP cameras) and consumers (WebRTC clients).

If those features are not needed, for purely WebRTC routing there's also mediasoup, with the same philosophy: N media producers send video to a central server, and the server distributes it to M devices consuming the media.

True peer-to-peer comms (i.e. sending data directly from producers to consumers, without an intermediate centralized server) was a cool thing to aim for by the WebRTC standard, but real-world practical constraints (i.e. bandwidth) put a limit to the usefulness of a truly p2p architecture. You'll find more info about this searching for MCU and SFU.

I've been vetting solutions in the space and I think I have a need for both...

I'm having a hard time figuring out direct streaming from device on your local LAN without having to go out/back-in through the public internet with a hard requirement of an encrypted "point-to-point" communication (ie: can't listen into streams) which is browser trusted + the ability to ship that out to a "proxy/bridge" media server solution like you describe.

I've looked at EvoStream and Wowza as licensed solutions and I am super interested in the ability to use something like Kurento with ideally self-signed certificates to a cloud-deployed/redundant media bridge that then in-turn broadcasts to the remote clients who are consuming via the public internet.

The OpenCV tie-in with Kurento would be of great interest to me as well. That could be a game changer for what I'm currently embarking on!

Would a hybrid approach make sense to you as you're definitely an expert in this space? (ie: using Janus on-edge and Kurento in the cloud at the same time)

PS: I apologize if my questions/communication is rough... I'm two weeks into a nightmare trying to sort all of this out so I'm still coming up-to-speed on the technical details of WebRTC + secure streaming!

You can deploy Kurento (or Janus itself, for that matter!) inside a subnet of the LAN, to act as a media bridge. Then, if the security group / firewall / whatever is configured so it allows the media bridge public network access, then it could be used to send the data directly to remote peers.

This however would have the bridge in the middle of LAN connections, so it wouldn't be a point-to-point flow, and the server would be able to "see" data passing through it.

There is however some new work on what's called "insertable streams" in Janus, which would allow e2e encryption directly between sender and receiver, thus having the media bridge purely act as a "blind" router, not being able to see the streams passed through it.

Janus has some very recent support for this [0], while this is (for now at least) not standardized and out of scope for Kurento.

[0]: https://www.meetecho.com/blog/janus-e2ee-sframe/

I’ve also tried to setup Kurento and Janus and Janus is 100000000000% easier

The Google's WebRTC Native is a good option too. It's basically a piece of the Chrome browser.

Out of curiousity: What is an edge device? An IP camera? Depending on the professional grade of your use case, you could directly talk to meetecho, as they are the original developers and offer consultancy around Janus.

IP cameras mostly, some remote-audio stuff - I think that may be a logical next step for me so I'm going to bring that up to leadership tomorrow.

I used Janus to map my IP camera's stream to a WebRTC page using a Raspberry Pi's hardware transcoder. It works quite well.

I'd be super interested in seeing what you've got! Is your implementation posted anywhere?

I really like your Stylus project btw!

There's two parts to the implementation. First part is a docker container that will transcode a stream for Janus using the hardware on the Pi:

https://github.com/mmastrac/gst-omx-rpi-docker

I run this with the following config (just remember to map the RPi /dev/vchiq device into the container!):

  gst-launch-1.0 rtspsrc location="rtsp://admin:(password)@(host):554/cam/realmonitor?channel=1&subtype=0" latency=500 ! rtph264depay ! h264parse ! omxh264dec ! omxh264enc target-bitrate=500000 control-rate=1 ! video/x-h264, profile=baseline ! h264parse ! rtph264pay name=pay0 config-interval=1 pt=96 ! udpsink host=(janus) port=8004 sync=false

The second part is the Janus configuration magic that creates the appropriate stream:

  [gstreamer-sample]
  type = rtp
  id = 1
  audio = no
  video = yes
  videoport = 8004
  videopt = 96
  videortpmap = H264/90000
  videofmtp = profile-level-id=42E01F\;packetization-mode=1\;level-asymmetry-allowed=1
  videobufferkf = yes

> I really like your Stylus project btw!

Thanks! Been working on Stylus a bit more this weekend. Nearly have all the features I need for my own setup.

Reply on news.ycombinator.com