DTVKit Wiki

DVBCore uses a resource manager for tuners, demuxes, decoders and CA descramblers using an object called a “decode path” (often referred to simply as a path in the code), which is effectively a “handle” to a set of resources that are acquired to perform a particular function, such as watching live TV, recording or playing back a recording, etc. The “live path” is a decode path that has been acquired to tune to a live broadcast signal and, optionally, decode it for output on the screen. Other types of path that can be acquired are recording paths, used when recording on a PVR product, and a playback path for playing back recordings on a PVR. The actual number of decode paths available will be platform specific and will depend on whether PVR functions are provided.

If some form of conditional access system is supported, then the descrambling resource associated with these are also managed using the decode path.

The resource manager code can be found in midware/src/stbdpc.c and stbresmgr.c.The functions in stbdpc.c start with STB_DP and most of them can be used by higher level (DVB or App) code. The functions in stbresmgr.c are used exclusively by stbdpc.c and shouldn't be used by higher level DVB code or an application.

There are a number of functions to acquire, release and query decode paths in stbdpc.h, but for acquiring a live path to view a service a simple convenience function is provided, ACTL_AcquireLivePathForService, defined in ap_cntrl.h, which will ensure the correct type of tuner is acquired in order to view the service.

As decode paths are used for resource management, it’s important that they’re also released when no longer required. For the live path, ACTL_ReleaseLivePathForService is available, but STB_DPReleaseLivePath, STB_DPReleaseRecordingPath and STB_DPReleasePlaybackPath are also available. On a system where multiple tuner types are available, or a conditional access system is being used, a release and reacquire of the live path should be performed whenever the service being viewed is changed to ensure the correct resources are assigned to the path.

The resource manager allows the tuner component of a decode path to be acquired more than once, so if a user is watching a particular service and a recording needs to be started on another service on the same TS, then the tuner resource will be shared between the live decode path and the recording decode path. If the user tries to change channel to a service on the same TS while the recording is in progress, then no tuning is needed and a decode path will be returned that uses the same tuner as the recording path, allowing the service to be viewed. But if the service is on another TS and there's only one tuner then the attempt to acquire a decode path to watch this new service will fail. If another tuner is available, then this second tuner will be acquired to tune to the new TS to allow the service to be viewed. This functionality allows a number of services to be viewed whilst recording is in progress, even if there's only one tuner.

Rather confusingly, the platform code also refers to 'path's, but these are the handles for the separate resources. So when a call is made through an STB_DP function, such as to start video decoding, the platform function STB_AVStartVideoDecoding will be called, but the value of 'path' that's passed to it is the video decoder handle that was acquired when the decode path was acquired.