See also: IRC log
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