W3C

Automotive Working Group Teleconference

26 Apr 2017

See also: IRC log

Attendees

Present
PatrickB, Ted, Gunnar, Rudi, Paul, Joel, Jeff
Regrets
Chair
Paul
Scribe
Ted

Contents


PatrickB: software should run on different platforms, at least mac and windows, including playback
... you need MS' visual studio to recompile the lame decoder
... it doesn't need any user interaction, nor need to launch a separate client as is the case with VLC
... I'll focus on the media library so people can browse tracks
... potentially will be able to extract images as well for cdn

Rudi: I did similar for VLC and Python for a JLR demo
... I didn't need to start VLC separately

PatrickB: I didn't try it but that was my understanding from the docs, I needed to start VLC in server mode

Rudi: I had standard VLC installed and the related libraries and it could start up fine
... worked fine with local and audio but was problematic with youtube url
... unsure what the Python binding was

PatrickB: that would be helpful

Rudi: I have about 5 lines of Python code I can send you

Ted: Patrick, I think you dropped off last week before Joel touted how VLC might be a better choice than lame

Joel: only real problem is dealing with codecs

PatrickB: I think BMW and others use Cinemo

Joel: I believe it is derived from VLC
... at least that is what Steve (INRIX) was telling me

Paul: that is widely used by Tier 1s

Gunnar: VLC I believe is GPL so that might be difficult for proprietary software

Ted: depends if they are only using the libraries and separate code levaraging it or have a wrapper

Gunnar: there will be differences with production environments but as long as the bindings make sense you should be fine

Joel: you can multiple media player drivers and select which

Gunnar: Genivi has a generic media interface
... you might want to take a look at it

Joel: I'll check it out

Gunnar: we have it split into player, control and indexing
... probably similar to ViWi

Paul: playback, browsing, sorting, more metadata manipulation and phonetization

[[amusment at the word

Phonetization \Pho`ne*ti*za"tion\

(f[=o]`n[-e]*t[i^]*z[=a]"sh[u^]n; 277), n.

]]

<Paul> https://www.w3.org/community/autowebplatform/wiki/IVI_LBS_UseCases_And_Comparison_with_GENIVI%27s

PatrickB: for our meeting in May, I hope we something we can play around with

Joel: there are references to web sockets throughout the documentation but only end points for media

PatrickB: you'll send a subscribe message to that endpoint and get updates when it changes
... there is a statement in each service where you can subscribe to endpoint or element unless noted otherwise, example being not being able to subscribe to every geo location in the world
... that is a convenience method to avoid having to repeatedly poll for changes

Joel: if someone targets an endpoint with a POST then the server implementer needs to to consult subscriptions on clients to notify

PatrickB: correct
... web socket and HTTP are separate so as developer you don't have to worry about the protocol

Joel: say I want to strictly do sockets, open up pipe and...

PatrickB: you can't

Joel: so you can only optionally subscribe to an end point

PatrickB: that is a good way to describe it
... subscription is for asynchronous callback

Paul: last week we talked about reviewing LBS use cases, I dropped a link to the work Qing An (Alibaba) did
... there is quite a bit more than I think we want to go over but they are well organized and granular
... high level use case is to find a POI and either route to it or merely show on a map

https://www.w3.org/community/autowebplatform/wiki/IVI_LBS_UseCases_And_Comparison_with_GENIVI%27s

Paul: basic get POI and route to it is covered in Genivi

PatrickB: we should go over the use cases and see how to represent them. in these where you see a clear get that defines a potential object
... what might be difficult is to implement is showing points on map, routing but we can start building the API for that
... we can POST to map the POI we want displayed

Gunnar: it sounds like you are thinking of creating this API now and presupposing that the REST based model is the right one
... with modifiable attributes. it is an interesting exercise but it is quite an assumption when RPC calls might be more suited

PatrickB: we have implemented this and know it is feasible and more flexible than RPC
... we built use cases after we got the implementation from the supplier
... we cannot share it however
... for LBS you need a powerful, production engine to really be able to see the capability

Paul: what about things like OSM or Mapbox?

PatrickB: I'm not familiar with them but we can check it out

Gunnar: it takes a long time to get navigation suppliers to agree to an API and it is a struggle

PatrickB: absolutely
... maybe for some simpler use cases it might be possible to use Google or Bing Maps API

Paul: that was why I threw out Open Street Map and Mapbox

Gunnar: as far as making a proof of concept there are different options
... we have found Navit maintenance go through periods of activity and neglect
... proving an API can be done with that however

Paul: we're just aiming for proof of concept at this point and Philippe Colliot may have something we can leverage

Joel: it would be good to have the various provider APIs side by side and then see how what we have stands up

Gunnar: we have wrestled with the commercial providers for years, you won't get them so readily

Joel: then we focus on those who are more willing to provide public information about their APIs
... those who use other solution will have more work to bind them or come back to us

Gunnar: standards in this space is what we're all after

Joel: I want to avoid the fools errand of doing a proof of concept for something as complex as maps that won't work with the commercial solution

Paul: we need to come up with something useful and it may take more work for some to align with it than others

[discussion of trying to get some to the table, Ted suggests he and Gunnar take action to reach out and welcome others doing same or sharing contacts]

Gunnar: Philippe Colliot will have more insight. we have some very good relationships in Genivi with a number of providers

https://lists.w3.org/Archives/Public/public-autowebplatform/2017Apr/0024.html

[discussion on finding Genivi's POI documentation]

https://lists.w3.org/Archives/Public/public-automotive/2017Apr/0006.html

<Paul> https://github.com/GENIVI

Gunnar: code and documentation are open, only the compliance program is limited to Genivi members
... UML is also member only

Paul: I'll read these and encourage others to as well
... other actions?

Ted: based on the meeting Rudi was going to share some VLC code with PatrickB who will look at that instead of lame. I'll talk with Gunnar about Nav providers active in Genivi and reading up on Genivi LBS

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/04/26 21:08:10 $