Live events in Ravnur Media Services (RMS) enable you to stream live video content to your audience in real-time. A live event is the primary resource for ingesting, transcoding, and distributing live streaming content. Live events support various streaming protocols and can handle everything from small webinars to large-scale broadcasts with millions of concurrent viewers.

In this article:

What are live events?

A live event is a streaming pipeline that receives live video feeds from encoders, processes them, and makes them available for distribution to viewers. Live events manage the entire workflow from video ingestion through content delivery.

Key capabilities:

• Live ingestion - Accept live video feeds from on-premises or cloud encoders.
• Real-time transcoding - Convert incoming streams into multiple bitrates and formats.
• Passthrough mode - Forward pre-encoded streams without additional transcoding.
• DVR functionality - Allow viewers to pause, rewind, and replay live content.
• Low latency streaming - Deliver content with minimal delay for interactive scenarios.
• Cloud Recording - Automatically archive live streams as video-on-demand assets.

Live events work in conjunction with live outputs, streaming locators, and streaming endpoints to deliver a complete live streaming solution.

Live event types

RMS supports two types of live events, passthrough and ABR encoded, each designed for different scenarios:

Passthrough live events

Passthrough live events forward the incoming stream directly to viewers without transcoding. The encoder sends a pre-encoded adaptive bitrate stream that passes through the live event unchanged.

Characteristics:

• No cloud transcoding performed.
• Lower cost (no encoding charges).
• Minimal latency added.
• Requires encoder to produce adaptive bitrate output.
• Multiple bitrate tracks sent from encoder.

When to use:

• You have powerful on-premises encoders.
• You want to control encoding quality and settings precisely.
• Cost optimization is important.
• You need the lowest possible latency.
• You have reliable, high-bandwidth upload connectivity.

Requirements:

• Encoder must output adaptive bitrate stream (multiple quality levels).
• All bitrates must use same GOP size, frame rate, and encoding settings.
• Common configurations: 720p/1080p with 3-6 bitrate levels.

Encoding live events (Standard and Premium)

Encoding live events accept a single bitrate stream and transcode it in the cloud to produce an adaptive bitrate output suitable for streaming.

Standard encoding:

• Accepts single bitrate input (up to 1080p).
• Produces adaptive bitrate output with multiple quality levels.
• Suitable for most live streaming scenarios.
• Balanced cost and performance.

Premium encoding:

• Supports higher input resolutions (up to 4K).
• More encoding options and bitrate ladders.
• Enhanced quality settings.
• Higher cost but greater flexibility.

Characteristics:

• Cloud-based transcoding.
• Single bitrate input required.
• Multiple quality outputs generated automatically.
• Higher cost than passthrough.
• Slightly higher latency than passthrough.
• Simpler encoder requirements.

When to use:

• You have basic encoders that output single bitrate.
• You want Ravnur to handle adaptive bitrate generation.
• You don't have high-bandwidth upload capacity.
• Encoder complexity should be minimized.
• You need failover and redundancy features.

Requirements:

• Single bitrate input stream.
• Supported resolutions and frame rates.
• Compatible video and audio codecs.

Live event architecture

A complete live streaming workflow involves several components:

Core components

Live event - The ingestion and processing pipeline.

Live output - Defines the recording and archival settings for the live stream.

Asset - Storage container for the recorded live stream content.

Streaming locator - Makes the live and archived content available for playback.

Streaming endpoint - The delivery infrastructure that serves content to viewers.

Workflow

1. Create a live event with appropriate encoding type and settings.
2. Start the live event to begin accepting input.
3. Configure encoder with the ingestion URL and key provided by the live event.
4. Create live output to define DVR window and archival settings.
5. Create streaming locator to generate playback URLs.
6. Start encoder to begin sending video to the live event.
7. Distribute URLs to viewers for playback.
8. Monitor stream health and viewer metrics during the event.
9. Stop encoder when event concludes.
10. Stop and delete live event to end streaming and finalize recordings.

For more details, see Live streaming quickstart.

Input protocols

Live events support industry-standard protocols for receiving video from encoders:

RTMP (Real-Time Messaging Protocol)

The most widely supported live streaming protocol.

Characteristics:

• Mature and stable protocol.
• Broad encoder support.
• TCP-based (reliable delivery).
• Good for most scenarios.

Use cases:

• General purpose live streaming.
• Encoders with RTMP output.
• Corporate and educational events.

RTMPS (RTMP Secure)

RTMP over TLS/SSL for encrypted transmission.

Characteristics:

• Encrypted ingestion.
• Prevents eavesdropping during upload.
• Slightly higher overhead than RTMP.

Use cases:

• Sensitive content requiring encryption in transit.
• Compliance requirements.
• Public internet transmission with security concerns.

SRT (Secure Reliable Transport)

Modern open-source protocol optimized for live video over unpredictable networks.

Characteristics:

• Low latency transmission.
• Built-in encryption (AES).
• Excellent packet loss recovery.
• Firewall-friendly (UDP-based).
• Adaptive bitrate handling.

Use cases:

• Remote production over public internet.
• Locations with unreliable network connectivity.
• Long-distance contribution feeds.
• Mobile and bonded cellular encoders.
• Sports and news field production.

Benefits:

• Better performance than RTMP over lossy networks.
• Lower latency than RTMP.
• No need for VPN for secure transmission.

RTSP Push

Real-Time Streaming Protocol in push mode, where the encoder initiates the connection.

Characteristics:

• RTP/RTCP-based transport.
• UDP or TCP transport options.
• Lower latency than RTMP.
• Standardized protocol.

Use cases:

• IP cameras and surveillance systems.
• Hardware encoders with RTSP output.
• Broadcast equipment integration.
• Professional production workflows.

RTSP Pull

Real-Time Streaming Protocol in pull mode, where RMS connects to the encoder.

Characteristics:

• Ravnur initiates connection to encoder.
• Encoder acts as RTSP server.
• Useful for fixed encoder locations.
• Supports both UDP and TCP transport.

Use cases:

• Permanent encoder installations.
• IP camera integration where cameras are RTSP servers.
• Broadcast facilities with RTSP output.
• Environments where encoders cannot push to cloud.

Input and output settings

Video input requirements

Supported codecs:

• H.264 (AVC).
• H.265 (HEVC) - for certain configurations.

Resolutions:

• Standard: Up to 1920x1080 (1080p).
• Premium: Up to 3840x2160 (4K).

Frame Rates:

• 23.976, 24, 25, 29.97, 30, 50, 59.94, 60 fps.
• Must remain constant throughout stream.

Bitrates:

• Passthrough: Multiple bitrates (typically 500 Kbps to 8 Mbps per track).
• Encoding: Single bitrate (typically 2-8 Mbps depending on resolution).

GOP (Group of Pictures):

• Recommended: 2 seconds.
• Must use closed GOP.
• All bitrates must align GOP boundaries (passthrough).

Audio input requirements

Supported codecs:

• AAC-LC (most common)
• MP3
• AC-3

Sample rates:

• 44.1 kHz or 48 kHz preferred.
• Must remain constant.

Channels:

• Mono, Stereo, or Surround sound.
• Must remain constant.

Bitrates:

• Typically 128-192 Kbps for stereo.

Live output and DVR

Live outputs define how the live stream is recorded and how much time-shifted viewing is available.

Archive window

The archive window determines how much of the live stream is recorded:

Setting Options:

• Minimum: 1 hour.
• Maximum: 24 hours.
• Default: Entire event duration.

Content older than the archive window is automatically discarded and cannot be viewed.

DVR Window

The DVR window (manifest window) determines how far back viewers can seek in the live stream:

Characteristics:

• Subset of archive window.
• Allows viewers to pause, rewind, and catch up.
• Does not affect final recording.

Use cases:

• Short DVR (5-15 minutes) - Breaking news, sports with minimal rewind needs.
• Long DVR (hours) - Conferences, all-day events where viewers join at different times.
• No DVR - Pure live with no time-shifting.

Recording behavior

Continuous recording:

• Live output records from creation until deletion.
• Creates a single asset with complete event recording.
• Suitable for full event archival.

Segment recording:

• Create and delete live outputs to produce separate recordings.
• Useful for creating distinct video-on-demand assets from a single live event.
• Example: Record each session of a multi-session conference separately.

Low latency live streaming

RMS supports low latency modes for interactive scenarios:

Standard latency

Characteristics:

• Typical delay: 15-30 seconds from camera to viewer.
• Suitable for most live streaming scenarios.
• Optimizes for quality and scale.

Use cases:

• Webinars and presentations.
• Entertainment and sports broadcasts.
• Corporate communications.

Low latency mode

Characteristics:

• Reduced delay: 3-10 seconds from camera to viewer.
• Enables more interactive experiences.
• May require additional player configuration.

Use cases:

• Live auctions.
• Interactive Q&A sessions.
• Gaming streams with chat interaction.
• Live betting and real-time engagement.

Configuration:

• Enable low latency on live event creation.
• Use compatible players that support low latency protocols.
• Configure encoder for lower GOP sizes.

Trade-offs:

• Slightly reduced scalability compared to standard latency.
• May require more bandwidth for viewers.
• Requires compatible player implementation.

Live event states and lifecycle

Live events progress through several states during their lifecycle:

State machine

Stopped - Initial state after creation, no costs incurred.

Starting - Transitioning to running state, resources being allocated.

Running - Active and ready to receive encoder input, incurs running costs.

Stopping - Transitioning to stopped state, finalizing recordings.

Deleting - Being removed from the system.

See the tips on how to check the state and health state via the RMS Console.

State transitions

Start operation:

• Stopped → Starting → Running.
• Allocates resources and prepares for ingestion.
• Takes 2-4 minutes typically.

Stop operation:

• Running → Stopping → Stopped.
• Finalizes recordings and releases resources.
• Takes 1-2 minutes typically.

Delete operation:

• From any state → Deleting → Removed.
• Permanently removes live event.
• Recorded assets remain available.

Cost implications

Running state costs:

• Live events incur charges while in Running state.
• Costs based on encoding type and duration.
• Stop live events when not actively streaming to avoid charges.

Stopped state:

• No charges for stopped live events.
• Configuration and settings preserved.
• Can be restarted for future events.

Best practice:

• Stop live events immediately after streaming concludes.
• Don't leave events in Running state when idle.
• Use stopped live events for recurring events with same configuration.

Live event creation and configuration

When creating a live event, you specify:

• Live event name - Unique identifier within your account.
• Live event type - Passthrough or Encoding (Standard/Premium).
• Input protocol - RTMP, RTMPS, SRT, RTSP Push, or RTSP Pull.
• Encoding preset - For encoding live events, defines output quality settings.
• Key Frame Interval - GOP size for encoding live events.
• Streaming protocol - Output format (HLS, DASH).
• Description - Optional description of the event.
• Tags - Metadata for organization and management.

IP allow list

Control which IP addresses can send video to your live event:

Open access:

• Any IP address can connect (0.0.0.0/0)
• Useful for testing or dynamic encoder IPs
• Less secure

Restricted Access:

• Specify exact IP addresses or CIDR ranges to Ravnur support.
• Recommended for production.
• Prevents unauthorized encoder connections.

Example configuration:

• 203.0.113.5/32 - Single encoder IP.
• 203.0.113.0/24 - Entire subnet.
• Multiple entries for redundant encoders.

Monitoring and diagnostics

Live event health

Monitor live event status in real-time:

Ingest health:

• Bitrate monitoring.
• Dropped frames detection.
• Connection stability.
• GOP alignment issues (passthrough).

Stream health:

• Audio/video synchronization.
• Timestamp accuracy.
• Discontinuities and errors.

Viewer metrics:

• Concurrent viewer count.
• Geographic distribution.
• Bandwidth consumption.
• Error rates.

Diagnostic logs

Enable detailed logging for troubleshooting:

Encoder connection logs:

• Connection attempts and failures.
• Authentication issues.
• Protocol errors.

Ingestion logs:

• Bitrate variations.
• Frame drops.
• Audio/video issues.

Output logs:

• Packaging and manifest generation.
• Player request patterns.
• Errors and warnings.

Use cases and examples

Corporate webinar

Scenario: Monthly all-hands meeting with 500 employees.

Configuration:

• Live event type: Standard encoding.
• Input: Single bitrate 1080p from presentation software.
• DVR Window: 1 hour (allows latecomers to catch up).
• Recording: Full archive for on-demand viewing.
• Latency: Standard (15-30 seconds acceptable).

Result: Simple setup with single encoder, automatic adaptive bitrate generation, recorded for later viewing.

Sports broadcast

Scenario: Live sports event with 10,000+ concurrent viewers.

Configuration:

• Live event type: passthrough.
• Input: Multi-bitrate adaptive stream from professional encoder.
• DVR Window: 1 hour (instant replay capabilities).
• Recording: Full game archive.
• Redundancy: Active-active with primary and secondary ingest.
• Latency: Standard for quality and scale.

Result: High-quality broadcast with encoder control, reliable failover, instant replay.

Multi-day conference

Scenario: 3-day technology conference with multiple sessions.

Configuration:

• Live event type: Standard encoding.
• Input: Single bitrate from venue equipment.
• DVR Window: 6 hours (full day catch-up).
• Recording: Separate live outputs for each session.
• Approach: Single live event running continuously, start/stop live outputs per session.

Result: Efficient resource usage, organized session recordings, comprehensive DVR.

Virtual classroom

Scenario: Online course with interactive Q&A.

Configuration:

• Live event type: Standard encoding with low latency.
• Input: Single bitrate from instructor's computer.
• DVR Window: 2 hours (class duration).
• Recording: Full class archive.
• Latency: Low for interactive discussion.

Result: Engaging experience with near real-time interaction, complete recording.

Remote sports production with SRT

Scenario: Live sports coverage from stadium with unreliable public internet.

Configuration:

• Live event type: Passthrough or standard encoding.
• Input Protocol: SRT for resilient transmission over unpredictable networks.
• Redundancy: Bonded cellular plus venue WiFi as backup.
• DVR Window: 1 hour.
• Recording: Full event archive.

Result: Reliable transmission despite network challenges, professional broadcast quality.

IP camera surveillance integration

Scenario: Live monitoring and recording from security camera system.

Configuration:

• Live event type: Passthrough.
• Input protocol: RTSP Pull from IP cameras.
• DVR Window: 24 hours for continuous monitoring.
• Recording: Continuous archive for security purposes.
• Multiple cameras: Separate live events per camera or camera group.

Result: Cloud-based surveillance with long-term recording and remote monitoring.

Best practices

✅ Plan your encoding strategy - Choose passthrough for quality control and cost savings, encoding for simplicity and encoder failover.

✅ Select appropriate input protocol - Use SRT for challenging network conditions, RTSP for IP cameras, RTMP for general purpose streaming.

✅ Test before going live - Always conduct a full test stream days before the actual event.

✅ Use redundant encoders - Configure primary and secondary ingest for critical broadcasts.

✅ Configure IP allow lists - Restrict ingest to known encoder IP addresses in production.

✅ Monitor stream health - Watch for dropped frames, bitrate issues, and connection problems during live streams.

✅ Set appropriate DVR windows - Balance viewer flexibility with storage costs and use case requirements.

✅ Record important events - Create live outputs to archive content for video-on-demand distribution.

✅ Stop events promptly - Stop live events immediately after streaming to avoid unnecessary charges.

✅ Use consistent settings - Maintain constant frame rate, resolution, and GOP size throughout the stream.

✅ Plan for bandwidth - Ensure adequate upload bandwidth from encoder location (2-3x stream bitrate minimum).

✅ Prepare backup plans - Have backup encoders, internet connections, and contingency procedures ready.

✅ Communicate with encoders - Ensure encoder operators understand requirements and procedures.

✅ Leverage SRT for remote production - Take advantage of SRT's error correction for challenging network environments.

Limitations and considerations

Maximum concurrent live events - Account limits on simultaneous running live events; plan accordingly.

Start/Stop time - Live events take 5-10 minutes to start; plan ahead of event time.

Encoding limitations - Input resolution and bitrate limits based on encoding tier.

DVR Window limits - Maximum 24-hour archive window; longer events require management.

Disconnection handling - Brief encoder disconnections are tolerated; extended disconnections may require restart.

Format support - Not all video/audio formats supported; verify encoder compatibility.

Geographic considerations - Consider encoder location relative to Ravnur region for optimal performance.

Cost management - Running live events incur costs; monitor usage and stop unused events.

Network requirements - Reliable, high-bandwidth connection essential for encoder location.

Player compatibility - Ensure target players support your chosen streaming protocols and latency settings.

Protocol-specific requirements - Each input protocol has specific configuration needs; consult documentation.

See more:

• Live Outputs: API reference
• Assets: API reference
• Streaming Locators
• Streaming Endpoints
• Encoders and Encoding Settings