Skip to content

2016 Munich Face to face meeting

Jump to bottom Edit New page
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.

        • New event for when bitrate is rendering
        • Switch at front of buffer instead of end
        • Preserves highest quality on seek
        • Can now build 30s buffers? Could be risky with live.
        • Should be wrapped in an API.

      • APIS for playing back from live - time vs segment. Discuss minimum APIs necessary and default values.

        • time delay is function of segment duration
        • Uses for both time and segment duration APIs
        • Add UI controls to reference player
        • Proposal to create modes - combination of API settings. Consensus no but add docs to describe. Create sample to show different behaviors.
        • Change default to MIN (12s, 2 segments).

      • baseURL - discuss segment retry APIs and priorities. Establish consensus around which fail-over schemes should be offered and the APIs necessary to sustain those.

        • Retries on 404 , 3 retries @ 1000ms, 2 modes - DVB (weights, priorities) with auto detect on profile, or BASIC DASH. Hierarchical implementation. Sticky to new source. Does not loop.
        • Change default retry to 1.
        • If baseURL in place, change retry to 0, and try all baseURLS.
        • New property baseURLListRetryAttempts, set to 1. #Make issue.

      • retry logic

        • LIVE - 404 on segment during steady state.
          • Re-do clock sync and reload mpd
          • Retry segment after retry interval
          • If baseURL, switch to next source
          • Invoke ABR logic before retry
          • #Make issue.

      • VirtualBuffer - proposal for removal. Why? What benefits? Can it be replaced with a mapping class that maps time ranges/bitrates/resolutions. * Added when multiple segments were loaded in parallel at period switch. * Storing media objects in VB today. * Should store init segments. Should not store all media segments. * Should be removed and replaced with append queue for source buffer to allow scheduling to proceed while appending. * Processor in front of source buffer. @Axel has some code for this. * #make issue

      • Audio Video Download Evenness * issue raised with audio buffer length growing longer than video length, in low throughput. * Fixed by limiting audio buffer length to be <= video buffer length. * check for audio-only streams. * @Dan will make a PR

      • Only load the highest bitrate init segment. * If bitstreamswitching flag is true, you can pick segment from representation. Only need to append one init segment at start of playback. Kilroy suggests to use highest. * If bitstreamswitching flag is false, can not do optimization.

      • Subtitling and live simulator - Tobbe.

        • TTML, WebVTT, CEA608
        • EBU-TT-D, either in segmented track, or side car
        • WEbVTT, so style support, sideload or track with segments.
        • 608 , only scanned if signaled in manifest. Two rendering modes.
        • Image sub titles, old code, not well supported.
        • PPTX wil be sent to group.

    • 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.

        • Today we tear down source buffers at every period switch.
        • Two things have to match - same codecs parameter, fps,
        • Shaka has seamless switch - are they using two video elements ?
        • signaling of period continuity - can reuse buffer.
        • Proposal - try to reuse sourcebuffer. Catch error if fails and then tear down. #Make issue.

      • 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?

      • Tutorial on how to use dash.js, go back to contributors

      • Contact submitters, ask to update, or permission to deprecate and remove.

      • Accessibility - what can/should/must dash.js do to support W3C accessibility guidelines?

        • We are a headless player
        • Dash.js supports stickiness for default startup options.

      • Smooth support - a case by Orange

        • Asked for Smooth support, so forked and added capability to 1.2. Compatible with existing Smooth live platform. target still to migrate to DASH. Many companies still using live Smooth.
        • Who else is interested in this project - Orange, Fraunhofer, Microsoft, Streamroot, Akamai.
        • Must parse manifest, but rest of workflow is similar. Add module for SS.
        • Must not bloat code, or add excessive complexity.
        • HLS support for CMAF only.

      • Competitive discussion - dash.js vs Shaka. Where is dash.js behind? Where does it need to improve? * Documentation - dash.js needs work. * Shaka Binary is smaller.

  • 13:00 - 13:30 – LUNCH, NETWORKING

  • 13:30 - 17:00 – AFTERNOON SESSION

    • Ad Insertion

      • Ad Insertion demo by Fraunhofer FOKUS
      • Discussion on ad-insertion features, gaps * Decided not to push for OnRequest XLINK * MPD Chaining
      • EMSG support.
      • MPD Update event.
      • EventID - how long to keep looking for duplicates? We keep everything currently.

    • Content Protection

      • Content protection - should architecture be changed? Proposal from Sander, comments from Loke and Bernhard. Can we stop supporting the older EME implementations - no, please keep supporting them. Does FF support of Widevine allow us to simplify the code?

      • Give more control to application, can override and allow which CDM to play content.

      • Regarding selecting CDM, priority is hardcoded.

      • How to get PSSH - parse segment, or from MPD. Today we only support parsing segment.

      • DASH IF has deprecated having PSSH in segments. Current recommendation, should send update to CDM.

      • Need to parse and use ContentProtection element from manifest. #make issue

      • Should deprecate PSSH parsing? - Would break some existing applications. Irdeto has different license urls depending on user.

      • Tracked at https://github.com/Dash-Industry-Forum/dash.js/issues/1367

      • dash.js use by W3C for EME - briefing. W3C are pushing EME to candidate release, every feature requires two independent implementations. By Sept 29 have to go to CR, no test plan done yet. Suggestion to use dash.js to do functional tests of EME. 1) dash.js must be made current with latest spec and have strict mode 2) Test player exposing all EME traffic to allow EME testing. Do all this in next two months. If Greg gets involved, can work with Dan.

      • Adobe can help with Access implementation.

    • P2P delivery

      • Demo by Streamroot of p2p/WebRTC distribution.

      • What needs to be changed to make dash.js a better platform for p2p solutions? https://docs.google.com/presentation/d/1oTwkI5nSL4lAk1xEvD2x-uYxqNSP8r90SzN-MdZy0jA/edit#slide=id.g112873f9cf_3_122

        • State duplication - facade over video element. Make more robust.
        • Scheduling logic - use getForTime after start, seek, then getNext.
        • DashHandler - DashHandler needs to be re-written. Avoid IF forest.
        • Encapsulation
        • Naming - scheduling rules are not replaceable rules, should be renamed. Remove "rule" from name and from namespace. #make issue, list classes and propose better name.
        • Scheduling and sync rules should be removed as rules #make issue

      • FMSE - flash polyfill for media source. Allows MSE to be used in older browsers. Streamroot and Akamai.

    • Project (docs, organization, workflow)

      • Best practice-guide for set up broadcast main/backup (=failover-scenarios) for Encoder -> CDN -> Player

        • Live streaming DASH - two encoders running independently (main, backup), segmentTimelines, manifests can differ. 24x7, how implement
        • Options 1) - Player is given two independent manifests and switches over with visible discontinuity.
        • Options 2) Sync the encoders - generate equivalent segments from each. Use wallclock for tfdt.

      • Who is testing on Smart TV's ?

        • Adobe will be playing
        • BBC are looking at it.
        • Simulators are available, but need ot test on actual set.
        • WAVE project
        • Start Slack channel and mine mailing list.

      • 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. * @lloyd has proposal for mandatory form - mpd, steps to reproduce. Action item to edit ISSUE_TEMPLATE. Have issue tag that says needs-more-info. Make clears its for bugs, point at FAQ about common problems.

      • Error handling in debug player.

        • Reference player needs to listen to errors and surface a warning.

      • Over-view of BrowserStack based dash.js test framework

        • BBC build dash.js and automate playback of list of mpds. Record results. Project is open source. Move to dashIF. @Dan - Add more tests. Process for adding new test vectors.
        • dash.js has account with browserstack.
        • Streamroot use Selenium.
        • Unit tests in DOM. Requires mock objects. Can Karma to run Mocha. #make issue.
        • Testing ABR logic - all tests runs with good connectivity. Stability tests. BrowserMob https://github.com/lightbody/browsermob-proxy - proxy that between asset and client, then with JS throttle bandwidth. @Assign to Kevin for summer - #make issue.

    • Open items: * Audio-only streams - BBC/Akamai care. * Several bugs assume video streams are present. * @Lloyd - add audio-only samples to reference. * Offline playback - #Make issue - for new feature. * What features need - support for t anchors, offline playback, multi-period, server-side ad support.

  • 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.
Add a custom footer
Add a custom sidebar
Clone this wiki locally