Digital video recorders (DVRs) take the analog video input from closed circuit televisions (CCTVs), digitize the input using video decoders and then compress this digital data before storing it on a local storage media like hard disk. The critical advantage that DVRs give over tape-based predecessors is that one can process the recorded data much better and perform event search, time search and more to play back specific content.
Key Design Requirements for Low-End DVRs
• Input CCTV channel density – Up to eight channels
• Real-time efficient compression such as H.264
• Storage peripheral support (e.g., SATA, USB, Hard disk)
• High speed I/O peripherals (e.g., Ethernet, USB, PCI)
• Application to generate, capture and search external sensor /motion triggered/ video loss events during recording and playback
• Network streaming for all encoded input channels
• Support for multi-channel mosaic layouts on display devices particularly VGA monitor and TV (analog composite/HDMI/S-video)
In general, a DVR design consists of a general purpose processor for OS and application control, one processor/ASIC for codec (encode and decode) operations, one FPGA or ASIC for display subsystem to support mosaic and multiple video decoder front end to convert analog input to digital.
We found DM36x to be significantly useful for DVR applications, and it could easily replace all the above processors/ASICs with just one SoC. The DM36x has an ARM® processor running from 300 MHz to 432 MHz which is used for running Linux OS, filesystem and application/GUI. It has embedded hardware accelerated engines to perform H.264 encoding and decoding and support the requirement of eight-channel CIF real-time operation. It has a set of hardware modules which make Video Processing Subsytems (VPSs) and can generate any level of mosaic layouts such as 2x2, 3x3, 8CH from the input channels.
The overall block diagram of the DVR reference design built on the DM365 with TI’s TVP5158 used as a video decoder is shown in Figure 1.
The DVR application is a multi-thread architecture that allows multi-channel capture, color-conversion, resizing, encoding, display, file-write, file-read and decoding, which all happen in separate threads. This architecture allows all the operations to run in parallel because most of them are using hardware engines and do not need ARM MIPs.. The multi-thread architecture is shown in Figure 2.
The key aspects of software design for DVR design on DM365 are listed below:
• TVP5158 provides data in lined, interleaved mode for different input channels. The multi channel capture task has to first demultiplex this interleaved data and then place it in the different data buffers for each channel. The demultiplexing thread uses minimum CPU for this processing and uses internal DMA engine to transfer the buffers. This is a time-critical operation, or else the input frames would be lost.
• As multiple channels are being encoded and recorded simultaneously, there would be a great level of hard disk access if a proper file management layer was not used. Also, for playback, the data read can happen from anywhere on the disk, corresponding to the playback start time. To achieve minimum hard disk seeks (which causes lot of delay), we designed and used a proprietary file management system. In this file manager, we open single file (called a basket) for all channels. All the channels’ encoded data is interleaved and stored in this basket. There is an index file for each basket to know the exact position of an encoded frame for a particular channel. The metadata for each frame stores the information about any event associated with that frame.
DM365 Digital Video Recorder Reference Design [http://www.focus.ti.com/docs/toolsw/folders/print/dm365dvr-ud1.html]