How to Simulate ONVIF Recording and Replay for NVR Compatibility Testing

Why Simulate ONVIF Recording and Replay?

Testing NVR recording and playback integration against ONVIF Profile G is challenging because it requires a real device that has already been recording for hours or days. Happytime ONVIF Server solves this by allowing you to:

• Pre-populate Recordings: Seed the simulator with media files that appear as if they were recorded at specific past times, enabling immediate search-and-replay testing without waiting for real recording to accumulate.
• Test Recording Search: Validate that your VMS client correctly sends FindRecordings and GetRecordingSearchResults requests with time-range filters, event-based filters, and metadata filters.
• Test Replay Control: Verify rate-control operations: play, pause, fast-forward (2x, 4x, 8x), rewind, and reverse playback using RTSP RTP-Info and Scale headers.
• Test Edge Cases: Simulate recordings spanning DST transitions, midnight boundaries, long-duration continuous recordings, and fragmented recording sessions.
• Repeatable Regression Testing: Use the same configuration every test run to ensure consistent validation of your NVR software across releases.

Happytime ONVIF Server has a dedicated Profile G compatible version that implements the Recording Control, Recording Search, and Replay Control services, and has passed compatibility testing with the ONVIF official test tool.

Understanding ONVIF Profile G Recording Architecture

Before configuring the simulator, it is essential to understand the ONVIF recording model. Profile G defines how an ONVIF client interacts with a recording-capable device (such as an NVR or an IP camera with SD card storage).

Core Concepts

Three Key ONVIF Services for Profile G

Step 1: Use the Profile G Compatible Version

Happytime ONVIF Server provides separate builds for different ONVIF profiles. For recording and replay simulation, you must use the Profile G compatible version, which activates the Recording Control, Recording Search, and Replay Control web services.

• Windows (x86): happytime-onvif-server-profileg.zip
• Linux: happytime-onvif-server-profileg.tar.gz

Both versions are available from the ONVIF Server download section. The Profile G build includes all the standard ONVIF Core and Media services plus the three recording-specific services.

Step 2: Configure the Device as a Recording Server

In the configuration file, set the device to advertise itself as an NVR-type device with recording capability. This ensures that ONVIF clients recognize the device as a recording source during discovery.

<config>
    <!-- Device identity -->
    <name>Test-NVR-ProfileG</name>
    <manufacturer>Happytimesoft</manufacturer>
    <model>ONVIF-REC-SIM</model>
    <hardware_id>NVR-TEST-001</hardware_id>

    <!-- Network -->
    <http_port>8080</http_port>
    <https_port>443</https_port>
    <rtsp_port>554</rtsp_port>
    <ip_address>192.168.1.210</ip_address>
    <ipv6_enable>0</ipv6_enable>

    <!-- Enable Profile G recording services -->
    <device_type>NVR</device_type>
    <profiles>S,T,G</profiles>

    <log_enable>1</log_enable>
    <log_level>1</log_level>
    <log_path></log_path>
    <log_mode>loop</log_mode>
    <log_max_size></log_max_size>
</config>

Key points:

• <device_type> set to NVR informs clients that this device is a recording-capable server and exposes the recording service endpoints.
• <profiles> must include G to advertise Profile G compliance. You can list multiple profiles (e.g., S,T,G) if the device also supports live streaming.

Step 3: Define Media Profiles for Recording

A media profile defines the video and audio encoding configuration that the recording will use. Each recording track references a media profile, which dictates the codec, resolution, framerate, and bitrate of the stored data.

<media_profiles>
    <!-- Profile 1: Default recording profile (H.264, 1080p) -->
    <profile>
        <token>Profile-H264-1080p</token>
        <name>H.264 1080p Recording</name>
        <video_source>VideoSource1</video_source>
        <video_encoder>
            <codec>H264</codec>
            <resolution>1920x1080</resolution>
            <framerate>25</framerate>
            <bitrate>4096</bitrate>
        </video_encoder>
        <audio_source>AudioSource1</audio_source>
        <audio_encoder>
            <codec>G711A</codec>
            <samplerate>8000</samplerate>
            <channels>1</channels>
        </audio_encoder>
    </profile>

    <!-- Profile 2: Secondary recording (H.265, lower bitrate) -->
    <profile>
        <token>Profile-H265-720p</token>
        <name>H.265 720p Recording</name>
        <video_source>VideoSource1</video_source>
        <video_encoder>
            <codec>H265</codec>
            <resolution>1280x720</resolution>
            <framerate>15</framerate>
            <bitrate>2048</bitrate>
        </video_encoder>
    </profile>
</media_profiles>

Step 4: Configure Recordings and Tracks

A recording is the top-level container. Each recording contains one or more tracks. Typically, you configure one recording per simulated camera channel.

<recordings>
    <!-- Recording 1: Camera Channel 1 -->
    <recording>
        <token>Recording-Ch01</token>
        <name>Front Entrance Camera</name>
        <description>Continuous recording from front entrance IP camera</description>
        <tracks>
            <track>
                <token>Track-Ch01-Video</token>
                <type>Video</type>
                <description>Main video track</description>
            </track>
            <track>
                <token>Track-Ch01-Audio</token>
                <type>Audio</type>
                <description>Audio track</description>
            </track>
        </tracks>
    </recording>

    <!-- Recording 2: Camera Channel 2 -->
    <recording>
        <token>Recording-Ch02</token>
        <name>Parking Lot Camera</name>
        <description>Motion-triggered recording from parking lot camera</description>
        <tracks>
            <track>
                <token>Track-Ch02-Video</token>
                <type>Video</type>
                <description>Main video track</description>
            </track>
        </tracks>
    </recording>
</recordings>

Track types supported:

• Video: H.264, H.265, MPEG-4 encoded video data.
• Audio: G.711, G.726, AAC encoded audio data.
• Metadata: Analytics events, motion detection markers, PTZ position data, and other structured metadata associated with specific timestamps in the video.

Step 5: Configure Recording Jobs

A recording job binds a recording to a media profile and defines the recording mode. ONVIF supports two primary job modes:

<recording_jobs>
    <!-- Continuous recording job -->
    <job>
        <token>Job-Continuous-Ch01</token>
        <name>Channel 1 Continuous</name>
        <recording_token>Recording-Ch01</recording_token>
        <profile_token>Profile-H264-1080p</profile_token>
        <mode>Continuous</mode>
        <priority>high</priority>
    </job>

    <!-- Event-triggered recording job -->
    <job>
        <token>Job-Event-Ch02</token>
        <name>Channel 2 Motion-Triggered</name>
        <recording_token>Recording-Ch02</recording_token>
        <profile_token>Profile-H265-720p</profile_token>
        <mode>Event</mode>
        <priority>high</priority>
        <event_filter>MotionDetection</event_filter>
        <pre_event_buffer>5</pre_event_buffer>   <!-- seconds of video before the event -->
        <post_event_buffer>10</post_event_buffer>  <!-- seconds of video after the event ends -->
    </job>
</recording_jobs>

Job configuration parameters:

• recording_token: Must match one of the recording tokens defined in the <recordings> section.
• profile_token: Must match a media profile token. This determines the codec and quality of the recorded data.
• priority: When multiple jobs reference the same recording, priority determines which one runs. high jobs preempt low ones.
• event_filter: For event-triggered jobs, specifies which event type activates recording (e.g., MotionDetection, DigitalInput, Analytics).
• pre_event_buffer / post_event_buffer: Overlapping recording around event boundaries, ensuring the moment of interest is captured.

Step 6: Seed the Simulator with Pre-Recorded Data

For immediate testing without waiting for real recording, the ONVIF Server can be populated with existing media files that are indexed by timestamp. This allows you to run recording search and replay tests immediately.

<recording_data>
    <!-- Pre-seeded recording segment for Channel 1 -->
    <segment>
        <recording_token>Recording-Ch01</recording_token>
        <track_token>Track-Ch01-Video</track_token>
        <start_time>2026-07-09T08:00:00Z</start_time>
        <end_time>2026-07-09T10:00:00Z</end_time>
        <media_source>recordings/sample-front-entrance-20260709-0800.mp4</media_source>
        <event_type>Continuous</event_type>
    </segment>

    <segment>
        <recording_token>Recording-Ch01</recording_token>
        <track_token>Track-Ch01-Video</track_token>
        <start_time>2026-07-09T10:00:00Z</start_time>
        <end_time>2026-07-09T12:00:00Z</end_time>
        <media_source>recordings/sample-front-entrance-20260709-1000.mp4</media_source>
    </segment>

    <!-- Event-triggered recording segment -->
    <segment>
        <recording_token>Recording-Ch02</recording_token>
        <track_token>Track-Ch02-Video</track_token>
        <start_time>2026-07-09T14:23:45Z</start_time>
        <end_time>2026-07-09T14:24:55Z</end_time>
        <media_source>recordings/motion-event-parking-20260709.mp4</media_source>
        <event_type>MotionDetection</event_type>
        <event_description>Vehicle entering parking lot</event_description>
    </segment>
</recording_data>

Seeding notes:

• Timestamps must be in UTC (ISO 8601 format). The simulator uses these timestamps when responding to recording search queries.
• Media files should match the codec and resolution specified in the corresponding media profile. Mismatched codec/resolution may cause the replay stream to fail on the client.
• Multiple segments can cover different time ranges for the same recording. Gaps between segments are treated as "no recording available" for that time period.
• The event_type field determines how the segment appears in event-filtered searches. Events with the same type can be filtered using the FindRecordings search criteria.

Step 7: Complete Configuration Example

Below is a full working configuration for a single ONVIF Server Profile G instance with 2 recordings, 2 media profiles, and pre-seeded recording data:

<config>
    <name>Test-NVR-ProfileG</name>
    <manufacturer>Happytimesoft</manufacturer>
    <model>ONVIF-REC-SIM</model>
    <hardware_id>NVR-TEST-001</hardware_id>
    <http_port>8080</http_port>
    <https_port>443</https_port>
    <rtsp_port>554</rtsp_port>
    <ip_address>192.168.1.210</ip_address>
    <ipv6_enable>0</ipv6_enable>
    <device_type>NVR</device_type>
    <profiles>S,T,G</profiles>
    <log_enable>1</log_enable>
    <log_level>1</log_level>
    <log_path></log_path>
    <log_mode>loop</log_mode>
    <log_max_size></log_max_size>
</config>

Step 8: Testing Recording and Replay with an ONVIF Client

Once the ONVIF Server is running, you can validate Profile G compliance using any ONVIF-compliant client or the ONVIF Device Test Tool. Below are the key test flows.

Test Flow 1: Discover Recording Capability

1. Use an ONVIF client to discover the device on the network.
2. Verify that the device advertises Profile G in its capabilities (under GetServices or GetCapabilities).
3. Verify that the Recording Control, Recording Search, and Replay Control service endpoints are present in the device's service list.

Test Flow 2: Query Recording Configuration

1. Call GetRecordings to list all available recordings. Confirm that Recording-Ch01 and Recording-Ch02 appear.
2. For each recording, call GetRecordingOptions to verify supported modes, track types, and media formats.
3. Call GetRecordingJobs to list active recording jobs. Confirm that both the continuous job and the event-triggered job are listed with their correct modes.

Test Flow 3: Search Recordings by Time Range

1. Call FindRecordings with a search scope that covers the entire day (e.g., 2026-07-09T00:00:00Z to 2026-07-10T00:00:00Z).
2. Call GetRecordingSearchResults to retrieve the matching recording information. Verify that all seeded segments appear with their correct start and end times.
3. Test with a narrow time window (e.g., 09:00-09:30). Confirm that only recordings overlapping that window are returned.
4. Test with a time range that has no recordings (e.g., 2026-07-09T03:00-04:00Z). Confirm that zero results are returned, not an error.

Test Flow 4: Search Recordings by Event Type

1. Call FindRecordings with an event type filter set to MotionDetection.
2. Verify that only the motion-triggered recording segment (Channel 2 parking lot) is returned.
3. Test with a non-existent event type. Confirm that zero results are returned.

Test Flow 5: Replay Playback with Rate Control

1. From the search results, select a recording segment and call GetReplayUri to obtain the RTSP replay URL.
2. Open the RTSP stream using an RTSP-capable player. The stream should begin playing from the start time of the selected segment.
3. Test pause/resume using RTSP PAUSE and PLAY commands. Verify that playback pauses and resumes at the correct position.
4. Test seek (NPT-based): Send a PLAY request with a Range header specifying a midpoint within the recording (e.g., Range: npt=900.000- for 15 minutes in). Verify that playback jumps to the requested position.
5. Test fast-forward: Send a PLAY request with Scale: 4.0. Verify that playback runs at 4x speed.
6. Test rewind / reverse playback: Send a PLAY request with Scale: -1.0 to play backwards at normal speed, or Scale: -2.0 for 2x reverse. Verify that the reverse stream plays correctly.

Test Flow 6: Verify Recording Information Details

1. For each recording information entry returned by the search, call GetRecordingInformation to retrieve detailed metadata.
2. Verify that the recording information includes: recording token, recording time (start/end), track token, and any event data.
3. Validate that timestamps are in the correct format (ISO 8601 UTC) and that time arithmetic is consistent (end_time is after start_time).

Step 9: Run and Verify

1. Save the onvifserver.cfg configuration file in the Profile G version's working directory.
2. Place your seed media files in the recordings/ directory (or adjust paths in the config). Ensure files are accessible to the ONVIF Server process.
3. Launch the Profile G ONVIF Server executable.
4. Check the logs to confirm that all services started, recording data was loaded, and the RTSP server is listening on port 554.
5. Discover and test using your ONVIF client, following the six test flows described in Step 8.

Troubleshooting

Best Practices

• Use the Dedicated Profile G Build: Always use the Profile G compatible version when testing recording and replay. The standard Profile S build does not expose Recording Search or Replay Control services.
• Prepare Diverse Seed Data: Create media files of varying durations (short 1-minute clips, long 2-hour clips) and with different event types. This enables comprehensive testing of search filters, time boundaries, and long-playback scenarios.
• Include Edge-Case Timestamps: Seed recordings that span midnight (23:50 to 00:10), DST transitions, and month boundaries. These edge cases are where NVR search logic most frequently breaks.
• Test All Rate Control Values: Verify not just play and pause, but also fast-forward (2x, 4x, 8x, 16x), slow motion (0.5x, 0.25x), and reverse (-1x, -2x). Profile G requires support for all these scales.
• Test Pagination: When seeding many recording segments, verify that your client correctly paginates through FindRecordings results and does not truncate data at arbitrary limits.
• Validate Metadata Tracks: If your NVR supports metadata tracks (analytics overlays, PTZ position data alongside video), seed a recording with a metadata track to verify that the client correctly displays and aligns metadata with video frames.
• Keep Configuration Under Version Control: Store your test configurations and seed media files in a repository. This ensures that regression testing is exactly reproducible across NVR software versions.