W3C

- DRAFT -

Web and TV Convergence workshop

12 Mar 2014

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Daniel

Contents


Introduction by Philipp Hoschka



<dsr> scribenick: dsr

The Web is 25 years old, let's make history today!

Let's put the Web and TV together!

Philipp introduces the goals of this workshop.

W3C is also celebrating its 20th year.

W3C is expanding our reach into new areas, e.g. TV and automotive,

Today we will focus on Hybrid TV and multi-screen.

Tomorrow, we will continue on multiscreeen then focus on ongoing work and upcoming topics.

Finally, we will try to prioritize next steps.

The major players are here at the workshop, and come from all over the World.

This is a great opportunity to exchange ideas,. I would like to thank our host IRT and our sponsor NBCUniversal, and lastly our reviewers.

Welcome from IRT

Ralf Neudel welcomes everyone to IRT. We are a research institute working for public broadcasters.

The convergence of the TV world and the Web world is very exciting for us!

We see a lot of excitement about the prospects for the convergence, after an early phase of trepidation.

It took radio 30 years to reach the same audience that the Web reached in 3 years.

Have a great workshop and let me pass you back to Philipp.

Introduction to W3C Process and Terminology

Work at W3C typically starts with a workshop which often leads to a Community Group or a Working Group.

Working Group's drive specifications to standards (W3C Recommendations).

Our working groups are open and welcome feedback from the public.

Community Groups are free and you don't need to belong to a W3C Member.

We have Interest Groups e.g. the Web and TV Interest Group -- http://www.w3.org/2011/webtv/

The Working Group process progresses specifications from Working Draft to Last Call Working Draft (when a spec is mature and stable).

This is followed by a Candidate Recommendation where we look for implementation feedback. This is followed by a Proposed Recommendation where we seek review from the W3C Advisory Committee, and the spec then becomes a W3C Recommendation.

Question: how does the implementation feedback work?

Answer: we provide a set of tests against which implementations can be assessed.

Web & TV IG Overview

See http://www.w3.org/2011/webtv/

Guiseppe Pascale introduces the goals of the interest group as set out in the charter:

http://www.w3.org/2012/11/webTVIGcharter.html

Interest Groups are not the same as Working Groups. The former focuses on requirements and input for working groups.

We work through email with an archived list.

We start with use cases, and extract requirements. We then perform a gap analysis on what's missing from existing standards.

This work is usually done on task forces that address a specific topic.

We may issue bug reports, e.g. against the HTML specification, or we may propose work on a new API.

This may in turn lead to a new working group being set up.

The home network task force (now closed) addressed local discovry and control of devices in local area IP networks.

Opera and Cable Labs then proposed an API to the W3C Device APIs WG.

We got some review by implementers and the Privacy Interest Group and adjusted the API accordingly.

The Media Pipeline task force (now closed) focused on improving the HTML5 media pipeline, e.g. for support for multitrack.

The media source extensions and encrypted media extensions appeared as a result of this task force.

These are being driven along the standards track in the HTML WG.

The testing task force (now closed) focused on testing, use cases and requirements.

The timed text task force (now closed) focused on facilitating use of TTML and WebVTT for subtitles.

Close collaboration is recommended for these two approaches.

The charter for the Timed Text WG is currently under review.

Finally, the media APIs task force (ongoing), which focuses on recording and downloading of media, discovery and control of device capabilities.

We are discussing what it means to integrate with the tuner.

We have also looked at what changes are needed for other related specs.

All of this depends on people actively engaging with the work! We need your help.

Questions?

Question: to what extent the feedback from the testing task force have been adopted?

Philipp: there is two levels of testing at W3C. The first is a test for each feature of a spec. We are planning on component testing -- this looks like it would be quite expensive and looked for funders without success.

We will keep this plan on the shelf but are not actively looking for funders anymore.

So whilst we remain focused on spec feature testing, we are not actively working on component testing right now.

Guiseppe: W3C is working on the test framework.

Bryan: contribution based approach and encouragement through test the web forward events.

<ddavis> http://www.testthewebforward.org

Question: any idea on the roadmap for the tuner work?

Guiseppe: we're looking for greater involvement to help move this forward. May be one year to produce a stable spec?

Depending upon how broad the requirements, we may proceed in two phases, based upon the priorities for individual features.

Clarke: the speed depends on the people involved -- if this matters to you please join us!
... we break for coffee and demos

<ddavis> Scribe: Daniel

<ddavis> scribenick: ddavis

Session 2 - Hybrid TV

kirk: I'm going to talk about HbbTV - reinventing the broadcast TV UX
... I'll give you an overview of what HbbTV is about.
... 5 or 6 minutes.
... HbbTV started in 2009 to provide a more interactive experience for consumers.
... Meant to be a platform across regions around the globe.
... Business drivers are the analog switch off, consumer demand, broadcaster innovation, government initiatives and pay-TV operators.
... Adoption in Europe is shown on the screen.
... We're starting to see international adoption as well, still building in recent weeks.
... ASBU (equivalent of EBU for Arabic countries) is also adding HbbTV to its DTT recommendations.
... As well as interest in French-speaking African countries and Australia.
... We have a 2.0 version which Jon will talk about shortly.
... Millions of units are being shipped in many countries with wide STB support.
... HbbTV 1.0 introduced various features - playback, download, channel lists, etc.
... HbbTV 1.5 adds MPEG DASH, DRM APIs, etc.
... HbbTV 2.0 has features under consideration including improved HTML5 support, companion apps support, improved support for ad insertion, improved synchronization between media and applications, etc.
... Services available include VOD, information, shopping, education, games, advertising, TV portal, companion screen
... So to summarize, we have good momentum and growth, different stakeholders coming together, and an active LinkedIn group.
... No over to Jon Piesing

jon: HbbTV 2.0 started with a list of 19 requirements.
... Most relevant here are related to W3C specs or companion screen.
... Starting with web specs...
... First version was heavily influenced by Open IPTV Forum, based around a TV profile of W3C specs.
... In HbbTV we have HTML5, some CSS 2.1 and 3, DOM 3, and some other HTML5-related specs such as canvas 2D, XHR, etc.
... For some of the specs only a profile is required. For specs that are not Recommendations it's OK to use newer versions.
... For integration, e.g. video element, you have to specify how it fits with other areas such as hardware decoders, so integration is important.
... An example of this is the "controls" attribute of the video element. This specifies how much of the controls are available to the web page or an app.
... There are a number of bugs that we've submitted to W3C.
... For companion screen, we have discovery and launching a companion app from the TV.
... The TV browser can discover apps that can be connected.
... There's a web socket server on the TV so the app gets the IP address of the server.
... We've gone for something similar to DIAL for app-launching companion apps.
... For strategic issues, we find some gaps in HTML5 for IP-delivered video.
... Some parties would like to get away from using our A/V object.
... There's one web but there isn't one TV. There's regional, country or operator differences.
... There needs to be understanding of the differences between one web and regional TV if you look into the details

question: How does companion screen discovery work, when does it happen?

jon: It's complicated. We assume the launcher app is already there. It could be remote control app by the TV manufacturer.
... If you have e.g. a Samsung TV, the user would run the launcher app on the tablet.

klaus: Next is HbbTV certification and testing

simon: Welcome. I'm Simon Waller
... A typical TV viewer looks like Homer Simpson.
... It's a laid-back experience and the TV remote is not necessarily readily available.
... But these days we have alternative methods - voice and gesture.
... What's the broadcaster expectation? We currently have over 100 apps which for us is a lot.
... Broadcasters expect their apps to look identical on every TV and STB.
... TV manufacturers want this as well.
... In the TV space, there are roughly 10 new browsers launched.
... That means a new snapshot of e.g. WebKit
... and no software updates - we tend not to do this in the TV space, except for bug fixing.
... So app developers have to deal with a lot of different browsers and quirks.
... How can the viewer know apps will work?
... What should users look for? We have an HbbTV logo available for license.
... It's based on a test suite and the manufacturer sings an agreement to use it.
... In this agreement it says "TV has to pass HbbTV Test Suite" - all of them, no exceptions.
... The manufacturer commits to try to resolve interoperability problems.
... If the TV is proven to be non-compliant, the manufacturer must update the TV software

ddavis: Next speaker: Andy Hickman

andy: HbbTV just has to work - that's what testing is for.
... The test harness is basically a PC doing three things:
... 1 web server for TV apps
... 2. Playing a DVB transport stream
... 3. It's also a video server, playing MP4, DASH with and without DRM over IP.
... Each test case in the test suite has an XML file describing the test and the test itself - images, javascript, CSS, etc.
... The test case description XML files are very important.
... They have metadata - title, test ID, formal assertion saying what expected behaviour is, description, steps of the test.
... Within the test suite, metadata is used for management - which chapters and references specs are used.

<Mohammed> whois Mohammed

andy: Also says which spec version the test applies to.
... Finally metadata for licensing, history, etc.
... In comparing HbbTV with W3C testing, I'm not a W3C expert so may have some things wrong - please let me know.
... W3C has more reduced test metadata.
... HbbTV has a precisely defined test case list. In extreme cases, a failed test can cause a manufacturer to stop production.
... You either pass or fail test test suite, whereas in the web world it's rare for a browser to say "I pass 100%"
... Both HbbTV and W3C are looking for automation.
... For W3C you can install the test suites locally.
... For HbbTV you must have a test harness implementation.
... The output of the test harness must be a machine-readable and verifiable report.
... The test must be run on an unmodified, off-the-shelf device.
... HbbTV does not address DRM testing.
... It's an area that the HbbTV community is interested in. I think there's interest in EME testing for W3C.
... Video testing is critical for HbbTV.
... I'm not sure how well that's tested in W3C.

simon: HbbTV is used in many countries around the world. The number of apps is growing.
... The number of devices is growing.
... Broadcasters want compatibility.
... HbbTV builds upon W3C Recommendations. It's important to enable HbbTV to be more closely aligned with W3C.
... There are issues if browsers don't support parts of a test suite.

andy: There's a lot of interest in cooperation between HbbTV and W3C, recognizing that there are differences between the approaches.
... Better specs -> better tests -> better compatibility -> better user experience

David Singer: You said the experience should be the same on every device, whereas W3C wants correct experience on every browser. Do you need "the same"?

simon: You don't for there to be errors in the implementation so that the page is displayed wrong.

Bryan Sullivan: Most of the goals are shared with W3C (which is contribution-driven) doesn't give W3C as much room to be exact.

scribe: People pay HbbTV to provide tests which W3C doesn't have. But W3C should take good practices from HbbTV and discuss/follow-up on that.

Next is Kinji Matsumura (NHK)

"Overview of IPTV Forum Japan's Hybridcast Technical Specification"

kinji: Hybridcast uses HTML5. NHK started the Hybridcast service in September 2013
... Commercial broadcasters are carrying out trial services.
... Major TV manufacturers are adopting Hybridcast.
... Version 1.0 was published in March 2013 - the English translation has just been made available

http://www.iptvforum.jp/en/download

kinji: Technical specs consist of two documents:
... "Intergrated broadcast-broadband system specification" and "HTML5 browser specification."
... Diagram of overall architecture is on the screen.
... Hybridcast spec covers enhanced APIs for applications, and app control and management, and companion device connection and message.
... 1. Application Control and Management. This is outside the browser so no direct overlap with W3C specs.
... AIT is "Application Information Table"
... AIT can be used in two ways - multiplexed in the broadcast signal or acquired over HTTP.
... This is similar to HbbTV but there are some differences in getting data from the server.
... 2. "Enhancements to HTML5"
... Some key API enhancements include displaying video/audio using an object element with type attribute "video/iptvf-broadcast"
... Like the video tag, this can use CSS to specify coordination and z-order.
... There is also a Broadcast Resource Access API - the most frequently used API.
... It has a ReceiverDevice object and a StreamEventTarget object.
... The GeneralEventMessageListener is almost the same as the StreamEvent.
... Some Hybridcast second-screen, or companion-application, screenshots are on the screen.
... We use a native app for companion devices.
... The user launches it and connects to the TV, to control the TV contents.
... The user can answer quiz show questions, for example.
... It works as a browser for HTML5 applications on second-screen device.
... The companion apps are mostly developed and distributed by each TV manufacturer.
... The companion app launch sequence is a bit complicated.
... When the user launches the companion app, it discovers the receiver and receives data.
... The TV connects to the broadcaster's server. Then the app on TV calls setURLForCompanionDevice to instruct the companion device to load an app.
... Then the native companion app loads an HTML app from the instructed URL.
... and maker.js in the HTML app implements the APIs to communicate with the TV App.
... Apps on both ends communicate with each other.
... In conclusion, we have 6 months of experience since launching Hybridcast.
... We hope to identify further requirements towards establishing better standards.

Turgay Yoo: Is Hybridcast also suitable for rolling out in the education sector for schools?

kinji: Yes, I think so.
... HTML5 content can interact with broadcast content. NHK has an educational channel and we're looking into this.

Clarke Stevens: HbbTV and Hybridcast seem to have overlapping goals. Is there any effort to work together or are they in competition?

kinji: That's one reason why we're here. Ideally we could migrate to one standard, but there are many local requirements to consider, e.g. what remains a regional standard.

yosuke: HbbTV and IPTV Forum Japan are talking together about how to exchange information. Also, talking within W3C is another effort towards cooperation.

Jon Piesing: There are opportunities for learning from each other, but TV is inherently regional. Japanese TV has its own requirements.

scribe: HbbTV came from something fundamentally different to the Japanese system.
... There are opportunities but TV isn't global. If you try to make a global spec for a market that isn't global you're going to end up using a lot of time and energy that won't meet expectations.

Philipp Hoschka: I understand TV is different in Japan but how does that impact web APIs that you want to use? What part of web technology has to be regional because TV isn't global?

Jon Piesing: We can talk in more detail in the panel later, but we have a list APIs from Hybridcast - HbbTV has a similar list.

scribe: You could push them into a single set of APIs with the same syntax but the actual semantics would end up relating to the broadcast system you're running on.
... E.g. return values could be different depending on region.
... The API could be global but only in appearances.
... Concrete examples I know of are parental access controls, metadata, failure reasons.
... Once you start exposing channels, their description is usually TV-specific.
... The more you try and coordinate, the longer it takes.
... Let's do the best we can and not try to boil the ocean.

Next presentation is "The 1st Implementation Report on TV Programs on Hybrid Broadcasting System using HTML5 Browser-Hybridcast 2014 Project" by Kunio Numabe and Kazuhiro Hoya (Fuji TV)

kunio: We are all from Japanese commercial broadcasters.
... We've been discussing convergence with W3C specs.
... We're getting fedback from the first implementation of HTML5 browsers.
... We're working with the Ministry of Internal Affairs and Communication in Japan.
... We're producing experimental programmes using HTML5 and companion devices.
... We tried various kinds of programmes - sports, animation, etc.

Keiji Yaniguchi: I'm from TBS.

keiji: We made a football (soccer) programme with Hybridcast technology using a large amount of data in realtime.
... The viewer can put widgets on the screen and see rich play data.
... The viewing rate was 2.6%
... One widget is pass conversion rate. Another one is player running distances.
... The widgets were written in canvas, SVG and CSS
... The last widget is a heatmap.
... We tried to make it with SVG but the performance of Hybridcast TV sets so far were not yet sufficient so we used images instead.
... We also have second screen applications using HTML5. You can use the smartphone to see a replay.
... Data arrives from the stadium, goes through the server, and gets shown on TV and smartphones.

Kohei Kawakami: I'm from Nippon TV

scribe: We aired two programmes this winter.
... Users can enjoy not only Hybridcast TV but also legacy TV via smartphones.
... Viewing figures are small but this is one small step for Hybridcast, one giant leap for broadcasting.

kohei: Hybridcast Service System Chart is shown on the screen, using CSS, jQuery, Hybridcast lib, which is a lib for Hyrbridcast APIs NHK introduced in the previous presentation, and object tag for broadcast video.
... Our service is able to connect with social network services and TV programmes.
... So your friends who are watching the same programme as you can see your photo. You can enjoy programmes together.
... We use web specs for animation.

Yusuke Fujii: I'm from TV Asahi

scribe: Our service has useful information available on the TV screen as a Hybridcast application.
... By connecting to the internet, Hybridcast TV can receive information which can be viewed at any time regardless of the broadcast type.
... Now, we can see a famous cartoon character in Japan. This service links a smartphone while watching the programme on air.
... Viewers are able to use their own phone as a remote and enjoy games during the TV programme.
... The Hybridcast API is used for this, to control the character. The character's abilities change over time.
... So the longer you view, the more skills he gets.
... We used canvas to implement this.
... Please see our demos upstairs.

Kenji Sugihara: I'm from TV Tokyo.

scribe: Mission 001 is a shotter game TV program. It supports multiple devices.
... 140,000 people have played this game. 1% of them had a Hybridcast TV.
... The second screen serves as a game controller and the TV shows information.
... The player taps the phone to easily control the game.
... The synchronization uses WebSockets.
... The information on the screen is shown using HTML5.
... The TV can show hints, score and other animation.
... We used CSS sprites and jQuery Effects API for animation.
... We aired this and enhanced the viewer's sense of participation.

Kazuhiro Hoya: I'm from Fuji TV

scribe: We have some case studies.
... We want to make the TV screen to show popups such as tweets or competitions/amusements
... It could be a banner with sponsored content.
... Advantages include rich expression and communication, as well as interaction.
... Some challenges are that it's very hard and uses human resources - we need a framework.
... Also compatibility. There are a lot of TVs on the market. We need a better testing method.
... Also, UX is an issue. Pushing a button the remote is easy.
... But for second screen and pairing there are a lot of steps.
... Using QR code is still hard for coach potatoes.
... We got some negative feedback - too much information on the screen, both on the screen overlay and on the second screen.

kazuhiro: We have 1.2 million viewers but just 1,064 using Hybridcast. And 76 users of second screen.
... We had 1,890 tweets, 3,790 using our hashtag.

Multi-screen 1

Louis Bassbouss: I'm representing the second screen presentation community group. This paper is written by Intel.

scribe: The group was founded at the end of 2013 and has 36 participants from a variety of areas.

<inserted> scribenick: kaz

<inserted> yosuke: got many papers on multi-screen, so split into two sessions

<inserted> ... not only W3C but also involving other SDOs is important

<inserted> ... 15 mins for each presentation

Enabling Second Display Use Cases on the Web - Louay Bassbouss

<inserted> louay: from Fraunhofer FOKUS

<inserted> ... present the second screen CG as well

<inserted> (slide 1)

louay: Introducing the Second Screen Presentation CG

(slide2)

louay: Current Status

(slide3)

louay: Second Display for the Web?

(slide4)

louay: "Second Display" Clarification
... a large screen as TV/projector?

(slide5)

louay: Use Case: Presentation

(slide6)

louay: Use Case: Gaming

(slide7)

louay: Remote Display Technologies
... e.g., Miracast, Airplay, DLNA-based solution and Chromecast
... there are differences between Miracast and Chromecast
... but we want to have one unified API

(slide8)

(slide9)

(slide11)

(slide 12)

(slide 13)

louay: API Preview
... (shows example IDL)

(slide 14)

louay: Presentation API Example
... Phone/Laptop vs. TV/Second Screen
... (explains example script)
... communicating commands like "play/pause video"
... similar to Web messaging APIs
... missing close event

(slide 15)

louay: Presentation API Key Features
... Presentation API

(slide 16)

louay: Presentation API Demo
... (shows URL)

(slide 17)

louay: Participate

Q&A

simon: examples included two user agents

louay: just one agent is possible
... open the Web page with a hidden tab
... like Miracast and Apple TV
... Chromecast is a user agent itself
... if googlechrome hosts miracast, it would be automatically detected
... but the complexity will be move into the browser
... on the browser level

A Flexible Multi-Screen Solution Based on UPnP - Clarke Stevens

clarke: from CableLabs
... member consortium of cable companies
... also representing UPnP
... nearing the end of the spec named multi-screen

(slide 1: Content)

clarke: schedule, etc.

(slide 2: Multi-Screen Trends)

clarke: several of them are proprietary
... looking for W3C solution
... UPnP Forum members working on an open interface
... CableLabs, Cisco, Intel, LGE, PacketVideo, TP Vision, ZTE
... Samsung as well

(slide 3: Goal)

clarke: device /service discovery
... description eventing and notification with the UPnP device architecture
... HbbTV uses UPnP
... communication initiated by either end

(slide 4: Terms used for Informative Usage)

clarke: clarify terms
... Multi-Screen Service, Main screen device and Companion screen device

(slide 5: UPnP Components designed by Multi-Screen ...)

(slide 6: Basic Interaction Model)

clarke: "screen control point" and "screen device"

(slide 7: Extended Interaction Model)

clarke: very flexible model
... TV as a main screen device and tablet as a companion screen device
... but could have individual views on the main screen

(slide 8: Services of Multi-Screen DCP)

clarke: phase 1: app management, app-to-app communication management, key-press protocol and synchronization
... three protocols certified by UPnP
... synchronization is phase 2

(slide 9: UPnP Cloud: Overview)

clarke: allows you set up virtual rooms
... e.g., for chat programs
... anybody from your family can access that room and share realtime communication
... wrapper to a UPnP device

(slide 10: UPnP Cloud Interaction (MUC))

clarke: (shows a diagram)
... user a creates room (MUC)
... user a invites UCCDs and UCC-CPs
... usr a&b meet and share

(slide 11: Web and Virtual Realizations)

clarke: that's it

Q&A

@@@: how does a video streaming work with the architecture?

clarke: just provide your URL
... looking at a possible way for remote access protocol

Simon Waller: eventing?

clarke: you guarantee to leverage UPnP eventing
... depends what you want to do

simon: screen devices

clarke: if you only communicate with new devices you're building, that's fine
... the network service protocol is also being discussed within W3C
... if you just think about communication between screen and screen, websocket might be enough
... but if you use TV, we might need authentication

jc: new screen device type?

clarke: new screen device type

yosuke: tx

Multuscreen Service in Shanghai - Mingmin Wang

mingmin: from Oriental Cable Network
... second time to attend W3C events

(slide1, 2, 3)

mingmin: cable network in Shanghai
... over 1M HDTV subscribers and 1.3M digital Pay TV users
... started NGB since 2008

(slide 4: NGB - network architecture)

(slide 5: NGB - home access network)

(slide 6: Interactve TV service)

mingmin: 10M digital STBs

(slide 7: Multiscreen Service Deployment)

mingmin: started last year

(slide 8: Multiscreen Service Deployment)

(slide 9: Multiscreen Service Deployment)

mingmin: 60 SD libe streaming channels
... 1 HD live streaming channels

(slide 10: Multiple screen service or application)

mingmin: DVB, VOD, SDV, OTT
... are the infrastructure
... Unique content management
... converting metadata
... Unique customer management
... managing IDs
... Unique session management
... session control
... which session comes from which device
... Unique resource management
... QoS control
... identify video stream
... Device management system
... Smart search engine plugins

(slide 11: Multiscreen Service Deployment)

mingmin: typical use case
... video-cloud deployed at cable head-end

(slide 12: Multiscreen Service Deployment)

mingmin: video cloud
... XMPP

(slide 13: Multiscreen Service Deployment)

mingmin: typical application/smart home gateway
... local channels, OTT, internet streaming

(slide 14: Multiscreen Service Deployment - Typical application (1) - DVB+OTT+APP)

mingmin: VOD and TV shopping
... deployed on many STBs
... online chatting as well

(slide 15: Multiscreen Service Deployment - Typical application (2) - OTT+DVB+APP)

mingmin: application for cloud TV

(slide 16: Multiscreen Service Deployment)

mingmin: multi platform
... including iOS and Android
... video streaming, network-based sharing

(slide 17: Multiscreen Service Deployment - smart home gateway)

(slide 18: Multiscreen Service Deployment)

(slide 19: Suggestions)

mingmin: which solution would be suitable for OCN (Oriental Cable Network)?
... would like a unique platform
... XMPP, HTML5 and metadata
... trying to find the best solution

Q&A

ph: already deployed but how popular?

mingmin: deployed our services last year
... OTT, mobile operators cable operators start with Shanghai
... STB for free

not charging for the content either

scribe: our subscribers are 300 thousand

ddavis: video messaging, second screen, OTT

mingmin: they use those services lot
... young people don't watch TV
... prefer tablets
... tablet and mobile phone for streaming
... TV broadcasters are keen to keep their own subscribers

ddavis: Fuji TV said using second screen might be troublesome

mingmin: not troublesome, very popular

Second Screen User... - Dave Raggett

(slide 1: MediaScape)

dsr: new EU project
... mixture of technology of W3C and broadcasters

(slide 2: MediaScape)

dsr: (shows diagram)
... devices- social network-broadcasters

(slide 3: Use Case)

dsr: John is watching a live sports event on TV
... his phone notifies him to start a complementary news service
... he invites Ann...

(slide 4: Requirements)

dsr: social connection, associating TV and phone, allowing phone to know what is being shown on TV, ...

(slide 5: How does it work?)

dsr: conected with WebSocket
... social network server tracks context

(slide 6: What's needed?)

dsr: service workers
... as an agent to be part of the social network
... websocket
... for asynchronous messaging

(slide 7: Synchronization)

dsr: synchronize user experience across devices
... (demo in the break)
... mobile devices don't preload videos

(slide 8: Local vs Remote Messaging)

dsr: local P2P discovery and messaging
... DAP, SysApps, NFC, WebRTC
... lot of choices
... problem with using local discovery
... server-based approach would be better

Q&A

dsr: third-party services
... search broadcasters' metadata, screen, etc.

@@3: would like to have demo

bryan: comparison with other standards?
... any kind of gap analysis?

dsr: will do
... catch me for demo

ddavis: note that no food/drink is allowed here in the meeting room
... this evening
... IRT will hosts a Bavarian dinner
... before that we'll take a group photo
... if you need a taxi, please talk with the lady at the reception
... next session will start at 4pm

(break)

<jcverdie> scribenick: jcverdie

Giuseppe: it's not only a panel, we'd like the audience to interact
... the topics are worth discussing with an audience as wide as possible

(Introduce panelists)

Jean-Pierre Evain for EBU

Jon Piesing for HbbTV/OIPF

Kinj Matsumura for IPTV Forum Japan

UPnP / DLNA : Clarke Stevens

W3C: Philip Hoschka

Short presentation from EBU

Jean-Pierre Evain: largest association of broadcasters worldwide

scribe: production for sports, news
... training for people in the field
... technical innovation, frequency planning
... follow lots of SDO

<kaz> ... 15 mins for each presentation

scribe: Interest in W3C: HTML5 including WAI, annotation, EME, metadata
... Some overlaps indentified: Timed text, EBU-TT-D adopted by MPEG-DASH and HbbTV
... audio modelling
... metadata, bringing semantic web to production
... summary: where's the expertise and who does what?

HbbTV Presentation

(battle plans displayed)

Jon Piesing: this is an illustration of the specification dependencies in HbbTV v2

(Jon describes most important dependencies listed on the slide)

slide is visible here: @@put_url_here

Jon Piesing: many information come from DVB world which is not global.

scribe: ISDB has similar standards but the semantics may vary
... HbbTV is about integration of a pile of stuff done by others, not inventing things

IPTV Forum Japan presentation from Kinji Matsumura-san

(slide show technology overview of HybridCast)

Kinji: Hybridcast uses HTML5 Specs for App development
... Extensions for hybrid use
... @@@

UPnP / DLNA introduction by Clarke Stevens

Clarke: I'm going to assume you have memories of what's been told earlier :)
... UPnP and DLNA are not competitors. UPnP is about technology, DLNA is about usage narrowing down technologies options from UPnP
... Future of TV is about:
... HTML UI: UPnP HTML5 RUI
... Discovery using NSD, XHR or WebSockets
... includes Internet Of Things
... MSE came out of an effort from CableLabs and the Media Pipeline TF
... not directly to UPnP stuff but still cable companies in the US
... Now DLNA
... Recently announces CVP-2 Guidelines
... We don't want to add new APIs to HTML5
... Broke compatibility with CEA-2014 in order to align with HTML5

(slide about cloud scenario in CVP-2)

slide from cable labs are available here: @@cablelabsslides

Clarke: CVP-2 also handles Live Linear Streaming

Giuseppe: @@

Clarke: our goal is to have new platform on HTML5

Kinji: HTML5 is attractive and the only option for us to extend to broadcast

Jon: strategic reason was to sync w/ Standards to enable web developer to reuse their knowledge including libraries
... second reason is people wouldn't develop a specific non HTML5 browser for TV so it was a fait accompli

Giuseppe: what is the challenge of referencing specs from W3C including HTML5?

Clarke: very productive to co-work with W3C (NSD, MSE, EME, TTML...)

Kinji: TV has specific requirements (no windowing, remote controllers)
... We add some guidelines about using HTML5 on TV

Jon Piesing: two set of issues

scribe: Organisational, what version do we refer to if it's not a rec?
... how does that impact test & certification if that can change
... second set of issues is about functionnalities. when they're not completely there, do you define your own properties ?
... you end up with a transition phase with two sets of APIs, one nicely shaped and the other temporary

JP Evain: Trolling about MHEG5

Giuseppe: why is the web economy able to handle the fragmentation, and not the tv industry?

JP Evain: we don't have tv displays only anymore, but dozens of devices with various apps

scribe: HTML5 should be finalized soon so we have a version to reference to
... But there are still ongoing discussions
... But things like timed text are still not sorted
... So some platforms have to create their own extensions

Clarke: Before you put something in a TV you used to test it for a long time and have a stable standard
... The web has brought a new world where you update everyday
... the TV is not quite there

JP Evain: feedback from broadcasters is even more important

Clarke: cable industry now has versioning plans for upgrade and testing

Simon Waller: there are no commercial model for SW Update

scribe: except from giving breath to our call centers by fixing bugs

Giuseppe: is this the same problem in the mobile area?

Steven: I can't say

Jon: the frequency of android updates on the mobile industry is hectic

David Singer: my samsung tv regularly wants me to update

scribe: But I never pressed yes so who knows

@@: @@ ?

Simon: there are updates for the smart tv side. Broadcasters want us to update to be able to run their up to date apps

Jon: whichever update you give even for free that's time & money someone oughts to pay for
... is this broadcasters, manufacturers, ...

Giuseppe: some of you mentioned gaps in your presentations, for instance in Video element. When you run into these gaps in your SDO what's the resolution process?

Clarke: we take some instances back to W3C
... W3C kept up with our pace of innovation
... Related to Web&TV but also Internet of Things

Kinji: in IPTV-J we just use existing standards
... only extension for local broadcasting requirements
... so it wasn't worth bringing back to W3C as it was regional
... there might be some common ground however

Jon: the 1st HbbTV built on top of specs with fine-grained clarifications. We don't want to repeat this
... in v2 we consider W3C specs as they are not trying to clarify anyhow
... What you call gap, I call it a feature I need a solution from somewhere even if not w3C
... little gaps such as Video Element lacking some properties such as different audio stream
... DRM "failure from" description
... look at "hbbtv" in w3C bugzilla for details about what I call "little gaps"

Giuseppe: if it's a little gap you hand it to W3C, if the feature is simply lacking you look for it elsewhere
... At a time you used CEA 2014 now HTML5 would you consider W3C has covered what you call a "big gap"

Jon: but CEA 2014 made the same mistake we made about clarifying W3C specs
... one shouldn't fine-grain clarify other's specs since you don't have publication control

JP Evain: There are different level, second-screen stuff is close to W3C core business

scribe: when you deal with video you are at the fringe
... what a broadcaster sees as a video might not be what the W3C calls a video
... re: schema.org we worked with BBC for a while
... Initial metadata was californian-based geek vision of TV Episode/Series/Season
... Took us ages to sort this out

Giuseppe: there are success and failure stories, is it related to the method aka becoming member and working from the inside rather than bringing input as outsiders

Philipp: the TV Community explained quite well their video element requirements
... it was difficult of course
... but we are obviously interested in getting TV Requirements in our specs

Clarke: disappointed by the testing effort
... we supplied some reqs
... we created some tests on our own

Jon: Investment in time and/or money is important
... Does what you want will benefit from being global ?
... Where are the resources ?
... If you can't afford the investment it takes to do this in the W3C process, then what about elsewhere?
... This is obviously an investment
... Fixing a couple of properties in audio elements vs lobby for a new functionality is a different investment
... Unfortunately TV Industry seems not to have that kind of money anymore
... Some functionalities would be generic but how many devices have a Tuner?
... And if you can't afford to do it in W3C then it doesn't really matter whether W3C is the right place or not

(giuseppe and jon teasing each other about tuner api)

(no harm done, everybody's safe so far)

JP Evain: Jon makes a point.

scribe: I'd like to do things such as Sport ontology in W3C
... my dilemma is: I can do my own stuff and I know I'm good enough because I'm facing actual data
... But there'll always be someone who will say "I don't care, I'll use something from W3C because it's W3C"
... So it's risk mitigation and investment

<inserted> scribenick: ddavis

<scribe> Scribe: Daniel

<jcverdie> Bryan Sullivan: A lot can be done through CG

Bryan: What of these gaps are the most difficult ones?
... Delivery of real-time linear content to devices.
... The access to EPG or metadata.
... Harmonising access today to third-party integration

Clarke: There's an abstraction layer that would be well-address by W3C. If we can indicate a URL it wouldn't depend on the hardware. That's a good area for integration.
... Dealing with linear content in general is one of the most critical.

Jon: There's a huge amount to deal with regarding linear content - I don't think W3C can deal with this.
... So you end up with something not fit for purpose.
... An abstraction layer that doesn't enable a legacy version to be phased out you just end up with duplication.
... There is a lot of work on MPEG-DASH to do live TV over the internet.
... What do you need at W3C to fit with that?
... You need failure modes that have enough information.
... But I look at the people participating in MPEG-DASH and they are people who's lives depend on getting live TV to work. It's advanced, lots of work has gone into it.

Mingmin Wang: The topic is aligning standards and what's next.

scribe: We are interested in W3C standards because we use HTML. In China, standards are very hybrid so there is competition between video services and cable operators.
... Do you think it's possible to have a basic profile quickly that focuses on basic things like a video player to create a unique standard that can have mass deployment?
... It's better to have a good solution as quickly as possible because of fast competition.
... We attended this workshop to find a solution.

Jean-Pierre: For more than 30 years we have been living with the fantasy of faster standards.
... If it's a good compromise, it takes time.

Jon: The more people you have in the room, the longer it takes.
... To do it quickly, you need a small group of people and ruthless focus.
... Then you add more people, more ambition and it takes longer.

@@@: I think EME breaks everyone of Jon's laws.

Jon: I think EME is actually a good example of a fast standard.

Clarke: The Chinese approach seems practical. It's going to be about whether a standards organisation survives if it moves fast enough.

Giuseppe: The last question I have is about testing.

Clarke: If the testing regimen for HTML5 is not ready then we prefer not to use it. The effort to raise money has not really worked. At the end of the day, companies will only use tech they can rely on.

Kinji: Testing is very important. We're happy to use existing test suites. IPTV Forum Japan has a test suite but just for our extensions.
... Our efforts are still under discussion.

Jon: HbbTV is not interested in duplicating anybody else's work.
... If there's something usable from W3C, even if it's not perfect, we'd be interested in it.
... DLNA seems to have the closest mindset for us.

Giuseppe: The need is still there. Is there anything SDOs can do?

Clarke: Jon probably means that DLNA is similar because tests have to be created at an early stage.

Jean-Pierre: We are developing services using existing web technology such as SOAP and REST. It's just for broadcasting. People don't want to pay for the technology or to be a member.
... All that we can do is to have some members that participate, doing remote testing. The best we can do is facilitate such self-testing.

Jon: What about TTML testing?
... Is there somebody who can talk about that?

@@@: I think there is a W3C test suite available since the TTML spec was published.

scribe: I'm not sure how up-to-date it is.

Bryan: Coming back to the question of cost. With Test The Web Forward, anybody can participate. Similarly, community groups are free for anyone to create or join - you just need people who know what they're doing.
... Is there are a possibility that we could drive this through domain-specific efforts?
... All the SDOs have their HTML5-specific profiles. There could be virtual events that don't cost money - just time.

Giuseppe: About testing, we see each SDO is spending money on tests. Wouldn't it be better to put that money together?

Clarke: Viable companies will want to test their products before shipping. For CableLabs we contributed tests to DLNA and W3C. Everyone benefits and it's shortsighted if you keep them to yourself.

Jon: I agree, but the tests have to be suitable.
... Tests that just test the validity of the spec are less useful.
... Off the top of my head, unofficially, the extra formality to make W3C tests useful for certification is not sufficient. The absence of it is a deal breaker.

Clarke: We contributed tests to WebKit.
... If we have a more formalised test development infrastructure we could encourage more contributions.

Bryan: Are there people in the SDOs who are able to share that diligence with W3C? They're experts - if W3C could adopt some of those practices we could build something more usable.

Andy Hickman: I think yes.

scribe: There's clearly an opportunity for mutual benefit.
... It sounds trivial but I reckon if you look at the voluntary HbbTV effort, less than a quarter of it is writing the tests themselves.
... The remainder is the stuff that takes the most time.
... If we're not organised, we get a load of tests but we can't see the woods for the trees.
... There are 10,000s of good tests out there but working out which are good is non-trivial.

Jon: With MHP we spent millions on creating tests.
... The time spent in peer-reviewing tests is easily double what we spent on creating the tests in the beginning.
... But a test suite that hasn't been peer-reviewed is worthless.
... You can't have confidence in the results. So any test cost has to be doubled to account for peer-review.

<bryan> Some W3C members are also very well aware of the need for diligence in device certification - for example many Mobile Network Operators certify up to 40 different devices each year through multiple software revisions. Exact tests that are efficiently regression tested are essential, and business as usual.

Jon: The strangest of example is that we had a test case had to pass three implementations. But you end up building test suites biased towards testing just the easy stuff.
... I have the upmost respect for people who deal with this daily.
... We should try to cooperate better on this as an industry.

Clarke: With W3C, we took on a big testing effort that didn't get any funding.
... Maybe we could build a minimal set of that and at least have something.

Philipp Hoschka: There is an infrastructure in place.

scribe: Test The Web Forward explains how tests work and is a repository for tests.
... There needs to be more study. We are working on this and Opera have contributed a lot of tests, as have others.

<bryan> Focusing/phasing the TTWF infrastructure and assets (e.g. tests and assertions) is one of the "plan B" approaches we have proposed to W3C in the absence of sponsorships. All we need to do is form a Web&TV community that applies resources to defining and developing just those priorities/phased resources, rather than just defining what they want.

@@@: We noticed that some people were leaving after getting funding for a spec, if it's not done on time.

scribe: So funding for the spec includes funding for testing.

Jon: Not going to Recommendation is not a good deterrent when people reluctantly refer to Working Drafts.

Jean-Pierre: Going back to MHP, you have manufacturers who are shipping million TV sets which is different to those making web services.

ddavis: What are some quick wins?

Jean-Pierre: I see more people from the broadcast world coming to W3C than vice versa.
... I'd like to make it easier for people to join W3C from broadcasting world.
... Sometimes it's difficult for people to speak up.

Jon: Being cynical, please look at the Bugzilla entries in my presentation this morning.
... Low-hanging fruit - one of Giuseppe's points is... it's a lot easier in a W3C spec to say the return value of a method is something.
... I've seen huge debates where people end up getting shouted down for proposing extensibility methods.
... When you're trying to make a connection between something that's global with things that are not global, if you can work out how they connect then that would enable more commonality.
... Not necessarily abstraction layers but where return values are not defined by W3C but left to other implementers.

Giuseppe: Maybe there are places where a return value can be generic, but there could be the opposite too.
... Also, it's possible to propose extensions to the spec. We have bugzilla but maybe not enough TV people have submitted bugs.
... So if you want an additional return value you can submit a bug.

Jon: If I wanted to submit a bug for failure codes, doing that would take a lot of my time. But such small extensions are low-hanging fruit.

Clarke: I think the easiest problem to solve is where you've several dedicated people in a room to fix a problem.
... With EME, there weren't necessary aligned opinions, but with MSE there were a lot of people who wanted to solve the same problem.

David Singer: At least one of the slides showed a bewildering number of standards, which reference testing.

scribe: The bodies are slightly different in how they implement specifications. Is that a problem? Should W3C look at that?

Jean-Pierre: Going back to the services using SOAP and REST I mentioned earlier.
... Somebody suggesting calling them examples rather than reference implementations.

Jon: The two words "reference implementation" cause concern. They could give a particular vendor an advantage.
... You could have a big discussion about what reference implementation means.
... It's such a touchy subject about what benefits they give.

Clarke: I think you have to look at each organization. There's also operability testing.

JC Dufour: To give an idea about the level of thinking MPEG had, yes, a reference implementation is a very powerful tool.

scribe: But if we find an ambiguity we have to export it as soon as possible.
... Yes, the company selected gets an advantage but it has to give the software away for free for conforming.

<jcverdie> anyone has an idea why the minutes did not take the last session? (the IRC logs did however)

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2014/04/03 06:47:02 $