Android Stream To Live Stream Receiver

Yes - but there are two separate issues here:

1. Mobile browser camera permissions / secure context
2. Stream quality settings for lower latency

1) Android/iPhone camera access in a browser

The error:

getUserMedia must be used in a secure context

means the phone browser is refusing camera access because the page is not being served over HTTPS or localhost. Mobile browsers are much stricter about this than desktop Chrome.

What that means in practice

• Desktop Chrome may allow the stream page to work over plain HTTP on your LAN.
• Android Chrome and especially iPhone Safari often require:
  • https://... with a valid certificate, or
  • localhost only

So if the Live Stream Receiver is being opened from a normal local IP like:

http://192.168.x.x:port

the phone may connect to the page but still block the camera, which matches what you’re seeing: connected client, frozen frame, or no frames.

Recommended workaround

Use a secure tunnel or reverse proxy that provides HTTPS to the phone, or access ARC through a secure remote method.

A supported option to consider is ARC Remote Access Service if your goal is to operate ARC remotely:

• https://synthiam.com/Support/ARC-Overview/Options-Menu/remote-access-sharing

That will give you a much more reliable remote-control path than trying to force mobile browsers into an insecure camera flow.

2) Can you force 640x480 @ 15 fps?

With Live Stream Receiver, there is not typically a user-exposed parameter in ARC to request a specific resolution/FPS from the mobile browser camera like 640x480@15. The browser decides what it can provide, and the control/stream pipeline decides what it can accept.

So if you want lower latency, the proven approach is:

• use a device/browser combo that supports the camera pipeline cleanly
• reduce the camera source load if the skill exposes settings
• keep the stream local and secure
• or avoid browser-based phone camera capture altogether

If your real goal is "drive Roli from another room using a phone as the camera and controller", the better ARC-native path is usually:

• Live Stream Receiver for camera only
• Custom UI or movement skill buttons/joystick for driving
• access it through a secure remote method

Important ARC best practice

For Roli Rover, the track drive should stay on the Continuous servo Movement Panel only if your tracks are actually continuous servos.
If they’re the standard Roli H-bridge tread motors, the better/standard skill is the Hbridge Movement Panel using:

• D0 = left PWM
• D1/D2 = left direction
• D4/D5 = right direction/PWM depending on your wiring layout

Since you said your two Continuous servo skills are working, I assume your robot is configured that way, but I want to make sure you’re using the correct drive skill for the actual hardware.

What I’d try next

1. Confirm the phone is opening the stream over HTTPS
2. Test with Chrome on Android first; Safari is often more restrictive
3. In ARC, inspect the Live Stream Receiver kebab menu / settings to see whether there are any camera constraints available
4. If you need true remote operation, use Remote Access Service instead of relying on the phone browser as the camera transport
5. If your end goal is low-latency teleop, consider a Custom UI with a camera panel and joystick rather than browser camera streaming directly

Question for you

What is the bigger goal here - are you trying to:

• use the phone itself as the camera on the robot, or
• view ARC remotely from the phone while the robot camera stays on the EZ-B v4?

Those are very different setups, and I can point you to the best ARC skill combination once I know which one you want.