dash.js face-to-face 2022 - Agenda and discussion

[dsilhavy]

The agenda will be announced soon. In the meantime, please raise potential agenda items in this discussion thread. More information about our face-to-face meeting can be found below:

Dear all,

we are very happy to announce that we will finally have a dash.js face-to-face meeting again. We will meet on June 20th in Berlin!

The dash.js face-to-face meeting is being hosted by Fraunhofer FOKUS in Berlin, and is co-located with the Media Web Symposium. The FOKUS Media Web Symposium (MWS) is an annual international conference organized by Fraunhofer FOKUS hosting 200+ participants from all over the world discussing Internet based media delivery.

Both events are free to attend. Please find all the relevant links below:

• dash.js face-to-face registration: https://www.eventbrite.de/e/dashjs-face-to-face-meeting-2022-tickets-311628327717
• MWS 2022 Registration: https://fokusmws22.eventbrite.de/
• MWS Program: https://www.fokus.fraunhofer.de/go/mws/program

Looking forward to seeing you in Berlin

F2F Agenda

• Timeslot: 20.06.2022 - 13:00 - 18:00

Welcome session 13:00 - 13:30 (all)

• Introductions (all)
• Agenda/Prioritization (Daniel)

Overview session 13:30 - 14:00 (Daniel, all)

• Status and numbers
• The latest features and additions
• Related projects & activities

Features & Demos (14:00 - 16:00) (all)

Catchup logic (Daniel)

• Recent changes to the low latency catchup logic
• Support for ProducerReferenceTime
• Discussion on how to deal with seeks
• See Feature/service description #3831

Documentation on Github pages (Daniel)

• See https://dsilhavy.github.io/dashjs-jekyll-documentation/

Short break 15:00 - 15:15 (all)

Subtitle Rendering in LL DASH (Andreas Tai)

• See dash.js face-to-face 2022 - Agenda and discussion #3912 (comment)

Throughput and ABR refactoring (Daniel)

• Changes to the ABR and throughput implementation
• See: Refactor throughput and abr #3776

Content validation (KVPasupuleti)

• Validate whether the attribute values like duration, timescale and the number of segments tally with the actual total duration given
• In case of multiple periods, we can check whether the periods are divided properly
  • Start times and Durations match between Periods
  • Period duration matches with the SegmentList duration attribute and the number of Segments involved in that Period

Demo: S4S - Server Side Segment Selection for Streaming (Guillaume Bichot)

• Server Side ABR logic
• Synergy to CMSD?

Demo: ABR testbed (Vinay, Björn)

Short break (16:00 - 16:15)

Developer workflows: Tools and more

• Which tools are you using for development
• Any tips & tricks to be shared?

Roadmap planing 16:15 - 17:15 (all)

• ARI track
  • Parse track information and dispatch them via event
• PRFT box parsing
• Content Steering
  • Server needed, but could easily be added
• Support for adaptation-set-switching
• MSE in webworkers
• Improve developer documentation
• New reference UI
• Improved XML parsing
• Preload support
  • Preload support with no view attached #3954

Other discussion items (17:15 - 17:45)

• dash.js Release cycle
• Coordination: Slack, Google Groups, Github
• How to attract more developers?
• How to attract more companies to use dash.js in production?
• Any other item?

Team photo

Group dinner (18.00 - 21:00)

[KVPasupuleti]

A suggestion about an item to be discussed in the Agenda,

We can have a perfect DASH validator (We already have one, but a better one)

The existing validator does these

I guess we can do these.

1. Validate whether the attribute values like duration, timescale and the number of segments tally with the actual total duration given
2. In case of multiple periods, we can check whether the periods are divided properly
   a. Start times and Durations match between Periods
   b. Period duration matches with the SegmentList duration attribute and the number of Segments involved in that Period
3. So on...

and some other mathematical stuff that can validate the accuracy of getting the manifest played as expected, not just validate syntactically.

@dsilhavy please add this if you could see some potential need for this in the Industry. If yes, we can enhance this.

[tobbee]

I'd like to have a browser-based validator, instead of server-side tools. That would then work with local content and one would not be relying on the performance of the server. We probably cannot write such a validator in pure Javascript, but we translate C/C++/Go code into WebAssembly and run it in the browser.

[GuillaumeBichot]

Hi all. I would be interested to introduce S4S (Server Side Segment Selection for Streaming) that is based on a transport level available bandwidth estimation. S4S supports a transparent mode based on self-initializing segments (which works with dash.js out of the box) and a non transparent mode requiring to modify the player in order to supports the protocol (a set of HTTP headers and/or query string parameters. We have modified the dash player for supporting both modes and for reporting accordingly the informations displayed by the UI.

[andreastai]

Topic: Subtitle rendering in LL DASH.

Recently, there have been discussions in the W3C Timed Text WG (TTWG) about possible issues with subtitle decoding/rendering in low latency scenarios (LL DASH in particular). The issues were whether subtitles need to be delivered in chunks and whether progressive parsing and rendering of subtitle documents are required. The discussion started with IMSC, but the same scenario applies to WebVTT.

For more info on the TTWG discussion see the mailing list thread and the TTWG meeting minutes.

It would be good to hear some views from the player/decoder perspective. Is there a problem and what could be the next steps for a solution?

[tobbee]

@andreastai I think that chunked subtitles is an interesting topic. WebVTT (wvtt) in CMAF segments is somewhat better off since the timing is done by samples as for video and audio, so splitting and combining cues is relatively simple. TTML has the issue of double timescales with both a segment timescale and duration and the actual cue samples and duration inside the segment. That leads to cross-layer couplings and quite a lot of overhead by repeating the whole TTML document in each chunk. Maybe one could use some type of XML patch mechanism to make the overhead smaller? In any case, it is important that the player can render subtitles which are split into multiple segments/chunks without issues. That normally works well in dash.js, but has been a disaster in Apple players for a long time (it may have improved recently, but not last time I checked after having reported bugs and gotten some indiction that it should have improved). Proposing new mechanisms is more for DASH-IF/MPEG, but we could have a player discussion here.

[nigelmegitt]

repeating the whole TTML document in each chunk

@tobbee I don't recognise this as a requirement, but it may be a naive implementation choice.

It's more likely that parts of the TTML document are duplicated in each segment, such as the styling and layout in the head element.