<cpn> scribenick: cpn
Chris: Agenda is here: https://lists.w3.org/Archives/Public/public-web-and-tv/2020Mar/0017.html
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
<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.
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
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.
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.
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]