ABSTRACT:
This theses covers the design and implementation of recording functionality for a set-top box in a home network. An initial investigation is done and possibilities for extending the system to support specific features are presented.
Digital TV is becoming more common each day, and soon it will be more widely used than todays analogue standard. At the same time the need for recording TV shows remains the same or is increasing, which is shown by the number of PVR solutions popping up on the market.
The goal of this thesis work was to investigate the possibilities for extending an existing set-top box to support common PVR features and, if possible, to implement a prototype. This was supposed to be done in a home network environment with the set-top box as the digital media center.
A satisfying solution, covering basic recording functionality is defined and implemented. The solution includes recording to a USB hard drive and to a PC on the local network. On top of this, a graphical user interface is built and some simple benchmark show the performance of the set-top box with the new functionality.
EXISTING SOLUTIONS SURVEY
Background:
PVRs are becoming quite common today and some attempts at standardisation have been done in the area. Main organisation for standards in this area is the tv-anytime forum, http://www.tv-anytime.org/.
TV-Anytime:
TV-Anytime members have produced a number of requirement specifications, and other documents. However, most of the documents target the entire “content provider”—PVR scheme and are therefore to high-level and out of the scope for this project. Another, well debated subject is business models, broadcast models and the way they interleave with each other. There are however more detailed specifications, but those target ECG and metadata handling and are not applicable to this project.
Existing Products:
Right now we are in the middle of a PVR boom, with new products presented more and more often. A look at these products can be of benefit for both “feature ideas” and to see what customers expect of a PVR today. As an example, we can assume that a customer won’t accept a solution without a functionality of a common VCR.
Storage:
There are several possible solutions that can be used for storing recorded data and some of these are discussed. However, all PVRs that were looked into in this survey use a built in hard drive for storing content.
CURRENT SYSTEM STATE AND REQUIREMENTS
Overall System Description:
From a user perspective, the set-top box looks like a common consumer electronics appliance. It is controlled via a remote control or a wireless keyboard. The set-top box and the remote control.
System Hardware:
The set-top box today is a product of design that prioritises small size, low energy consumption and relatively low price. This has several effects on the box:
- The box is quite small, i.e. no place for a hard drive in the current design.
- The shell is not designed for hot and noisy elements.
- The box is quite cheap compared to external hard drives.
Software:
The top layer shows user applications. Below this layer there are services and at the bottom we have the operating system and the set-top box hardware.
The System Software Divided in Layers. Modules of Particular Importantance for this Project Are Coloured Pink.
Requirements:
Previous chapter gives insight into how large this area really is making a really good PVR takes a lot of time, and this project is limited to 20 weeks full-time work, including writing the report. Therefore the focus will be on implementing the basic recording functionality and thus test how well the system can be extended to support recording.
SYSTEM ARCHITECTURE
Extending the Streamer:
Since most of the work on this thesis will be extending the streamer, streamer architecture is also the most important architectural decision to make. In following sections streamer models are discussed and one of the modules is chosen for this project. These models show only the part of the element chain where the recording element is inserted.
Extending the System Architecture:
To make use of the new, extended streamer it is necessary to extend the overall system architecture. It show the current state of the system. The general idea is to add a user-level application to handle recording. This application will be accessible to the user directly or via other user-level applications such as the TV application. Communication between the pvrdk which is our new application, and other user-level applications will go through the URI loader.
Implications to the Chosen System Solution:
There are actually two solutions since the streamer, and hence the system, will support writing to both an USB disk drive and to a computer on the local network. Accessing the files stored on a local file-system can be done through standard libraries, but access to the files on LAN is a bit trickier.
DESIGN AND IMPLEMENTATION
Modules:
A home system capable of recording could look as shown in figure 5.1. Recorded streams can be saved on the USB hard drive that is directly connected or on a PC in the local network. Depending on which solution is used, different software is needed for a functioning system. A streamer element is necessary in both a hard drive and a PC based solution. This new streamer element will from here on be called diskwriter element.
Conceptual View of a Recording Capable Home System. the Set-top Box Can Record Streams Both to a Directly Connected USB Hard Drive and to a PC in the Local Network.
Remote File System Protocol:
This section will only describe the protocol and not any implementation of it. Some implementation-specific details might end up in this chapter, but that is only as a side effect to describing RFSP. RFSP is designed for this thesis work for transfer of files between the set-top box and a server on the local network.
RFS Server:
The server has to be extendible (easy to add new commands/responses) and reconfigurable (e.g. easy to add a preprocessing function for data that is written to disk). Also, different sessions have to do different things with the incoming data, e.g. file transfer session and command session have to save data to disk respectively parse client input.
RFS Server Can Be Viewed as the Depicted Modules, When Data Parsing Is “used as a Divider”. Note That Only the Command Session Uses Command Parsers, but All Types of Sessions Use a Data Parser.
Diskwriter Element:
This code module is one of many loadable code modules that will be loaded in the streamer for stream processing. As such, there are some restrictions on this element which will influence the solution to this problem. The most important ones are:
- The streamer is single threaded (and therefore)
- All I/O must be nonblocking
FUTURE WORK
The problem considering blocking file I/O is described. There are at least two ways of solving this problem, by modifying the Linux kernel to support nonblocking file I/O or by adapting the system by introducing a File writing service.
Source: Linkopings University
Author: Aner Gusic
>> More Wireless Energy Projects for Final Year Students