Configuring Other Components

The MME's behavior can be configured by settings chosen for its components and plugins, and for the QDB, and for some Neutrino components that are external to the MME. This chapter includes:

Configuring other MME components

Information about how to configure the MME component utilities can be found under the relevant sections of the MME Utilities Reference.

Information about some MME component configurations whose effect are most directly visible to MME clients, are described in this section:


Note: For information about how to change the io-media configuration file, see “Updating the io-media configuration file” in io-media in the MME Developer's Guide.

Configuring how io-media handles playback read errors

You can configure the MME's read error recovery behavior to best suit your end user's environment by configuring how io-media handles read errors. You can configure:

To configure io-media's behavior when it encounters problems reading media, you need to configure the io-media module mmf_trackplayer behavior. Syntax is as follows:

For more information, see io-media-generic in the chapter MME Utilities Reference, and Playback read error recovery in the MME Developer's Guide chapter Playback Errors.

Configuring io-media for video

You can configure io-media for optimal video performance on your system. You should use the io-media configuration file to:

For more information about using the io-media configuration file to configure resources, see io-media-generic in the MME Utilities Guide

For more information about how to use video output device modifiers, see Adding modifiers to a video output device URL in the MME Developer's Guide chapter Playing and Managing Video and DVDs.

Configuring the number of video decode threads

Adjusting the number of threads the system uses when decoding video can significantly affect performance, especially on systems with multiple cores. The mmf resource MM_IPP_VIDEO_DECODER_NUM_THREADS is available for configuring the number of threads used for video decoding.

To set the MM_IPP_VIDEO_DECODER_NUM_THREADS resource, add an entry in the mmf_graphbuilder section of the io-media configuration file.

For example:

resource {
    name = "MM_IPP_VIDEO_DECODER_NUM_THREADS"
    type = long
    value = 2
    optional = yes
}

The example above instructs mmf to use two threads to decode the video. This number of threads would be optimal for a single-core Atom processor. Four threads would be more suitable for a dual-core Atom processor "value = 4".

Automatic allocation of video threads

By default, mmf is configured to have the H.264 decoder (ipp_h264_decoder.so) autodetect the number of CPUs on your system and set the number of video decode threads for optimal performance.

To explicitly set the configuration so that the H.264 decoder autodetects CPUs and sets the number of video decoding threads, set the MM_IPP_VIDEO_DECODER_NUM_THREADS resource value to 0 (value = 0).

For more information about using the io-media configuration file to configure resources, see io-media-generic in the MME Utilities Guide

Limiting H.264 profiles

Video processing can be CPU intensive and, depending on the codec profile, may not perform optimally on all platforms. The mmf includes the resource MM_MP4_PARSER_ACCEPT_H264_PROFILE, which you can use to limit the H.264 codec profiles that your system will play; that is, to reject video files with H.264 codec profiles that your system does not have adequate resources to play smoothly.

The default behavior is to play all H.264 profiles. If you set the MM_MP4_PARSER_ACCEPT_H264_PROFILE resource, io-media will reject as unplayable any video files whose profiles you have not specified.

For example, to instruct mmf to decode only files with Baseline or Main profiles, add the following to the mmf_graphbuilder section of your io-media configuration file:

resource {
    filter = "parser"
    name = "MM_MP4_PARSER_ACCEPT_H264_PROFILE"
    type = long
    value = 3
    optional = yes
}

MM_MP4_PARSER_ACCEPT_H264_PROFILE

The MM_MP4_PARSER_ACCEPT_H264_PROFILE resource is a bitfield of playable profiles, as described in the table below:

Profile Value
Baseline 1
Main 2
Extended 4
High 8
High 10 16
High 422 32
High 444 64

MM_MP4_PARSER_*

The MM_MP4_PARSER_* constants define the maximum levels and bitrates permitted for each profile:

io-media strict option

io-media has an optional strict option that limits the parsers it tries to use for a file to the preferred parser associated with the file's file extension. This option causes io-media to fail immediately and return an error if a specified parser fails to identify a file.

Setting the strict implies that io-media rejects files with extensions that do not match their contents, as well as files without extensions; but it improves performance, especially when handling damaged files, because io-media does not waste time sniffing files with every parser in its list or on the system (with each parser taking 10 seconds or more to timeout) before io-media returns and reports an error.

To use the strict option, modify your io-media configuration file (io-media-generic.cfg to include “strict = yes” for each parser for which you want this option. For example:

format {

    url = "*.mp[a123]"
    parser = "mpega_parser"
    strict = yes
}

Note:
  • The strict option is optional; it does not have to be included in your io-media configuration file. However, if you include it, it must be set to yes.
  • To maintain consistent behavior across your system, use the same strict option for all your parsers.
  • You may prefer inconsistent behaviour for your projects. For instance, you might prefer files on a CD-ROM to use a strict policy to speed up failures, but files on a hard drive or a USB stick to be probed more thoroughly because these devices are faster and don't get scratched as easily as CDs. To configure your system for this sort of behavior, you can split the format descriptions information in two, for example, by adding an entry for /fs/cd?/*.mp[a123] before the entry for *.mp[a123].

Configuring the time io-media waits for metadata

An io-media option allows you to set a maximum time io-media will wait for metadata from device, such as an iPod, that manages its own track sessions.

This option applies to the mediafs_2wire graph. The default waiting period is 200 milliseconds.

To configure this option, change the value of metadata-timeout in the io-media configuration file:

module-options {
    module = "mediafs_2wire"
    metadata-timeout = 200
}

How the io-media configuration affects metadata events

The period set by metadata-timeout defines the maximum amount of time io-media waits for a device to deliver metadata.

After a track change io-media waits for metadata from the device. until one of the following conditions is true:

When either of the above conditions is true, io-media sends an event to the MME to indicate to the MME that it should send a MME_EVENT_NOWPLAYING_METADATA event to the client application.

If the device doesn't deliver metadata, io-media continues waiting for it, until either the device delivers metadata, or the track changes.

When the device delivers metadata, io-media sends an event to inform the MME, and the MME sends a new MME_EVENT_NOWPLAYING_METADATA event to the client application.

The client application should query the nowplaying table for metadata after every MME_EVENT_NOWPLAYING_METADATA event it receives. If there is no metadata in the nowplaying table, the client application can display “Unknown *” or another appropriate message string to the user. If metadata is present, it can display the metadata, as required.

Configuring the metadata timeout for your devices

The timeout period can be used to avoid flicker on the HMI screen by having the client application wait an appropriate amount of time before refreshing the screen after a track change.

For example, if a device takes 220 milliseconds to deliver metadata, leaving the metadata-timeout at the default 200 milliseconds will cause the HMI to display “Unknown *” message strings after 200 milliseconds, then 20 milliseconds later refresh the screen with the metadata — causing the screen to flicker for the end-user.

In a case such as this, in order to give the device time to deliver the metadata, you should set the metadata-timeout to 230 (or more) milliseconds. Your HMI can either clear the screen at the track change, leaving it blank for the 230 milliseconds between the track change and the arrival of the metadata, or leave old information on the screen, then update the screen once when it has metadata to display.

Override the default graph for slot types

The MME includes configuration elements that let you override the default graph associated with a slot type. These elements are the top-level <RendererOverride> element, and the <renderer> element. The table below describes the <renderer> element and its attributes:

Element Attributes Default Description
<renderer> storagetype Override the default graph for the storage type specified by the storagetype attribute (if used), at the mountpath specified by mount, and use the graph specified by name.
mount The path for the media whose default graph is to be overridden.
name The graph to use for media at the specified mountpath.

To override the default graph for slot types, add the new elements to the MME configuration file, under the <Configuration>, and set the attributes for the <renderer> element following the example below:

<RendererOverride>
    <renderer storagetype="1" mount="/fs/cd0" name="cam_trackplayer"/>
    <renderer storagetype="5" mount="/fs/shinwa0" name="trackplayer"/>
    <renderer storagetype="1" name="audiocd_player"/>
    <renderer mount="/media/drive" name="diskdrive_player"/>
</RendererOverride>

Note: If the storagetype attribute is not specified, the specified graph is used for all mediastores mounted at the path specified by mount.

Location of io-media DLLs

io-media DLLs All io-media DLLs should be installed in their own, exclusive directory, such as, for example, /lib/dll/media.

No other libraries should be installed at this location, because io-media loads all DLLs from its DLL directory in order to check if it can recognize them as MMF filters or as other Addon Interface (aoi) DLLs. Placing io-media DLLs in a directory with other DLLs, such as for example, /proc/boot, may adversely affect system performance.

For more information about io-media DLLs, see Configuring io-media to use DLLs in the MME Utilities Reference chapter io-media-generic.

Configuring other components

This section describes some important configurations that affect MME behavior and perfomrance.

Configuring the QDB

The qdb SQL database is a core component of the MME system. You can alter its behavior by setting command-line options and setting pragmas.

QDB command-line options

For a complete list of QDB command-line options, see the chapter Starting QDB in the QDB Developer's Guide, which describes the QDB command-line options.

Setting pragmas

PRAGMA is a special command used to modify the operation of the QDB process or to query the library for internal (non-table) data. The available pragmas fall into these basic categories:

For a full description of the pragmas you can set, see the PRAGMA command documentation in the QDB Developer's Guide.

Configuring Neutrino components external to the MME

These components are also used by the MME, but are not covered here. You can refer to their entries in the Neutrino Utilities Reference for configuration and startup information:

Media format support

When you are configuring your MME system, you should make sure that you install all the components required to support the media formats you will be processing. For information about formats supported by third party components and the required MME components for these, see the appendix Binary File Dependencies.