From johan.thelin at pelagicore.com Tue May 24 14:41:27 2016 From: johan.thelin at pelagicore.com (Johan Thelin) Date: Tue, 24 May 2016 14:41:27 +0200 Subject: [Automotive] QtIviMedia vs QtMultimedia In-Reply-To: References: Message-ID: 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 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: From Yoann.Lopes at qt.io Tue May 31 13:46:52 2016 From: Yoann.Lopes at qt.io (Yoann Lopes) Date: Tue, 31 May 2016 11:46:52 +0000 Subject: [Automotive] QtIviMedia vs QtMultimedia In-Reply-To: References: Message-ID: <85725531-346D-44A5-B761-B04A273C4713@qt.io> 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 > 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 On 24 May 2016 at 08:51, Marko Kangas > 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: From kalle.viironen at qt.io Tue May 31 14:54:02 2016 From: kalle.viironen at qt.io (Kalle Viironen) Date: Tue, 31 May 2016 12:54:02 +0000 Subject: [Automotive] QtIviMedia vs QtMultimedia In-Reply-To: <85725531-346D-44A5-B761-B04A273C4713@qt.io> References: <85725531-346D-44A5-B761-B04A273C4713@qt.io> Message-ID: 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 > on behalf of Yoann Lopes > Date: Tuesday 31 May 2016 14:46 To: Johan Thelin > Cc: "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 > 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 On 24 May 2016 at 08:51, Marko Kangas > 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: From johannes.oikarinen at qt.io Tue May 31 18:49:24 2016 From: johannes.oikarinen at qt.io (Johannes Oikarinen) Date: Tue, 31 May 2016 16:49:24 +0000 Subject: [Automotive] QtIviMedia vs QtMultimedia In-Reply-To: References: <85725531-346D-44A5-B761-B04A273C4713@qt.io> Message-ID: <8470C66B-0311-4A2D-95F9-6BC92225C889@qt.io> +1 I?m also thinking the same; let?s add what can be added to existing modules. As for changing the actual multimedia backend in QtMultimedia/QMediaPlayer, perhaps this could be a feature to add to future releases? -Johannes From: Automotive on behalf of Kalle Viironen Date: Tuesday 31 May 2016 at 15:54 To: Yoann Lopes , Johan Thelin Cc: "automotive at qt-project.org" Subject: Re: [Automotive] QtIviMedia vs QtMultimedia 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 > on behalf of Yoann Lopes > Date: Tuesday 31 May 2016 14:46 To: Johan Thelin > Cc: "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 > 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 On 24 May 2016 at 08:51, Marko Kangas > 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: