The DVR Module of the LEADTOOLS Multimedia API allows you to programmatically control the Capture object when capturing live video source or UDP network video streams. The purpose is to provide a mechanism, similar to a traditional DVR device, for video storage and playback of streaming video content.
A: The main purpose is to allow the capture of compressed video streaming samples to a circular buffer queue on disk, implemented as a set of files under a given folder path. When setting the DVR buffer properties, you can control the number of buffer queue folder locations, name of the buffer queue location's list file and recording chunk files, the number of recording chunk files to use and the size of each in bytes. For each buffer folder there are a group of related buffer files created, an .LBL (LEAD Buffer List) file and several .LRC (Lead Recording Chunk) files. The .LBL file specifies which .LRC files are used as underlying storage, as well as the playback ranges and their mappings to .LRC file data offsets.
A: It is important to note that the relationship between buffered file storage (in bytes on disk) and the duration of video playback (in seconds) is directly related to the compression bitrate (amount of compressed video data per second).
This relationship is as follows: File_size_bytes = duration_in_seconds * bitrate_in_bytes_per_second .
Conceptually it is easier to think of video storage in terms of play time. However, the DVR module's DVRSink interface exposes a method to allow for the recording size to be specified in bytes. Since video stream samples can be compressed used any number of methods, the DVRSink does not know which particular compression technique was applied to the media samples in stream, but only how big they are in terms of bytes. For this reason, you should calculate the buffer file size using the above formula See also DVRSink::SetBufferSize
A: CopyBufferToFile writes a specified portion of the existing DVR buffer data to a file, while StartBackupToFile starts the writing of future incoming data to the specified backup file.
Also, CopyBufferToFile will take some time and will not return until all the data has been written to the specified file. By contrast, StartBackupToFile will return right away because no data will be written until the next media sample is received. StartBackupToFile will cause all future capture data to be written to the backup file until StopBackupToFile is called.
Note: The target files of these two functions are separate files and care should be taken to not attempt to use the same file for both methods simultaneously.