![]() |
![]() |
![]() |
![]() |
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:
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:
![]() |
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. |
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.
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.
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".
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
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 }
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 |
The MM_MP4_PARSER_* constants define the maximum levels and bitrates permitted for each profile:
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 }
![]() |
|
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 }
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.
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.
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>
![]() |
If the storagetype attribute is not specified, the specified graph is used for all mediastores mounted at the path specified by mount. |
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.
This section describes some important configurations that affect MME behavior and perfomrance.
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.
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.
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.
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:
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.
![]() |
![]() |
![]() |
![]() |