Skip to content

Agenda for the 2018 Berlin face to face meeting May 14th

Jump to bottom Edit New page
Jesús Oliva edited this page May 15, 2018 · 15 revisions

09:00 – 9:30: Welcome

  • Registration, welcome coffee.

09:30 – 12:30: Morning session

  • Introductions

  • Dash.js project. Status & some numbers.

  • Documentation and examples (ABR, DRM, etc). Developer resources.

    • Waqarz - Architecture document. Classes hierarchy would be appreciated.
      • Action: Create documentation in the wiki explaining specific parts of dash.js. Examples:
        • How buffer management works? API methods related with buffer management.
        • How live starting point is calculated. API methods related with this.
        • Document manifest/chunk requests workflow.
    • Action: Re-structure/Re-layout samples page of dash.js. Samples should be easly browsable and focused on specific features. We will create different sections in samples page each one focused on one specific feature. Examples:
      • Captioning samples.
      • DRM samples.
      • Low Latency samples.
      • Thumbnails samples.
      • Etc.
    • Will - Enforce PRs of new features to come with samples.
      • Action: In the contribution guideline, add a note indicating every new feature must come with its respective sample page that demonstrate how it works and how it can be used.
    • Action: Link samples from documentation. Think on the best way of linking that doesn't require modifying links in documentation everytime they change.
    • Action: Review stream links of dash.js reference player. Removes the ones that are not working.
    • Test vectors coming from DASH-IF seems to have duplicated names. Current names are non very descriptive (test vector 1, test vector 2, etc):
      • Actions:
        • Waqar to open a fix in DASH-IF for test vectors so they include a short description.
    • Action: Reorder Streams menu so they are organized by features instead of a mix of feature/company name. Still keep company name but associated with the specific stream (Stream name - Company name).
    • Action: API documentation to show just MediaPlayer API. Remove modules and classes menus.

  • Improve logging - too verbose, add levels and filters. Log Events?

    • Action: Modify logging system to be level based. It will use the following levels:
      • debug: what we have today. Everything.
      • info: key events (ex: segment loaded, bitrate changes).
      • warning: (ex: timecode jumping, fetch is not available, EME not available, adaptations set that are not supported, semantic problems with the mpd that dont avoid playback to start).
      • error: errors that don't stop playback (ex: segment 404, codec errors - fallback).
      • fatal: Playback fails completely (codecs not supported).
    • Action: Modify log method so it has a level parameter and add a new method to MediaPlayer API so user can select from which level, logs will be writen in the console. Example: if user sets log level to be debug then all log messages will be writen to the console; if user sets log level to be warning then warning, error and fatal messages will be writen.
    • Action: Enable classname in logs by default.
    • Action: Deprecate log EVENT. Two dash.js versions after the deprecation it will be finally removed.

  • Errors Management.

    • We should have one type of event per type of error.
    • Manage errors always in the same way (triggering events instead of throwing exceptions).
    • Modify PR #2179 so it keeps backward compatibility. Set old event properties as deprecated and merge the PR as soon as possible. Remove deprecated event properties in dash.js 3.0
    • dash.js 2.7 to come at the end of May, dash.js 3.0 to come during summer
    • Actions:
      • Add test vectors that generate errors.
      • Nicolas will create a new PR which will replace #2179, that will homogenize errors management while keeping backward compatibility. Old error property names will be marked as deprecated. This PR will also replace errors that are currently managed throwing exceptions so they use events. This change will be included in dash.js 2.7.
      • In dash.js 2.7, add a note to the API indicating the properties that have been deprecated.
      • In dash.js 3.0 we will remove all the error event properties deprecated in 2.7.

  • Dash.js on low devices / Performance benchmarks.

    • Performance issues in chromecast, mainly when parsing manifest (xml to json process). Orange team reduced parsing time for Smooth streaming from 4-5 seconds to millisecond removing the xml to json process. Related with PR #2453 (action point later in this document).
    • Performance issues parsing long manifests. Mainly for live events (segment timeline).
    • Action: Include in logs profiling information of methods affected by perf (parsing).
    • Could web workers be a solution to perf issues? Action: Check level of compatibility in browsers before taking any action.
    • Computers not able to play high bitrates (CPU issues).
    • Action: Review ABR algorithm. How to manage drop frames situations? review drop frames threshold with regard to ABR algorithm.
    • Makes sense create, at documentation level, buffer length recommendations per device:
      • Action: Jesús will do some tests and will come with basic recommendations.
    • Action: Make empirical tests so performance issues are based on real numbers, which will allow us to measure impact of changes.

  • Functional tests.

    • Have a look at functional tests and issues with seeking and timeouts
    • Action: Functional tests are critical. Modifications to get them up and running as soon as possible:
      • 1.- Remove parts of functional tests that cause false positives (seeking timeouts).
      • 2.- Once point 1 is ready and working, analyze seeking timeout issues.
    • Action: Jesús to talk with browserstack to confirm we have the right environment.
    • In case browserstack continues being a problem, evaluate the idea of running our own instances for functional testing (selenium?) or different providers.
    • Action: Evaluate use of headless chrome for testing some features (ex: abr algorithm).
    • We may need our own machine to do functional tests that have hardware requirements (DRM).
    • Require unit tests to be included in PRs. Otherwise don't accept the PR. Already explained in the documentation, so it is just a matter of being more strict in the application of this rule.

  • DEMO: CMAF low latency. Status and next steps.

  • Low latency enhancements:

    • Action: Modify behavior of dash.js so, when playing live and the delay is higher than a given threshold, it catches up live time through playback rate increase. Configured with the following methods:
      • API for setting rate increase number.
      • API for setting live latency delay threshold. Beyond that, playback rate will be increased.
      • Not completed chunks issue -> file issue in browsers.
    • Concern: what should be the behavior in case of using low latency services with segment timeline.
    • Action: Add UI controls to dash.js reference player to control live latency (ex: live delay).
    • Documentation for live latency. How it works? What parameters affect it?.
    • Action: Finish low latency wiki page of dash.js and once ready, check it up with DASH-IF to see if we need to complete it.
    • Jump forward to live past a certain threshold of configurable latency (can we use this for sync across devices?).
      • Start implementing rate increase approach and don't do this one yet.

  • Trick play mode.

  • Action: Need to generate test vectors with adaptations for trick play mode.
  • We need to check how dash.js works with adaptation for trick play mode.
  • Don't play audio when trick mode is activated.
  • Adaptations for trick play must be used only when in trick play mode.

12:30 – 13:30: Lunch, Networking

13:30 – 17:00: Afternoon session

  • Development workflow / PR reviews.
  • Action: Add a note in the development guide so people knows how they can contribute approving pull requests.
  • Bi-weekly calls.
    • Announce topics before the call.
    • Action: Change coordination call to be once per month. Announce the change through our communication channel (Google Group, Slack).
  • Architecture - Requests/Segments/Manifest updates workflow.
    • Actions:
      • Given this changes part of the core of dash.js, split this change in two steps to guarantee we don't introduce any regression.
      • First, put all interface changes in dash.js v3.0.
      • Second, once dash.js v3.0 is released and tested, start coding the new procedure for requests management.
  • Handling missing/on error segments.
    • Action: Makes sense that number of retries are different for vod and live. Separate current "number of retry" configuration parameter in two, one for vod, one for live.
    • Action: Update documentation to say number of retries could be 0.
    • Action: Implements skip segments logic.
      • Add a new configuration parameter which will indicate that once a request fails (after retrying logic is completed), player should skip to the next segment.
      • Skip segment documentation: include a note about possible implications of skipping segments in live streams when we are getting 404 (errors because we are in live edge position).
    • Action: For live streaming, when a request fails do a resync before retrying. Limit the number of re-synchronizations: don't synchronize if the latest sync was done X seconds ago (X should be configurable).
    • Try same segment but with a different quality (how many qualities to test with? review Dave document to get a better idea).
    • Action: Dave (BBC) will share a document that describes failover mechanisms. We will take it as a reference. Taking or not actions regarding trying different qualities when there are fail requests will depends on failover mechanisms described in Dave document.
    • Action: Work on test vectors that raise missing/errors on segments.
  • Reset BlacklistController after url resolution failed (#2539).
  • Related with previous one (Handling missing/on error segments.). Wait for decisions taken on "Handling missing/on error segments." before taking any extra action.
  • DEMO - Multi Period Management changes. Reuse of MediaBuffers & Prefetching.
    • period-connect, there is time gap but codec can be reused.
    • period-continues, playback can continue. There is no time gap, there is no codec change. Use it as part of multi-period management change.
    • Better test vectors for multiperiod. No need to fix the ones that we have today (the ones not working in Chrome) because Chrome has already fixed the problems and patch will come in the next few weeks.
    • Action: Jesús will send to Waqar a list of possible test vectors that will enable testing different combinations of codec/parameters (ex: fps change during period transition, periods using segment timeline, etc).
    • Action: Review #2401 (review multiperiod with segment timeline). Nicolas: end of the first period seems to be not detected properly.
  • Dash.js and start-over in live channels. Dynamic -> static MPD. How control start of player at program start (anchor and/or mediaPresentationDuration).
  • Regarding Tobbe demo, seems dash.js behavior is ok with the spec. Right approach would be using an anchor to change the playback start position.
  • Encoder live to vod -> keep stream as dynamic and set mediaPresentationDuration property.
  • Offline playback for progressive webapps.
    • Actions:
      • Orange team is interested on working in this topic (interested on on-demand profile). Right approach would be adding it as an optional module (in the same way protection module works).
      • When recording, and using an API, user will have to indicate what are the renditions that should be recorded (max/min bitrates, which tracks should be recorded: multi video tracks, multi audio tracks).
      • Original manifest should be filtered/adapted so it points just to the "recorded" adaptations/representations/segments.
      • Jesús to send a message to the group to see if someone else is interested on working in this feature.
  • SAND message support for live in mobile environment.
    • Fraunhofer developing a separated library out of dash.js.
    • Add functionality to dash.js so it is able to parse and interpret SAND messages included in the MPD? Seems not appropriated, so instead of doing this, let's provide API methods that allows to implement SAND message support at the application level.
    • Application should have the possbility to modify manifest json objects when they are loaded and before they are parsed. This will allow SAND message implementation at the application level.
    • Take a more generic approach: anything retrieved by dash.js (manifest, segments, etc) should be interruptible (hooks), as a way of making it easy to extend from the app level.
    • Action:
      • Modify events related with content retrieval and make them to be interruptible. Add specific documentation for this and samples that shows how to do manifest manipulation from the application level. This will allow easily addition of SAND message support at the application level.

15:30 – 16:00: Coffee break

  • Leap seconds discussion.
  • Do nothing yet regarding this.
  • PR #2494 - Support of Audio/Video elements.
  • Actions:
    • Merge PR #2494.
    • Add a warning in case there are video tracks in a stream that is attached to an audio element.
    • Add an API method that allows the user to filter type of tracks attached (ex: use a video element but I don't want audio tracks to be attached) -> ignoreTrackType. ignoreTrackType is called automatically when using audio elements to ignore video tracks.
  • PR #2453 - ObjectIron replacement.
  • Action: Jesus to talk with nathan about moving ObjectIron modified version to src and license changes.
  • Industry needs / IOP conflicts.
    • Action: Create a flag (on by default) to allow or not IOP conflicts.
  • ABR algorithm. Thoughts. Issues, PRS (#2116, #2230).
    • Action: Given BBC has an environment for testing ABR, Jesús to talk with Rob about the possibility of involving him when there is a need to test changes in the ABR algorithm.
  • Reference Player
    • Improve UI of dash.js reference player -> Use of reference player as a debug tool.
    • Actions:
      • Improve graphs panel. Look for a new graph component. Fix problems in the graph panel when there are seeking operations.
      • Get a list of metrics that makes sense for debugging purposes and add them to reference player panel (example: segment duration).
      • Add a third panel with "global" information of the stream: stream duration, available adaptations, list of representations, etc.
      • Reduce size of video component. Add more space for debug information.
  • Open items & Wrap-up.
  • Take a group photo!

18:00 – 21:00: Group Dinner at “Opera Italiana”, 6 p.m. http://www.opera-italiana.com/en.html

Add a custom footer
Add a custom sidebar
Clone this wiki locally