Minutes from W3C M&E IG Bullet Chatting call 24 March 2020

Dear all,

The minutes from the Media & Entertainment Interest Group call on Tuesday 24th March are now available [1], and copied below.

The slides are also available [2].

We'll announce the next date to continue the Bullet Chatting topic soon.

Kind regards,

Chris (Co-chair, W3C Media & Entertainment Interest Group)

[1] https://www.w3.org/2020/03/24-me-minutes.html
[2] https://www.w3.org/2011/webtv/wiki/images/9/98/Bullet_Chatting_TF_24_03_2020_-_v6.pdf

--

W3C
- DRAFT -
Media and Entertainment IG - Bullet Chatting
24 Mar 2020

Attendees

Present
    Kaz_Ashimura, Chris_needham, Larry_Zhao, Michael_Li, Song_Xu, Keiichi_Suzuki, Takio_Yamaoka, Yajun_Chen, Huaqi_Shan, Akihiko_Koizuka, Fuqiao_Xue, Francois_Daoust, Nigel_Megitt_BBC, Kazuhiro_Hoya, Pierre-Anthony_Lemieux, Peipei_Guo

Regrets

Chair
    Chris, Pierre, Igarashi

Scribe
    cpn, kaz, tidoust

Contents

Topics

Agenda
    Introduction
    Whether Bullet Chatting File Standardization is needed
    Necessity of Bullet Chatting Rendering Standardization
    Bullet Chatting rendering use cases (1)
    Bullet Chatting rendering use cases (2)
    Wrap up

Summary of Action Items
Summary of Resolutions

<cpn> scribenick: cpn

# Agenda

Chris: Agenda is here: https://lists.w3.org/Archives/Public/public-web-and-tv/2020Mar/0017.html

# Introduction

https://www.w3.org/2011/webtv/wiki/images/9/98/Bullet_Chatting_TF_24_03_2020_-_v6.pdf Huaqi's slides

Huaqi: Following the last meeting, we discussed in the Bullet Chatting CG about Chris's and Francois' emails, and questions from the last meeting.
.... We have several topics: Why bullet chatting format standardisation is needed, the need for rendering standardisation and the related use cases and behaviours

# Whether Bullet Chatting File Standardization is needed

<kaz> scribenick: kaz

There's no requirement for interoperability at present, but we do seen an advantage in standardising, to save cost for new developers and companies.

Song: [describes Sports event example with multiple providers]

<cpn> scribenick: cpn

Song: It's not only about the cost for new developers, but also third parties and other developers.
.... Standardising would make it easier for anyone to enter the market.

Pierre: Is there a diagram for the broadcasting use case?

Huaqi: We need to support the VOD use case and non-video use case.

Pierre: This is the best case I've heard for standardisation so far.

Francois: Companies don't usually develop standards to enable new entrants to the market, but Song's use case seems compelling to show the need.

Nigel: Is there an existing technology in the broadcast world for bullet chatting?

Song: There's no concrete solution in the market. A service provider gets the right to build a bullet chatting back-end, then their technology could become a standard to make it easy for others to use.
.... The API solution would need to be opened to others.

Nigel: I want to know if there's a need for compatibility with technology that already exists, e.g., existing broadcasting technology.
.... For example, MPEG standards, or if this is independent of those?

Song: There's no strong need that I can see. If they want to build similar technology, they would use the current solutions in the market, which uses proprietary bullet chatting implementations.

<Zakim> kaz, you wanted to mention our previous questions from https://www.w3.org/2020/03/03-me-minutes.html

Kaz: Here's the link to previous minutes, for discussion of the previous topics.

Pierre: I'd like to hear in more detail what Song has discussed. How does the integration work, for the sports broadcast?
.... This kind of diagram would really help us select the right technology.

Song: Companies that provide bullet chatting provide similar technology but different interface.
.... Today we'll break it down into different scenarios, e.g, Big screen and wall.

# Necessity of Bullet Chatting Rendering Standardization

Huaqi: Rendering is not supported in a standardised way. Developers currently use canvas or CSS.
.... The advantage of using canvas is better performance, you can use WebGL to display a large number of texts at the same time.
.... Disadvantage is that it's not flexible. It's cumbersome to display text with images. Resolution needs to be addressed for mobile devices.
.... With CSS, it's more simple. Users can pause the bullet chatting.
.... Disadvantage is the large number of DOM nodes.

Chris: Does the browser provide all the rendering primitives you need, including for animation and pausing, or do you see gaps?

Larry_Zhao: For animation with Canvas, we can use rAF or setTimeout or setInterval. With CSS, we use CSS Animations.

<tidoust> scribenick: tidoust

Chris: I think what you're saying is that you have not identified gaps with these technologies?

<cpn> scribenick: cpn

# Bullet Chatting rendering use cases (1)

Huaqi: The first scenario is ondemand video. The bullet chatting is associated with the video timeline.
.... User A sends a message at 10 seconds, and other users see the message also at 10 seconds.
.... If the user pauses the video, the bullet chat also pauses. If the user hovers over a messsage, it stops scrolling, but other messages scroll as usual

Francois: Is it just one message, or the entire row of messages that pauses?

<xfq_> "real time" means user B can see the bullet chat user A sent when watching the video (without having to reloading the page to load the bullet chats in the database)

Huaqi: It's just one message that stops, and the others still scroll.

Francois: Do we want to specify the exact behaviour across all providers? Which parts could vary between providers?
.... I'm imagining a bullet chatting spec, it would say that the rendering must stop scrolling when the user hovers over a bullet chat message, or will implementers be free to implement other behaviours?

Fuqiao: This could be on a case by case basis. For the pausing behaviour I've seen variability between different sites.

<Zakim> nigel, you wanted to ask if preventing text overlap is part of the requirements

Nigel: From the image in the slide, there's a lot of text, which doesn't overlap other text.
.... The text scrolls at different speed, so is there a presentation requirement to prevent overlap of text?

<xfq_> There's an allowOverlap attribute in https://w3c.github.io/danmaku/api.html#bulletchatlist-element

Huaqi: Yes, we have a setting to control overlap or not

Nigel: Is this setting in the application, or in the data?

Song: For one activity, e.g., sports or live music festival, the hosting company provides the requirements for the bullet chatting, e.g., font, size, overlap setting.
.... Typically, the operator will set the configuration at the beginning, and there's no data exchange for different requirements in real time
.... The software receives the configuration. Standardisation should make it as flexible as possible

Kaz: It would be useful we could use abstract box model that Huaqi showed to describe this use case.
.... Also, it could help us understand the use cases to explain the users A, B, C are doing, and what the effect the others see.

# Bullet Chatting rendering use cases (2)

Huaqi: The second scanario is live streaming. In this case the bullet chatting does not relate to the media timeline. There's no progress bar.
.... The bullet chatting is broadcast via web socket.
.... If the user pauses the video, the bullet chat is also paused.
.... There's a mixture of live and on demand video, but it's not supported.

Nigel: The bullet chat messages are sent via web socket, so how do you manage scaling to millions of viewers?
.... If a viewer pauses the video, is their player expected to continue to receive bullet chat messages via the web socket and then associate them with media time?

Huaqi: For the second question: when you pause the video it continues to receive bullet chatting messages over the websocket

Nigel: So in this case, if the user unpauses the video, do they see all the messages that others would have seen, or do they jump to the live edge?

Fuqiao: From what I've seen, when the user pauses, the video receives message, but discards them, and when the user unpauses only new messages are rendered

Song: This depends on the vendor.
.... In some cases they'll present the messages the user passed during the next few seconds, but they're scrolled faster. The service provider wants to give the user complete information as much as possible.
.... But if the pause time exceeds say 30 seconds, it would skip on resume.
.... It wouldn't make sense to show them, from a user experience perspective..
.... Standardisation is flexible on this, so service providers can have their own solutions.

Nigel: We've heard about what existing implementations do. I'm also interested to hear what would people like for it to do.

<kaz> +1

Nigel: Is the existing behaviour the desired user experience, or what you have based on existing solutions or limitations?

Song: I can provide more details for people to read on this.
.... The slides here just present the general solution, but we can break down in different use cases, to see how standards can provide sufficient guidelines for different scenarios with different requirements.

Kaz: The slides here are an initial starting point, we can add requirements and expected behaviours for these use cases and think about gaps with exisitng mechanisms such as canvas, websockets, CSS.

# Wrap up

Huaqi: (Reviews remaining slides) The next slides cover rendering behaviours, we have some ideas on this: elements, attributes, events, and synchronisation with media timeline.

<nigel> Afterthought from me - it would be good to get a sense of which of the use cases, file format for exchange, or rendering, or something else, is most important to fix first.

Chris: Next meeting is 7th April, we have some other topics planned.
.... Let's exchange via email and we can organise another call dedicated for bullet chatting.

[adjourned]

Summary of Action Items
Summary of Resolutions
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2020/03/25 00:54:32 $

Received on Wednesday, 25 March 2020 11:34:04 UTC