Skip to content

2016 Munich Face to face meeting

Will Law edited this page May 19, 2016 · 31 revisions

General

The 2016 European face-to-face meeting of the dash.js project on GitHub. This meeting is open to all dash.js contributors, committers and interested parties to present/discuss architectural, feature, scope and planning input for the project. The meeting is free to attend. Lunch will be provided.

Thanks to Maxdome for hosting this event.

webex: https://meetings.webex.com/collabs/#/meetings/detail?uuid=MBRI147UCSQRHKVHQYD0EI3AN9-603&rnd=441297.96536

Registration: Please register your attendance at Eventbrite.

Where: G1 (Gutenbergstraße 1), - 85774 Unterföhring, Germany - View Map

When: May 19, 2016

  • 08:30 - 09:00 – REGISTRATION, WELCOME COFFEE

  • 09:00 - 12:30 – MORNING SESSION

    • Welcome - introductions

    • Feature discussions

      • Demo - FastSwitch Demo and discussion - Allow fast bitrate switching - fetch next segment ahead of playhead rather than front of buffer. Rules for doing this.
      • APIS for playing back from live - time vs segment. Discuss minimum APIs necessary and default values.
      • baseURL - discuss segment retry APIs and priorities. Establish consensus around which fail-over schemes should be offered and the APIs necessary to sustain those.
      • VirtualBuffer - proposal for removal. Why? What benefits? Can it be replaced with a mapping class that maps time ranges/bitrates/resolutions.
      • Audio Video Download Evenness
      • Only load the highest bitrate init segment.
      • Subtitling and live simulator - Tobbe.
    • Architecture Discussion

      • Demo by Technische Universitaet Berlin, who have developed a low delay live streaming adaptation algorithm.
      • Under what conditions when switching periods can we re-use the SourceBuffers and thereby achieve a seamless switch? How to add this feature to existign workflow? Use of AVC3 in particular is of interest here.
      • Support for webM via webm.js - not compatible with current dash.js (#1301). Should we continue support? Who is interested in working on this initiative? Should we retain support for webm?
      • Accessibility - what can/should/must dash.js do to support W3C accessibility guidelines?
      • Competitive discussion - dash.js vs Shaka vs Bitmovin. Where is dash.js behind? Where does it need to improve?
      • Smooth support - a case by Orange
  • 12:30 - 13:30 – LUNCH, NETWORKING

  • 13:30 - 17:00 – AFTERNOON SESSION

    • Ad Insertion

      • Ad Insertion demo by Fraunhofer FOKUS
      • Discussion on ad-insertion features, gaps
    • Content Protection

      • Content protection - should architecture be changed? Proposal from Sander, comments from Loke and Bernhard. Can we stop supporting the older EME implementations? Does FF support of Widevine allow us to simplify the code?
      • dash.js use by W3C for EME - briefing.
    • P2P delivery

      • Demo by Streamroot of p2p/WebRTC distribution.
      • What needs to be changed to make dash.js a better platform for p2p solutions?
    • Project (docs, organization, workflow)

      • Set minimum requirements for anyone saying "dash.js doesn't work" on github or slack. Example's: provide a public mpd and clear steps to problem reproduction, provide the mpd (even if its not public), provide the relevant portions of the console log, provide the exact code branch/build/fork you are referencing etc. Discuss and agree on issue submission template.
      • Best practice-guide for set up broadcast main/backup (=failover-scenarios) for Encoder -> CDN -> Player
      • Over-view of BrowserStack based dash.js test framework
  • 19:30 – 21:30 - GROUP DINNER - Nürnberger Bratwurst Glöckl am Dom (Duerer Stube), Frauenplatz 9, Munich


Agenda wishlist - now closed for input. The items below are retained for archival purposes.

  1. APIS for playing back from live - time vs segment. Discuss minimum APIs necessary and default values.
  2. baseURL - discuss segment retry APIs and priorities. Establish consensus around which fail-over schemes should be offered and the APIs necessary to sustain those.
  3. Demo by Technische Universitaet Berlin, who have developed a low delay live streaming adaptation algorithm.
  4. Competitive discussion - dash.js vs Shaka vs Bitmovin. Where is dash.js behind? Where does it need to improve?
  5. Support for webM via webm.js - not compatible with current dash.js (#1301). Should we continue support? Who is interested in working on this initiative?
  6. VirtualBuffer - proposal for removal. Why? What benefits? Can it be replaced with a mapping class that maps time ranges/bitrates/resolutions.
  7. FastSwitch Demo and discussion - Allow fast bitrate switching - fetch next segment ahead of playhead rather than front of buffer. Rules for doing this.
  8. Under what conditions when switching periods can we re-use the SourceBuffers and thereby achieve a seamless switch? How to add this feature to existign workflow? Use of AVC3 in particular is of interest here.
  9. Set minimum requirements for anyone saying "dash.js doesn't work" on github or slack. Example's: provide a public mpd and clear steps to problem reproduction, provide the mpd (even if its not public), provide the relevant portions of the console log, provide the exact code branch/build/fork you are referencing etc.
  10. Demo by Streamroot of p2p/WebRTC distribution.
  11. Best practice-guide for set up broadcast main/backup (=failover-scenarios) for Encoder -> CDN -> Player.
  12. Over-view of BrowserStack based dash.js' test framework (only if this was not discussed in the Dec face-to-face)
  13. Discuss and agree on issue submission template.
  14. Ad Insertion demo by Fraunhofer FOKUS
  15. Contrib/webmjs - who is interested in maintaining? Should we retain support for webm?
  16. Content protection - should architecture be changed? Proposal from Sander, comments from Loke and Bernhard. Can we stop supporting the older EME implementations? Does FF support of Widevine allow us to simplify the code?
  17. dash.js use by W3C for EME - briefing.
Clone this wiki locally