[Automotive] QtIviMedia vs QtMultimedia

Dominik Holland dominik.holland at pelagicore.com
Thu Jun 2 13:38:06 CEST 2016


Hi,

as the indexing,searching and browsing would be the most part of the
api, i think the overlap is quite thin. It's really only the basic
toplayer player api which is needed, nothing from the underlying
qtmultimedia backends or the audio-managment/camera etc. is used.

I already started with the design of it and have a prototype of it. I
still think the module makes sense to have and as it's part of qtivi it
has a completely different architecture and also a different scope.

qtivi is meant for system-ui development in the automotive space and
just provides you a core of apis which can be extended by the OEM. Most
of the OEMs don't do the backend development by their own. Instead they
just define an IPC and define that this needs to be used. This means
it's not possible reuse one backend of a OEM by another OEM. The feature
sets are also totally different and the goal here is not to provide a
full-featured API with a working backend. We just provide a skeleton for
the core aspect of the usecases and a simulation backend. Everything
else needs to be done by the OEM himself. For media this means, there
will be a basic player api for play/stop/next/previous the media and
it's basically translating these calls almost one to one to a
backend-interface which makes the API very thin, but easy to extend by
the OEM.

Usually the qtivi backend is then calling a OEM specific IPC calls to a
OEM specific implementation of the actual mediaplayer. This mediaplayer
is then implementing all the needed interfaces e.g. browsing, searching,
sharing, indexing, usb-device discovery, apple device discovery, DLNA etc.).

I don't think it would make much sense if the backend for the
media-player would be half implemented in qtmultimedia (for the
mediaplayer part) and the rest (browsing, search, indexing...) is
implemented as a backend in a separate repository with no direct way for
the two plugins to interact with each other.

The same goes other APIs needed in the automotive space, which may fit a
little bit with qtmultimedia, but it's hard to make it easy for the OEM
to write the backend and extend them. E.g. camera. QtMultimedia has a
camera api so we should try to reuse it, but this camera api is intended
for app developers to control the camera settings like exposure... and
maybe take photos or videos.
The rear-view camera of a car needs a totally different api, because the
exposure and settings like this are not exposed to the UI at all, this
is done by some backend which talks directly to the camera. The camera
is usually controlled in connection with some other sensors and comes as
a hardware-composited overlay. How surfaces like this are integrated in
QML (and whether they are) is also different by every OEM.

As QtMultimedia is supposed to work on all the tier-1 platforms i guess
the API should work on the tier-1 platforms as well, which means we
would need a backend which supports the playqueue management and all the
other features we need to support in automotive there as well. Otherwise
we would introduce APIs in QtMultimedia which you can't test on any
platform as there is no backend implementing them. I also think that
when introducing a full set of new features into the existing API we
might break a lot of things.

I would see the qtivimedia module similar to other existing apis like
qtgstreamer or phonon in the old days, which tries to solve a different
problem and may overlap a little bit with other APIs.

So i would propose to see the QtIviMedia apis as a test-balloon and see
whether the dynamic backend changing, the browsing and api works as such
and then think about moving features back to QtMultimedia and replace
our apis with them. This can be done as QtIvi will have it's own version
similar to the QtVirtualKeyboard and we can increase the version number
if we see a need to break the compatibility.

Dominik

Am 05/31/2016 um 01:46 PM schrieb Yoann Lopes:
> Hi,
> 
> I think it would make more sense to add the missing APIs to QtMultimedia
> rather than create a new module. That module would be redundant for the
> most part.
> 
> The only part that could make sense to be in a separate module are the
> media searching/browsing/indexing. Actually, I’d make that more generic
> to handle different kind of files and put it in QtCore.
> 
>> The reason for this is that it is common in IVI systems to have
>> out-of-process media rendering engines and we don't want to integrate
>> them as QtMultimedia backends as they really do not fit.
> In what way don’t they fit? The backend API could be extended to handle
> this case if there’s just no way to do it currently.
> 
>> Yoann
> 
> 
>> On 24 May 2016, at 14:41, Johan Thelin <johan.thelin at pelagicore.com
>> <mailto:johan.thelin at pelagicore.com>> wrote:
>>
>> Hi,
>>
>> I would say that QtMultimedia is for in-process media rendering, while
>> QtIVIMedia is about media indexing/browsing and out-of-process
>> rendering. Of course QtMultimedia can be used to implement a rendering
>> backend support in-process rendering, but that is not at the top of
>> the list right now.
>>
>> The reason for this is that it is common in IVI systems to have
>> out-of-process media rendering engines and we don't want to integrate
>> them as QtMultimedia backends as they really do not fit.
>>
>> Best regards,
>>
>> ---
>>
>> Johan Thelin   ヨハン  テリン
>> M.Sc.E.E.
>> System Architect
>>
>> PELAGICORE | Experience Change
>> Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
>> Mobile: +46 (0)700 900 250
>> Skype: jothpelagicore
>> E-Mail: johan.thelin at pelagicore.com <mailto:johan.thelin at pelagicore.com>
>>
>> On 24 May 2016 at 08:51, Marko Kangas <marko.kangas at qt.io
>> <mailto:marko.kangas at qt.io>> wrote:
>>
>>
>>     I think this should be discussed also with QtMultimedia maintainer
>>     Yoann Lopes (cc).
>>
>>     I'm not decision maker but in general I think we should use API
>>     and module we already have. Just extend it to fill automotive
>>     purposes. But I don't know details if it's not doable and there's
>>     some specific issues then it might be relevant to think separate
>>     API. It just might be confusing why to have several similar sound
>>     APIs.
>>
>>     Yoann, could you check mail below from Dominik. Maybe you have
>>     some opinion from the QtMultimedia side?
>>
>>     Br, Marko
>>
>>
>>
>>     -----Original Message-----
>>     From: Automotive [mailto:automotive-bounces+marko.kangas
>>     <mailto:automotive-bounces%2Bmarko.kangas>=qt.io at qt-project.org
>>     <mailto:qt.io at qt-project.org>] On Behalf Of Dominik Holland
>>     Sent: 23. toukokuuta 2016 15:34
>>     To: automotive at qt-project.org <mailto:automotive at qt-project.org>
>>     Subject: [Automotive] QtIviMedia vs QtMultimedia
>>
>>     Hi,
>>
>>     according to our roadmap, one of the next things are the
>>     development of
>>     RadioTuner APIs and to support all automotive multimedia usecases.
>>
>>     The first thought for this would be the QMediaPlayer and the QRadio
>>     classes which are part of QtMultimedia.
>>
>>     The last week i did a gap analysis and checked the classes and the
>>     backend interfaces for whether they support all the automotive
>>     features.
>>
>>     The outcome is the following:
>>
>>     QRadio:
>>     * No support for background scanning
>>     * No interfaces for DAB, SDARS (satelite), HDRadio
>>     * No interfaces for a DB to save favorite stations (presets) or
>>     already
>>     scanned stations
>>     * No metaData support (RadioText +, DAB media content)
>>     * No announcment system
>>     * No way to browse Channel categories
>>     * No way to search for stations
>>
>>     QMediaPlayer/QMediaPlaylist:
>>     * No way to change mediabackend from QML (e.g. switch to control the
>>     playback on my mobile phone)
>>     * No way to get all available media backends
>>     * MediaPlaylist only stores the urls, but not the metadata, this is
>>     retrieved only for the current file playing
>>     * No API for managing multi playlists
>>     * No media browsing api
>>     * No media search API
>>     * No Indexing control API
>>
>>     I think the QtMultimedia APIs are really meant to be
>>     cross-platform and
>>     should give the developer an easy way to playback their media content
>>     and integrate it into their own Application.
>>
>>     The QtIviMedia APIs on the other hand are more meant for system
>>     developers to use an underlying system MediaPlayer and also have
>>     in mind
>>     to control other devices like a connected mobile phone (bluetooth)
>>     or a
>>     RSE system.
>>
>>     Because QtMultimedia doesn't offer all the features we need and we
>>     need
>>     the new APIs soon, i would propose to do the QtIviMedia development
>>     without using QtMultimedia classes in the developer facing APIs.
>>     For the
>>     simulation APIs i think it's very valid to use the QtMultimedia
>>     APIs to
>>     make the simulation work on every development system.
>>
>>     Do you all agree with that ?
>>
>>     Best Regards
>>      Dominik
>>
>>     _______________________________________________
>>     Automotive mailing list
>>     Automotive at qt-project.org <mailto:Automotive at qt-project.org>
>>     http://lists.qt-project.org/mailman/listinfo/automotive
>>     _______________________________________________
>>     Automotive mailing list
>>     Automotive at qt-project.org <mailto:Automotive at qt-project.org>
>>     http://lists.qt-project.org/mailman/listinfo/automotive
>>
>>
> 

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holland at pelagicore.com
www.pelagicore.com



More information about the Automotive mailing list