[Automotive] QtIviMedia vs QtMultimedia

Tue May 31 14:54:02 CEST 2016

Sounds good to me. I also think that making separate module doesn’t really make sense in this case.

Also making the searching, browsing and indexing more generic and adding it as a part of core sounds like the way to go.

-Kalle

From: Automotive <automotive-bounces+kalle.viironen=qt.io at qt-project.org<mailto:automotive-bounces+kalle.viironen=qt.io at qt-project.org>> on behalf of Yoann Lopes <Yoann.Lopes at qt.io<mailto:Yoann.Lopes at qt.io>>
Date: Tuesday 31 May 2016 14:46
To: Johan Thelin <johan.thelin at pelagicore.com<mailto:johan.thelin at pelagicore.com>>
Cc: "automotive at qt-project.org<mailto:automotive at qt-project.org>" <automotive at qt-project.org<mailto:automotive at qt-project.org>>
Subject: Re: [Automotive] QtIviMedia vs QtMultimedia

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/automotive/attachments/20160531/5586f5dd/attachment.html>