DTVKit’s Native IP Implementation is an additional module in DVBCore. The architecture of the NIP module is outlined in the diagram below:

The NIP module is compatible with both GSE and MPE delivered NIP streams. The module performs MPE or GSE-Lite HEM decapsulation and FLUTE transport file extraction for NIP configuration files: NIF/SIF/DVB-I and Mutlicast Gateway Config. For chosen services the module then manages the retrieval and caching of the associated DASH MPD and AV segment data. All data is cached in a RAM file store, which is managed by the NIP module the size of which is configurable. Note: Playback of a NIP service is not supported by the DVBCore module and this is left to the application to implement. The NIP service lists and associated AV content can be accessed via native APIs which can also be mapped to a simple http server (e.g. mongoose) to provide http endpoints for service list information and AV (DASH) content.

The NIP module builds as part of DVBCore but to enable it the following options must be configured in the ‘example_setenv.sh’

# Set to 1 and export to enable DVB-NIP. When this is enabled, XML2 is also required export DTVKIT_INTEGRATE_DVBNIP=1

# Export the following values to compile in ADB functions to import/export the service database and specify the location of the libxml2 include directory

export DTVKIT_XML_SUPPORT=1

export DTVKIT_LIBXML2_INCLUDE_PATH=/usr/include/libxml2

In additional the following additional libraries are required in your build environment:

• libxml2-dev

Once these prerequisites are met then DVBCore can be built in the normal way, and it will produce a library with the NIP functionality enabled.

The DTVkit Application can then be built in the usual way for the desktop PC. (See instructions here) The application is able to read transport stream (MPE), or PCAP (GSE) files from the “ts” folder in the App’s root directory. For NIP services the application is expecting a satellite stream, so the file needs to be named as the L-band frequency, i.e. the Ku-band frequency specified on the scan dialog minus the LNB frequency, e.g. for a universal LNB, 9,750MHz for low band, and 10,600MHz for high band.

For example:

• Example: 10847 (frequency in MHz) - 9750 = 1097MHz
• Then, you need to multiply this number by 1000 to get it in KHz
• Example: 1097MHz * 1000 = 1097000KHz
• This is then the name of the transport stream - 1097000.ts.
• Note this is the MPE based NIP services that use a transport stream service.
• For GSE bas NIP streams the naming convention is the same except that the application with expect to read a PCAP file.
  • For the example above for a GSE/PCAP file the name would be – 1097000.pcap
  • The DTVKit App currently only supports Manual tuning for satellite tuning for DVB-NIP.
  • The parameters for the frequency to enter use this equation:
  • Frequency (e.g. 964) + LNB (9750) = 10714

The DTVKit Application does not support native playback of NIP services as these are typically DASH or HLS based. Instead, the NIP module includes a simple HTTP server that makes DVB NIP services available for playback using a web based or standard desktop player such as VLC. The list of DVBNIP services is presented as the index page of the HTTP server together with all files in the RAM file store including the dash MPDs and associated AV segment data.

Steps:

1. Provide list of satellite transponders in the App and select “NIP-search“ type.
   1. DVBCore will look through PMT to identify NIP services.
   2. This will discover MPE services and bootstrap them.
   3. Tune to Bootstrap stream
   4. Receive NIP tables - NIF/SIF/DVB-I Service List Entry point.
   5. Retrieve DVB-I service list, parse and add to NIP client DB.
   6. Services will be unbuffered by default unless you have explicitly requested them to be buffered.
2. For GSE services the home transponder needs to be set after which it will follow a similar bootstrapping process to MPE.
   1. Configurable via the App.
3. Available NIP services can then be determined via call to DVBNIP_ListServices().
4. The NIP engine then remains idle until a [DASH] manifest associated with a service is requested though a call to DVBNIP_GetFile().
   1. The NIP engine then subscribes to the FLUTE stream(s) relating to that manifest.
   2. Downloads the media segments and other files to file store in memory.
   3. If the file does not yet exist, then DVBNIP_GetFile() will initially return FALSE but will then search for the stream to subscribe to and then download it.
   4. Subsequent calls to DVBNIP_GetFile will return TRUE and a FLUTE file read context, which can be read using FLUTE_FileRead().

By default, when a NIP service is identified, the NIP engine will wait for a request via DVBNIP_GetFile() before caching the related AV segments. To have faster initialisation & channel change experience it is possible to override this behaviour, so the AV data is cached sooner. NIP services can be in one of the following states:

• E_DNSS_NOTFOUND - The service was not found
• E_DNSS_NEW - The presence of services is known, but no manifest yet present.
• E_DNSS_READY - The service is ready to start buffering, i.e. the manifest files are cached.
• E_DNSS_BUFFERING - AV segments are downloaded and cached for the cache time, to the limit of reserved memory.

To control / query the status of the service, two API methods are available:

• void DVBNIP_GetServiceStateByURI ()
• BOOLEAN DVBNIP_SetServiceStateByURI ()

These APIs can be used in conjunction with DVBNIP_ListServices () to cache services data at the desired level and offer a faster start/change time. Full details of the APIs are available in DVbCore’s API guide.

All files in the filestore will be cleaned after MAX_AGE_CONTENT (currently 30 seconds), or when the total of all the files exceeds MAX_MEMORY_USAGE, (currently 100Mbytes), and of manifests, when these remain inactive for MAX_AGE_CONTENT seconds, then it removes the media segments, the manifests, and unsubscribes it from the FLUTE session.

Full details of DVBCore’s NIP related APIs and data structure is available in DVBCore’s reference manual documentation. The reference manual can be built using doxygen from the source code, or an online copy Is available https://www.dtvkit.org/wiki/DVBCore_24_10_0_api/html.

Additional platform APIs have been included to facilitate GSE tuning – the extra parameters are needed to tune to these carriers.

• STB_TuneSetGSEMode() - switches the driver layer into GSE mode, providing a callback function to call with full GSE packets.
• STB_TuneSetGSEDataCallback() – callback function to call with full GSE packets.