Beyond Localhost: Security, Authentication, and Real-World Sources

Note: This is part 2 of the series "Demystifying Real-Time Video: A Practical Guide to FFmpeg & MediaMTX"

Introduction: The Real World is Messy

In Part 1, we built something magical: a live webcam feed streaming directly to your browser with minimal latency. But let's be honest, what we created was a beautiful proof of concept that would make any security professional break out in cold sweats.

Our localhost setup has some glaring problems:

• Anyone can publish streams to our server
• Anyone can view any stream without authentication
• We're limited to simple sources like local webcams and files
• The whole system crumbles the moment we try to move beyond localhost

Real-world video streaming is messier than our pristine demo. IP cameras use different protocols, have quirky implementations, and often require authentication. Network conditions are unpredictable. Users need granular access controls, not master passwords. And everything needs to work reliably over the internet, not just your local machine.

In this article, we'll transform our localhost demo into a production-ready streaming service. We'll secure it properly, connect to real IP cameras with their various quirks, and prepare our pipeline for internet deployment. By the end, you'll have a robust foundation that can handle the chaos of real-world video streaming.

Ingesting Real-World Feeds: The Power of FFmpeg

Let's start by expanding our input sources beyond local webcams. In the real world, you'll encounter IP cameras, network video recorders (NVRs), and various streaming protocols that don't play nicely with browsers. This is where FFmpeg's versatility truly shines.

Handling IP Cameras

Most professional IP cameras expose RTSP streams that you can pull and re-stream through your MediaMTX server. This "re-streaming" pattern gives you complete control over the video pipeline, allowing you to normalize different formats, add authentication, and provide a consistent interface to your applications.

Here's how to connect to a typical IP camera:

# Generic IP camera with authentication ffmpeg -rtsp_transport tcp -i "rtsp://username:password@192.168.1.100:8080/stream" \ -c:v libx264 -preset medium -tune zerolatency \ -c:a aac -ar 44100 \ -f rtsp rtsp://localhost:8554/camera1

Let's break down the key parameters:

• -rtsp_transport tcp: Forces TCP instead of UDP for more reliable transmission over networks
• The input URL includes credentials and the camera's specific stream path
• We're encoding to H.264/AAC for maximum compatibility
• The output goes to our MediaMTX server on a specific path

Working with Public Camera Feeds

For testing purposes, you can use publicly available camera feeds. Many cities and organizations provide public RTSP streams:

ffmpeg -rtsp_transport tcp -i "{CAMERA RTSP URL}" \ -c:v copy -c:a copy \ -f rtsp rtsp://localhost:8554/traffic_cam

Side note: I found this app (https://apps.apple.com/vn/app/rtsp-stream/id6474928937) to help you turn your phone's camera into an RTSP stream that you can use here and for other tests.

Notice the -c:v copy -c:a copy flags. These tell FFmpeg to copy the streams without re-encoding, which saves CPU and reduces latency when the source is already in a suitable format.

Handling Quirky Formats: MJPEG and Beyond

Not all cameras speak proper RTSP. Some older or simpler cameras use MJPEG (Motion JPEG) over HTTP, which is essentially a stream of JPEG images. FFmpeg can normalize these into proper video streams:

ffmpeg -f mjpeg -i "http://77.222.181.11:8080/mjpg/video.mjpg" \ -c:v libx264 -preset ultrafast -tune zerolatency \ -r 25 -s 1280x720 \ -f rtsp rtsp://localhost:8554/test_video

Key parameters for MJPEG handling:

• -f mjpeg: Explicitly specify the input format
• -r 25: Set output frame rate (MJPEG streams often have variable rates)
• -s 1280x720: Standardize resolution across different cameras

The Re-Stream Architecture Pattern

This approach creates a powerful architectural pattern:

[IP Camera] --RTSP--> [FFmpeg Process] --RTSP--> [MediaMTX] --WebRTC--> [Browser]

Each camera gets its own FFmpeg process, which handles:

• Protocol conversion and normalization
• Authentication with the source camera
• Format standardization (resolution, frame rate, codecs)
• Error handling and reconnection logic
• Bandwidth optimization

This pattern scales well because each stream is isolated. If one camera fails or has issues, it doesn't affect the others.

A More Scalable Approach: MediaMTX Direct Sources

While the FFmpeg re-streaming pattern is powerful, there's an even more elegant approach for RTSP sources: We can let MediaMTX handle the connections directly. This eliminates the need to manage individual FFmpeg processes and provides better resource utilization and automatic error handling.

Instead of running separate FFmpeg processes, you can configure MediaMTX to pull streams directly from cameras:

paths: test_camera: source: {CAMERA RTSP URL} rtspTransport: automatic sourceOnDemand: yes # Only connect when someone is watching

This creates a much cleaner architecture:

[IP Camera] --RTSP--> [MediaMTX] --WebRTC--> [Browser]

Benefits of the direct source approach:

• Simplified Management: No FFmpeg process management required
• Resource Efficiency: MediaMTX handles connection pooling and optimization
• Automatic Reconnection: Built-in retry logic for failed connections
• On-Demand Streaming: Sources only connect when viewers are present
• Better Monitoring: All connections managed in one place

Dynamic Stream Management with the MediaMTX API

The direct source approach becomes incredibly powerful when combined with MediaMTX's REST API. Instead of editing configuration files and restarting services, you can add and remove camera sources dynamically.

Adding a new camera source via API:

For this, you will need to make sure you have API access enabled via the MediaMTX config file. You need to include this:

# Enable HTTP server for web interface and API api: yes apiAddress: :9997 # Change port if needed (default is :9997)

Making API call to add a new source:

curl -X 'POST' \ 'http://localhost:9997/v3/config/paths/add/path_name' \ -H 'accept: */*' \ -H 'Content-Type: application/json' \ -d '{ "name": "test2", "source": "rtsp://192.168.0.43:8554/stream", "sourceOnDemand": true }'

Deleting a camera source:

curl -X 'DELETE' \ 'http://localhost:9997/v3/config/paths/delete/path--' \ -H 'accept: */*'

Listing all current sources:

curl -X 'GET' \ 'http://localhost:9997/v3/config/paths/list?page=0&itemsPerPage=100' \ -H 'accept: */*'

This API-driven approach enables powerful integrations. With this, you can:

• Automatically add cameras as they come online
• Create web interfaces for adding/removing cameras
• Sync with existing surveillance platforms
• Add streams based on demand or schedules

Securing Your MediaMTX Server

Now that we can ingest real-world feeds, let's secure our streaming server. Our current setup is wide open, which is fine for localhost development but catastrophic for production deployment.

Source Authentication: Controlling Who Can Publish

The first layer of security controls who can push streams to your server. Without this, anyone who discovers your server can start broadcasting whatever they want.

Update your mediamtx.yml configuration:

# Secure publishing configuration authInternalUsers: # Administrator with full API access - user: admin_user # You can set a specific username pass: secure_password # Set a password for security ips: ['127.0.0.1', '::1', '192.168.0.0/24'] # Add your network permissions: - action: api - action: publish - action: read

Now your FFmpeg commands need authentication:

ffmpeg -rtsp_transport tcp -i "rtsp://192.168.0.43:8554/stream" \ -c:v libx264 -preset medium -tune zerolatency \ -f rtsp rtsp://admin_user:secure_password@localhost:8554/test_video

This basic authentication prevents unauthorized content from being published and also controls who can view streams. Previewing the streams in VLC now would require you to enter the user and password you have set in your mediamtx.yml configuration.

While this is a significant security improvement, it has limitations for web applications where you can't embed master passwords in client code.

Advanced Security: JWT Authentication

Basic authentication works well for server-to-server communication (like your FFmpeg processes connecting to MediaMTX), but it's inadequate for web applications. You can't give every user the master password, and you need granular control over who can access which streams.

JSON Web Tokens (JWT) solve this problem elegantly. Think of JWTs as temporary, cryptographically-signed permission slips. Your authentication server issues tokens that specify exactly what a user can access and for how long.

Understanding the JWT Flow

Here's how JWT authentication works in practice:

1. User logs into your web application using their credentials
2. Your auth server validates the user and determines their permissions
3. Your auth server issues a JWT that specifies which streams they can access
4. The user's browser uses the JWT to connect to MediaMTX
5. MediaMTX validates the JWT by checking its signature against your public key
6. If valid, MediaMTX grants access according to the token's claims

The beauty is that MediaMTX never needs to talk to your auth server for each request. It just validates the cryptographic signature.

Update your mediamtx.yml configuration:

# JWT Authentication Configuration authMethod: jwt authJWTJWKS: http://your-auth-server.com/jwks-path authJWTClaimKey: mediamtx_permissions

Key configuration elements:

• authMethod: jwt: Enables JWT-based authentication
• authJWTJWKS: URL where MediaMTX can fetch your public keys for signature verification
• authJWTClaimKey: The JWT claim that contains MediaMTX-specific permissions

Understanding JWKS (JSON Web Key Set)

The JWKS endpoint is crucial. It's how MediaMTX gets the public keys needed to verify JWT signatures. MediaMTX fetches this endpoint periodically to get updated keys, allowing for key rotation without server restarts.

A typical JWKS response looks like:

{ "keys": [ { "kty": "RSA", "kid": "key-1", "use": "sig", "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx...", "e": "AQAB" } ] }

JWT Claims for Stream Access

When creating the JWTs, they need to include claims that MediaMTX can understand. Here's an example JWT payload:

A typical JWKS response looks like:

{ "sub": "USER_ID", "exp": 1640995200, "iat": 1640991600, "mediamtx_permissions": [ { "action": "read", "path": "camera_one" }, { "action": "read", "path": "camera_two" }, { "action": "publish", "path": "camera_one" }, { "action": "publish", "path": "camera_two" } ] }

This token allows the user to read (view) the camera_one and camera_two streams, but not publish any streams.

Building a Simple JWKS Endpoint

To demonstrate the complete JWT flow, let's build a minimal authentication server that can issue JWTs and expose a JWKS endpoint. This Node.js example shows the essential components:

Code for this simple JWKS Endpoint can be found on this [Github Repository]()

import express from 'express'; import jwt from 'jsonwebtoken'; import { generateKeyPairSync, createPublicKey } from 'crypto'; const app = express(); app.use(express.json()); // Generate RSA key pair (in production, use persistent keys) const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048, publicKeyEncoding: { type: 'spki', format: 'pem' }, privateKeyEncoding: { type: 'pkcs8', format: 'pem' } }); // Convert public key to JWK format function pemToJwk(pem: string) { const key = createPublicKey(pem); return key.export({ format: 'jwk' }); } // JWKS endpoint - MediaMTX fetches this app.get('/jwks-path', (req, res) => { const jwk = pemToJwk(publicKey); res.json({ keys: [{ ...jwk, kid: 'key-1', use: 'sig' }] }); }); // Token issuing endpoint - your web app calls this app.post('/api/token', (req, res) => { const { username, password } = req.body; // Validate user credentials (implement your logic here) if (username === 'demo' && password === 'demo') { const token = jwt.sign({ sub: username, exp: Math.floor(Date.now() / 1000) + 3600, // 1 hour mediamtx_permissions: [ { action: "read", path: "camera_one" }, { action: "read", path: "camera_two" }, { action: "publish", path: "camera_one" }, { action: "publish", path: "camera_two" }, ], }, privateKey, { algorithm: 'RS256', keyid: 'key-1' }); res.json({ token }); } else { res.status(401).json({ error: 'Invalid credentials' }); } }); app.listen(3000, () => { console.log('Auth server running on http://localhost:3000'); })

Using JWT Tokens with MediaMTX

Once your auth server is running, users can obtain tokens and use them with MediaMTX:

Get a token from your auth server:

curl -X POST http://localhost:3000/api/token \ -H "Content-Type: application/json" \ -d '{"username":"demo","password":"demo"}'

Use the token to access MediaMTX streams: For WebRTC in browsers, you'd typically embed the token in a URL parameter or header that your web application handles.

Production Considerations

The example above demonstrates the concepts, but production JWT implementations need additional considerations:

• Key Management: Use persistent, securely stored keys with regular rotation
• Token Validation: Implement proper expiration and revocation mechanisms
• Permission Models: Design fine-grained permissions that match your application needs
• Security Headers: Add CORS, rate limiting, and other security measures

Putting It All Together: A Complete Secure Setup

Combining everything into a complete, secure streaming configuration, there are two production-ready approaches. You can choose based on your needs.

Approach 1: Direct Sources (Recommended for RTSP cameras)

This approach lets MediaMTX handle camera connections directly. With this approach, you don't need any FFmpeg processes. MediaMTX handles everything. Add new cameras via API.

Use this when:

• Your cameras already provide RTSP streams in suitable formats
• You want simplified deployment and management
• You need dynamic camera provisioning via API
• You prefer built-in connection management and retry logic

Approach 2: FFmpeg Re-streaming (For complex processing needs)

Use this approach when you need format conversion, advanced filtering, or non-RTSP sources:

Uses this when:

• You need format conversion (MJPEG to H.264, resolution changes, etc.)
• You require advanced video processing or filtering
• Your sources use protocols other than RTSP
• You need custom encoding settings per camera

In Summary

We've transformed our simple localhost demo into a secure, production-ready streaming service that can handle real-world complexity. Let's recap what we've built:

Real-World Ingestion: Our pipeline now handles diverse video sources using two powerful approaches:

• Direct Sources: MediaMTX connects directly to RTSP cameras with built-in connection management, retry logic, and API-driven dynamic provisioning
• FFmpeg Re-streaming: For complex format conversion and advanced processing needs

Layered Security: We've implemented multiple security layers:

• Source authentication prevents unauthorized publishing
• Basic authentication controls viewer access
• JWT authentication enables granular, application-integrated access control

Scalable Architecture: The direct source approach with API management creates a highly scalable foundation. You can add and remove camera sources dynamically without service restarts or configuration file edits.

Production-Ready Patterns: Our configurations support different access patterns. Public streams, authenticated private streams, and admin-only content. All managed through a single MediaMTX instance.

The JWT implementation is particularly powerful because it allows your streaming infrastructure to integrate seamlessly with existing authentication systems. Users log into your web application once, and their permissions automatically extend to video stream access.

The MediaMTX API-driven approach represents a significant architectural improvement over traditional setups. Instead of managing dozens of FFmpeg processes and complex configuration files, you can build dynamic camera management systems that respond to changing requirements in real-time.

But we're still running everything on a single server, which creates scaling bottlenecks and single points of failure. What happens when you need to serve thousands of concurrent viewers? How do you monitor stream health across multiple cameras? How do you handle server failures gracefully?

In Part 3, we'll talk about how to handle these challenges. The journey from "secure localhost" to "planet-scale infrastructure" involves some of the most interesting challenges in modern distributed systems and some surprisingly elegant solutions.