Introduction of web-based signage experiences and bringing up technical issues (Newphoria)

Futomi: Experiences and issues of developing web-based signage JavaScript player

sangwhan: Please use speaker queue. Please login to IRC, type q plus and enter.
... Hatano-san, please

Futomi: We have developed a javascript player
... Which runs on a TV set
... Also developed a CMS.
... CMS can send messages to all connected signage player via WebSocket simultaneously
... At the TPAC hallway, we have shown synchronized displays
... no boxes attached to TV. TV can capable of displaying everything
... Runs on Raspberry Pi 2
... "Architecture and requirements" complient.
... Experimenting on companion devices with Single Board Computer (such as Raspberry Pi) with Microcontroller (such as Arduino)
... Issues: Lack of APIs: state synchronization, Power management, mechanism to use hardware devices directly
... security and Privacy: W3C standards APIs for web browsers used by users. But web-based signage is different in terms of security and privacy
... Web devices designed for specic use -- embedded web
... We'd like to create a WG.

WDS Emergency profile : Status and future plan (ETRI)

Presentation by Sung Hei Kim @ ETRI

SungHei: Architecture and requirements for ...
... Current draft: on requirements
... 1. Classification of severity level for presentation
... 2. Exchanging emergency information
... 3. Presentation of emergency information
... Presentation styles according to severity level
... leve 1 to Level 5, smaller box, gradually larguary, level 5 with sounds
... Usecase 1, sharing emegency information with users' devices

Sung: Usecase 2 : Amber (Alerts or a Child Abduction Emergencies) - TBD

SungHei: Usecase 3: Sharing emergency infromation for effective distribution
... Future plan: Define CSS style for severity level, define more usecases, define requirements, Harmonized with other SDO

Kiyoshi: question: on page 4, how do you device level 1 through level 5?

Report of study on benchmarking Web-based Signage terminals (Roy)

roy: presentation: Study on performance benchmarking for web-based sginage terminals

kaz: Need clarification if you got approval from both KDDI and W3C/Keio about this presentation

roy: yes

roy: Current members: Access, CATS, Computer Engineering & Consulting, Keio, Newphoria, Toshiba

roy: performace benchimarking is improtant for embedded system like web-based signage

<Roy> http://wpb.sakura.ne.jp/WPBtest

<Roy> usrname: wpbtest passowrd: w3ckeiosfc

roy: done: requirements, testing specification, contents guidelines, testing contents
... using CSS transition

(kawada-san demonstrating on projector)

roy: Seven components,: resolution, storage, rendering speed, parallel processing, playing video, playing audio, playing delay time (video / audio)
... Merits of stakeholders
... Collaboratioon with Digital Signage Consortium

Sangwhan: Is develped by who?

roy: developed by Keio
... Performance measurement is relatively new to W3C.

ITU-T Liaison

Kiyoshi: presentation: on ITU liaison statement on web-based digital signage work in ITU-T Q14/16 [to W3C]
... Q14/16 intends to study web-based architecure of digital signage
... Q14 want to harmonize with such W3C's works

Jay: I want to confirm who can respond to the formal letter. BG can formally? or W3C or ... any other?

sangwhan: it's really a formality. honestly I don't know.

<kaz> w3c liaison

kaz: do you know W3C liaison page?

sangwhan: anybody against to the liaison?

kaz: there is already such exists regarding IPTV, and I myself am the liaison contact from the W3C side

sangwhan: I will start mail thread. Just a formality
... Move on to next item: charter.

<kaz> [ITU-T SG16 right?]

About chartering a WG (NTT)/

sangwhan: Link to Draft charter: http://bit.ly/1kKj0RU

"Web Signage Working Group Charter (Working Draft)"

sangwhan: Essentially, based on boiler-plate texts
... essentially tanaka-san composed a list
... go through the charter items, then present W3C AC, W3C as a whole
... out of scope.. anybody fine with this?
... we listed potential deliverables which is long..
... Power Management API: should have API power cycle, but has security issue
... All of specs will be security reviewed
... Understandable we need this, how we can do this is another question.

Hatano volunteered as an editor (for Power Management)

Kihyoshi: yesterday we have break-out session, but there are somebody who haven't attend the session. Thus, we need to describe our intention.

sangwhan: what we want to do is creating a WG charter.

Kiyoshi: These APIs or specs, we select really wanted APIs. ask a opinon to attendees, but we haven't deided, we need to decide

Futomi: He have shown possibilities.

sangwhan: we can remove some features

Kiyoshi: some features are postponed. such as systen context or USBs
... BG members konw requirements on some

sangwhan: we have an hour but this chater is long...

Kiyoshi: we have a slide to list all of the items.
... (showing the slide used at Breakout session yesterday)
... On page 14
... eight APIs: Power management API (no WG), NTP Client API (decided after discussion with Multi-device tiing CG), System Context (decided after discussion in Web-based signage BG), System Event (SysApps WG for service worker issues)
... Multiple resources for video and Multicast video playback (Mediat TF), access control of external storage (Decided after discussion in Web-based Signage BG), Double buffering API (SysAps WG for service worker use)

Back to chater, on Web NTP Protocol

sangwhan: Anybody want to add item, now is the time.

Wook: I just wondered this proposel include screen state. Since screen should be turned off while terminal is powered

sangwhan: Isn't it possible to use sensor?

Wook: there is a regulation on brightness setting

sangwhan: PC based system may or may not work.

Adachi: Device status included?
... memory size, etc..
... memory, CPU and CPU temperature.
... CPU usage

Sangwhan: FireFox OS has. we should take look at that

Futomi: How you can access with help of operating system since signage application runs on userland was a question

Dewa: colorimetry or color temperature might be useful to be added

system events

sangwhan: I honestly have no good idea to how to implement this in a browser.

Multiple resources for video

Futomi: we may skip it.

sangwhan: Who proposed this should visit DASH, since DASH can solve some of them.

ito: we have implemented using object, DASH is not good for our usecase

ito: resolution of panel is getting higher and higher, but the graphics chipset performance is not following well enough

sangwhan: Anybody want to work to resolve with some industrial standard on this?
... We need contribution, withtout such, we have to reduce number of work items.

Kiyoshi: We may list only matured API topics

Multicast video playback

sangwhan: This is valid use case but whether fits here

Ito: Sony has implemented multicast functionality in Bravia
... hard to align with unicast based spec.

Sangwhan: mutlicast don't have URL that's an issue

Ito: video codec selection...
... this can be done with UDP api on user agent.

Sangwhan: Will Sony willing to write a short memo on how video tags can be improved?
... Media task force can work on this, thus ask them

Access control of external storage

Ito: Sony have implemented this.
... actually this is very useful when deploying.
... Sometimes it is difficult to use single shared network to deliver video contents on lot of devices.
... storing large media on to these local media helps.

sangwhan: This is a very valid use case.
... This is the one we should define.

Ito: capacity management API should be implemented

sangwhan: This is the one which does not belong to our charter, because its generic.
... make use of service worker to access these specialzed storage (cache)

sangwhan marked as candidate for removal.

Double Buffering API

sangwhan: I don't think we should define this since there are several way to do this.
... like to remove unless someone want to implement this.

Jay: I still confusing with the word "double"

Fujimura: "double buffering" name came from Java environment

sangwhan: Topic: schedule in charter
... Q2 2016 seems reasonable for FPWD
... Any BG only member?

<sangwhan> scribe: sangwhan

sangwhan: I would like to propose closing the business group.

<inserted> scribenick: shigeya

Futomi: our possible selections are close-BG or create a CG,

sangwhan: How many of BG members joining WG. How manys are not sure

sangwhan: since this require IP commintment, need to consul

aizu: we want to continue discuss use cases

sangwhan: switching to WG does not mean we can introduce new usecases
... WG has IRC and public mailing list to communitate with

Kiyoshi: We can contiue discuss at BG or CG.

sangwhan: WG can.. get usecases, get input, put into chater (next time on recharter) effectively same.

Futomi: (on white board): WG+BG, WG+CG, WG only

<Dewa> https://www.w3.org/community/about/faq/

Jay: It seems difficult to decide now.
... many non-members are not used to post feedback on mailing list.

sangwhan: BG is stay at least for another six months

kaz: Automotive group originated from BG
... Remiding: WG: works on specs, BG: incumbator (CG can be also act as incumbator). CG is free BG require some membership fee

sangwhan: Raise a hand if you're Japanese => most of attendees
... Another questionaire: No one *not post* to mailing list because it's in English.
... Japanese only community group help?
... (possibly in Chinese, Korean..)

roy: I come up with third option.
... how about make a transition period
... while creating WG, keep BG for some short period. in addition, we could have a Japanese CG and I can lead the Japanese discussion

Jay: my concern, may be there are no need to part of W3C.
... its a just a requirement only from Japan. In this sense, CG might be good.
... AC meeting started already at 3..

<kaz> [ afternoon break ]

<sangwhan> scribe: sangwhan

Multi-Device Timing CG

[Francois presenting Multi-Device Timing CG ]

Francois: Some of you might have seen me during WebTV
... I've shared this with a couple members during TPAC
... seems like quite a few are interested
... So who hasn't seen the presentation during WebTV

(people raise hands)

scribe: some synchronization issue experts have been doing this work
... based in a Norwegian research institute
... it is fair to say that the CG is mostly me, them, and a couple others
... the participation is not extremely active, but we are working on it
... I'm helping them convert their ideas into a spec
... although I'm not a sync specialist, but they aren't a web specialist
... in a signage scenario you know better than I do so you can share your experiences/issues with me
... but I believe you will benefit from this
... a few figures you need to keep in mind in the context of sync
... 25ms is frame accuracy
... 10ms is important for audio sync
... human ears can detect sync issues with audio at that threshold
... unfortunately hard in browsers atm
... To synchronize, you need to synchronize clocks
... normally easy to achieve, one device requests other device
... and do this occasionally to stay in sync
... all the deployed clock sync mechanisms are different
... e.g. NTP, PTP, other different standards in DTV contexts such as HbbTV
... all of them start from the same simple idea but differs in implementation
... it's hard to agree on how to standardize on clock sync
... it's possible with a pure JS implementation
... it's not accurate to the microsecond, but is within milliseconds
... which is good enough
... once you have a a synced clock, you distributed the updates across devices
... not very network intensive, you can use WS or HTTP
... hardest part is harnessing the media player
... you need a way to associate your timeline with the media element
... you need to tell it to use my timeline, and use my clock
... this can be somewhat emulated in JS
... there are some demos in the main hall
... some have demos of cross device sync, which are done by some of you

Futomi: Yes, there were some
... I developed things like ntp over websockets, but the precision isn't good enough
... wasn't good enough for lip sync

Francois: From my experience clock sync wasn't the main problem

Futomi: I only developed time sync
... so technically it wasn't enough to get everything in place
... would be interested in making it work with video playback

Francois: Media player harnessing is possible with js but it's hacky
... wasn't actually meant to be used that way

Ito: We've tried this kind of mechanism
... in a video context, it was good enough

Francois: From my experience it depends on the codec and player
... and depends on that
... I'll try a couple demos, so you get a idea of what we have done
... and see if it works or not
... please go to this url
... http://kwz.me/MW
... and when you are all connected let me know
... so this uses a JS implementation from the motion corporation
... it mostly follows the timing object spec
... but it's a previous version
... you should see a clock on your computer
... this will be in sync with what you have on your screen
... next is lip sync demo
... if you have sound on your pc you'll hear audio
... we might hear some echo

<naomi> http://seer2.itek.norut.no/pres/w3c/secondary.html

Francois: when I use trickplay you shouldn't notice that my screen and your screen is out of sync
... final one is what the timing object is about
... when you want to sync stuff you can manually count and press buttons
... but not good enough
... but another way would be to send the command from the control server
... there might be a bit of echo, as the command delivery can be delayed
... there are problems with clock drifting and media element implementation differences
... this makes it slightly better
... it gets synced up as time passes
... might take up to a minute
... atm there is no implementation and is only a draft
... the protocol is not specified
... and you can implement it whatever way you prefer, e.g. by doing ntp over websockets
... here is some example code
... with this simple code you can get everything to play in sync
... we are proposing a extension to the media element for this
... this proposes to replace the media controller to have a better impl across devices
... right now we can play back text tracks only with a media element
... doesn't let you play without a media element
... we are trying to fix this
... that's it for this proposal
... main goal is to make timing a first class citizen in web standards
... Futomi: can you show me page 21 again? (example code)
... what is position and velocity
... it defines linear motion

Wook: When you are using WS, how many concurrent users?

Francois: While I'm not a implementor so I don't have a good answer, the traffic should be fairly low
... because it only transfers messages when a sync or change happens
... WS is just a example, you can use anything

Wook: What about say 10000 users?

Francois: It really depends

Wook: I'm concerned about a centralized system

Francois: That is up to you, the transport is neutral
... and that is why we left it open ended

Ito: What kind of use cases are you looking for?
... In digital signage, the timing reqs depend on the application and situation
... in the spec there are a bunch of UCs mentioned
... it's pretty broad and generic
... but we want maybe up to audio (echo) sync
... video wall isn't there, but should be

Futomi: Is the library open source?

Francois: Not sure. Some are, but some might not be.
... I'll have to check.
... working on a polyfill atm.

[WebNFC demo]

Kenneth: I'm here to show you a demo and share the spec with the group
... spec: http://w3c.github.io/web-nfc/
... this is a basic application, one of the use cases you can do with webnfc
... this is a basic website
... imagine you have items at home and you might run out these things
... and when you don't want to type in everything manually, you can just tap nfc and it'll generate a event
... (showing demo with phone)

<itota> https://www.youtube.com/watch?v=i5CWNMtrrqQ

<inserted> scribenick: naomi

sangwhan: the reason why brought up is
... Japan is big market for Felica
... you just got payment, secure enough
... this tech is can be on laptop
... google contributed chrome
... we got feedback from tag
... use cases is very important

francois: have you considered Service Workers

Kenneth: if you touch tag, browser starts adding items to the cart

sangwhan: questions?
... thanks a lot Kenneth and Riju
... if you have any issues specs, spec has issues

Kenneth: any kind of feed back is appreciated

Riju: what can be specified on the Web

sangwhan: thanks!
... multi-screen will not be solve all problems
... we have to figure out

[showing google docs]

sangwhan: NFC guys show you that technology was standardized
... in poor feasible feature
... could be used for Felica
... Japan as well as Korea uses NFC a lot

Wrap-up

sangwhan: continue to discuss about issues WG, BG or nothing group

roy: how about multi-device timming

sangwhan: system contact is not related

roy: might be get confused. kiyoshi showed candidate API which is NPT client?

sangwhan: the problem doesn't have to be solved

roy: my assumption is one of the usecase, NTT client which create multi screen signage. Other usecases requires a lot of projectors. The method Francois showed includes scopes for our group

sangwhan: they are making CG

roy: talked to Francoi, Motion Control was approved. If we include the proposal into our wg, it might be probable?

sangwhan: motion controller is our member?

roy: no
... good for us to leave time sync

sangwhan: right side for me someone come here to keep mailing list. if they want to join our group, good
... as long as don't have any administrative issues
... seems to be tight, WG creating will take time 6 or more time
... are they in rush? if yes, the WG is not the place for thme

roy: our WG is good for them also
... we can ask Francois on this

sangwhan: if we get consensus from them, it's a good idea. we could use some more ideas

roy: not only Japanese and koreans

sangwhan: will talk to Francois and Ingar

kaz: I'm wondering from which position you are suggesting on this?
... KDDI or Keio?

roy: both
... proposing idea

sangwhan: is the place is appropriate place, will be ok
... back to the BG-CG discussion
... was told that we should have transition period

futomi: if we can charter to create a CG

sangwhan: transition from BG to CG, non-member can participate
... is anybody against to BG to CG?
... any objections? raise your hand?
... to go CG

kiyoshi: timing will be after creating WG
... all BG member can join CG
... no group period will cause confusion

sangwhan: will send a mail to ML
... anyone can answer the WBS
... answer it, it will only take 2 minutes your time.

kaz: so there is a consensus of this group on creating CG

futomi: I can create the expected CG

sangwhan: and I will send a formal questionnairre

Voice interaction with signs (Claes)

Claes' slides

claes: "Voice interaction with signs"
... devices correct language
... some people has difficulties reading
... a lady can't travel by herself
... she can't read, she can't navigate
... main idea is a sign telling you NRF specs

[showing presentation]

claes: into the smartphone, a URL forward you a web page, it could be your language or information you need or can interact using speech recognition or speech sync
... three steps
... 1. discover and select
... 2. downloading of related web content supporting speech interaction
... 3. Navigation or information stream through speech synthesis
... Evolving standards possible to use are discovery, Speech interaction for Web Speech API and VoiceXML
... what is needed in addition is use of low info navigation system
... comments? questions?

kaz: I think I know about this scenario (as the ex-Voice Browser contact :)
... the speech API refered to here is the spec draft of the CG. right?

claes: yes

kaz: just fyi, the speech API is a CG spec draft, so I'm wondering if this signage group is interested in that approach

claes: I don't know it's the right place. guess something could be picked
... maybe not for sign, not complete solution, not standardization today

kaz: two possibilities, 1, speech API, 2. VoiceXML

claes not really sure about voicexml deployment

kaz: voicexml is rather used for server-side like call center these days

sangwhan: bit about sppech API
... services which need API key
... can't be buy, undeliveried. only google can use
... you have access web API thru chromium

claes: there is web speech API

sangwhan: if you could compromise accuracy, could be

fujimura: Speech API CG final report has this

claes: up to you decide if you interested

aizu: sequence of request URL
... point of view for digital signage, it concludes JS, right URL to tag
... it will be useful

aizu: who writes URL to NFC tag?

claes: get the id on a phone
... your you can buy it

aizu: someone needs to write tag

claes: the idea is firm use. one option is firm is one of the functionality of NFC
... with supporting some speech interaction spec

sangwhan: thank you all for coming. we will keep you updates. you will be notified thru email including creating groups
... the charter still needs to be reviewed
... will be also discussed on the sled
... or W3C wiki. you should check

futomi: thank you for your work. chartering WG is quite challenging
... Your cooperation is needed

sangwhan: if WG gets traction, we need to have f2f
... keep you posted. see you guys on the mailing list

[adjourned]