Get started with nDVR in Wowza Streaming Engine

This guide describes many relevant concepts and requirements that are important to understand when you start using nDVR, which provides the ability to record a live stream with Wowza Streaming Engine™ media server software while simultaneously allowing users to play or pause a live stream, rewind to a previously recorded point, and resume viewing at the current live point. nDVR works with the HLS (Cupertino) and MPEG-DASH protocols. Custom configuration enables you to control the archive strategy and availability of your recorded streams. nDVR requires that the audio and video in an incoming stream be aligned.

Setup for client playback of recorded streams is similar to playback of live streams from Wowza Streaming Engine and can be easily added to your existing server configuration.

Note: Wowza Streaming Engine 4.7.6 or later is required to use nDVR for MPEG-DASH streaming.

Contents

Streaming concepts

nDVR can be configured to support multiple workflows and supports:

• Stream types – The live stream type as well as the liverepeater-edge stream type, which is used in live repeater (origin/edge) configurations. To set up an nDVR live stream repeater, see Set up a Wowza Streaming Engine live stream repeater for nDVR.
• Video and audio codecs
   
  • Video – H.264, video-only streams
  • Audio – AAC, MP3, audio-only streams
   

  Note: A common mistake is to try to record a live source stream that has an unsupported codec. However, if your source uses a codec that’s not supported by nDVR but is supported for ingest by Transcoder, you can transcode your source stream before recording. This setup can be accomplished with one application and doesn't require a two-step process. For more information, see Adaptive bitrate streaming and transcoding.

• Protocols – A Wowza Streaming Engine server can deliver H.264-encoded streams using the following HTTP streaming protocols:
   
  • HLS through the Cupertino packetizer, but not CMAF or Low-Latency HLS
  • MPEG-DASH through the MPEG-DASH packetizer, but not CMAF (Wowza Streaming Engine 4.7.6 and later)
• Players – To play recorded streams, you can use JW Player or your own custom player.
   

  Note: Apple iOS devices require that video is encoded using H.264 format and AAC or MP3 stereo audio. Profile and level support varies depending on the device, see the Apple technical specifications for the devices that you plan to target.

• Adaptive bitrate streaming and transcoding – Transcoder and nDVR can work together to transrate/transcode and record a live stream at the same time. You can set this up with one application and one configuration. Additional post-processing isn't required. For more information about Transcoder, see any of the technical articles at Use Transcoder.
  
  nDVR also allows you to leverage Synchronized Multimedia Integration Language (SMIL) files for adaptive bitrate streaming. The SMIL workflow requires an encoder that can generate multiple bitrate streams from the same source with properly aligned keyframes.
   

  Important: The streams used in adaptive bitrate streaming must have aligned keyframes. nDVR creates chunks based on the keyframe alignment and the adaptive bitrate switching occurs on chunk boundaries.

• nDVR can be configured using Wowza Streaming Engine Manager or via the Java API.

Playback URLs

Notes:

• In the following examples, [wowza-ip-address] is the IP address or domain name of the server running Wowza Streaming Engine, dvr is the name of the application, and myStream is the name of the stream.
• The smil: prefix is used when playing back a group of stream renditions using SMIL files. To see an example SMIL file, see Stream adaptive bitrate content with Wowza Streaming Engine. If you're using SMIL files to create adaptive bitrate, use the adaptive bitrate playback URL formats, below.

Use the following URL formats to play your nDVR recorded streams over the supported HTTP protocols:

Installation and configuration

Licensing nDVR

Application configuration

Content storage

Examples

• If the application name ([app-name]) is myApplication and the stream name ([streamName] is myStream, with the default settings in Application.xml, the storage directory will be located at [install-dir]/dvr/myApplication/_definst_/myStream.0.
• If you set the DVR/StorageDir property to E:/myStorage and your stream name is myStream, the storage directory will be located at E:/myStorage/dvr/_definst_/myStream.0.
• nDVR records each output rendition from Transcoder in a separate directory structure. If you're using the sample Transcoder template transrate.xml with a live stream named myStream, you'll see the following directories created in [install-dir]/dvr/[app-name]/_definst_/[streamName][.n]:
   
  • myStream.0
  • myStream_160p.0
  • myStream_360p.0

Directory structure

Each time-based folder contains .m4fa (audio information) and .m4fv (video information) files and a .txt (manifest) file. If the incoming stream sends metadata, a .m4fm (metadata) file is also created. These files are based on the MPEG-4 format and together represent a chunk of recorded audio and video content that can be used for playback of your recorded stream. The manifest file contains information about each recorded audio and video chunk and should not be edited. These files cannot be played directly. However, they are required and referenced when you play your live recorded stream using nDVR. nDVR does not concatenate the recorded files into a single on-demand file for later use.

Using the folder named 0000_00_00 as an example, the files that describe the first chunk are:

Archive strategy

• append: Specifies that nDVR will append to the existing recording. This is the default setting.
   
• delete: Specifies that the previous recording will be deleted and replaced with the new recording.
   
• version: Specifies that a new content storage directory will be created. If the stream name is myStream, the first recording is written to [install-dir]/dvr/[application-name]/myStream.0, the second recording is written to a directory named myStream.1, and so on. Whenever there's a recording of the same stream name, the previous recording is preserved and not deleted or overwritten.

DVR window duration

Best practices

Aligned audio and video

Input streams with short keyframe intervals and aligned audio and video work best. nDVR expects that the audio and video in an incoming live stream is aligned. When the audio and video are out of alignment beyond the allowable tolerance, you'll see the following WARN message in [install-dir]/logs:

WARN DvrPacketHandler.handlePacket[myApplication/_definst_/myStream]: Tossing packet with excessive duration: {DvrAMFPacket: size:6785, type:9, src:32185, seq:126, absTimecode: 35557077, timecode:131362, utcTc:1337890914597}

If you have out-of-alignment issues, you can set properties in Application.xml to try to compensate for them; however, nDVR can't fix these problems. See dvrAllowableAVPacketDelta in Configure advanced properties for nDVR. Note that this property is meant to help in situations where audio and video aren't closely aligned. If you already have an out-of-alignment issue, increasing the default value is likely to cause more problems. Increasing this value will increase the number of chunks that aren't recorded, which may cause the overall quality to be unacceptable.

Keyframe size

HTTP streaming has a latency of 3 chunks, which is why smaller keyframe sizes after often recommended. Smaller keyframe sizes result in more data in the playlist. Consider playlist size and the frequency in which the data is being sent from the server when determining your encoding settings.

Dependable live stream

nDVR requires a reliable live stream. When troubleshooting nDVR, first test that your live workflow is successful without nDVR enabled.

Recording length

nDVR has a recording limit of 30 hours. In real-world deployments, serving playlist data this large won't work. Also, if a problem occurs during the recording (disk full, network, out-of-memory, etc.), the entire recording could be comprised. An extremely large manifest file may also cause performance issues because the entire manifest file must be loaded into memory. Select a strategy that records a reasonable length so that small manifest files can be loaded and unloaded quickly. A longer recording is a viable workflow if only a small part of the recording is specified for playback. For example, a 24-hour recording with a 1- or 2-hour playback windows results in a much smaller playlist size vs. a playlist for the entire 24-hour recording. The playlist will be repeatedly requested every few seconds (based on keyframe size); therefore, an extremely large playlist size is problematic for the player and should be avoided. For more information about how to request a portion of your recording for playback, see Use nDVR playlist request with the Wowza Streaming Engine Java API.

Built-in safeguards

nDVR has multiple built-in safeguards built that require no additional configuration.

If nDVR detects an invalid chunk, it will try to fix it by recalculating if the clock was reset. Or, if it can't fix it, the chunk will be thrown out. For example, an invalid chunk could be caused by a problematic input stream where the video gets far ahead of the audio. If this occurs, it's reported in the logs with warning messages like the following:

WARN LiveStreamDvrRecorder.endChunk[myApplication/_definst_/myStream]: Recalculating duration by estimating. Was -601. Is now 811.
WARN DvrPacketHandler.handleHolder(): Skipping holder that can't be re-aligned. Holder: {DvrPacketHolder: type:V pt:3332574 utc:1335872445912 dur:1230 (KEY, ) codec:7 numPackets:0 dataLen:18513 enc.n:0 pkt:{{DvrAMFPacket: size:18513, type:9, src:1, seq:0, absTimecode: 3332574, timecode:1230, utcTc:1335872445912}}}

FAQs

What's an example of flexible viewer start time with a live event?

1. Users start viewing from the start time of the live stream, rewind to hear a particular part of the video again, and then continue streaming from the current live point.
    
2. If users join late, they can start viewing after the time the live stream has started, but start from the beginning and continue until the live stream ends. In this scenario, users can start at any time after the live stream has started--1 minute later or 1 hour later.
    
3. Users can start viewing the recording after the live stream has stopped. In this scenario, playback is streaming the previously recorded content as video on demand (VOD).

When do I need to use nDVR for recording?

Do I need a separate Wowza Streaming Engine application if I already have my live workflow set up?

How do I play a recorded video after the live event and recording is finished?

How do I specify playback start and end times?

What happens to my recording if my live stream disconnects?

Can I play recorded streams from nDVR over RTSP, RTP, RTMP?

Can I play a previous version of a recorded stream?

http://localhost:1935/myApplication/myStream.3/playlist.m3u8?dvr

What does dvrstreamingpacketizer do?

What happens if I don't set a store location?

nDVR sets the default store location as:

<Store>dvrfilestorage</Store>

In a live repeater (origin/edge) configuration, this property must be left empty. For more information, see Set up live stream repeater for use with nDVR (origin/edge).