QNX CAR Multimedia Architecture

The QNX CAR Platform uses many components to support the media tasks of synchronizing databases with mediastore contents, browsing mediastore filesystems, and playing audio and video files.

To carry out user-requested actions, the Media Player HMI app sends commands to the mm-player server. This server uses other services, shipped with either the QNX CAR Platform or the QNX SDK for Apps and Media, to access mediastore filesystems and browse and play media files. Also, mm-player synchronizes the contents of databases managed by the QNX Database (QDB) server with the metadata found on attached devices (mediastores).

The information flow between the components looks like this:

Architectural diagram showing HMI components, multimedia services, and OS services that work together to support media synchronization, browsing, and playback
Figure 1. QNX CAR Multimedia Architecture


As Figure 1 shows, communication between and within the HMI, multimedia components, and OS services layers is handled by native extensions, C APIs, QDB databases, and the Persistent Publish/Subscribe (PPS) service.

On CAR systems, the PPS and QDB services are running by default. This way, the user can initiate media actions as soon as the HMI loads. The components in the various layers will then forward the appropriate commands and data amongst themselves to perform the requested operations.


This release includes both an HTML5 and a Qt5 version of the HMI. The HTML5 HMI includes the car.mediaplayer WebWorks extension, which provides a JavaScript API that the Media Player app uses to send media requests to mm-player. In the Qt5 HMI, Media Player communicates with mm-player through the QPlayer library, which provides a Qt5 API for issuing media requests.

To customize media browsing and playback, you can modify the reference media player shipped with the platform or write your own media apps. In addition to the WebWorks extension and Qt library, your apps can directly call the C API of mm-player. All three interfaces—car.mediaplayer, QPlayer, and the mm-player C API—define functions for:
  • retrieving a list of accessible media sources
  • retrieving track metadata (e.g., artist name, album name, track title)
  • starting and stopping playback
  • jumping to a specific track during playback
  • handling updates in playback state, media sources, and track postion

The functions defined in these interfaces aren't specific to any device type, which allows your apps to work with a wide variety of media hardware and also simplifies their design because most of the application logic is handled by mm-player.

Multimedia components

The mm-player service is a media browsing and playback engine that processes commands sent by HMI apps through the car.mediaplayer extension. To support different device types, mm-player uses plugins. Each plugin interfaces to a particular device type to carry out media operations. For example, suppose you insert an SD card. The POSIX plugin supports this type of device, so it detects the SD card insertion and informs mm-player of the newly connected media source. This same plugin will then be used for all media operations on the SD card. For more information about mm-player plugins, see the Media Player Plugins chapter in the Multimedia Player Developer's Guide.

The following services support the operations of mm-player:
Discovers media devices and initiates synchronization of metadata.
Synchronizes metadata from tracks and playlists on media devices into QDB databases.
Plays audio and video tracks, and reports playback state.
Starts audio drivers to enable outputting of audio streams through hardware.

OS services

Device publishers provide information about attached devices through PPS. When the user attaches a device to their in-car system, the appropriate OS services inform the device publishers, which then write device information (e.g., mountpoints) to PPS objects in a directory monitored by mm-detect. The mm-detect service uses this information to start synchronizing the new device's metadata.

Other OS-layer components, such as the filesystem mounting service and various resource managers, support specific mm-player plugins.