[Automotive] QtIviMedia vs QtMultimedia

[Johan Thelin]

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

On 24 May 2016 at 08:51, Marko Kangas <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=
> qt.io at qt-project.org] On Behalf Of Dominik Holland
> Sent: 23. toukokuuta 2016 15:34
> To: 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
> http://lists.qt-project.org/mailman/listinfo/automotive
> _______________________________________________
> Automotive mailing list
> 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/20160524/c5a86f75/attachment.html>