Meeting Minutes

This page contains the agenda for our next meeting and the minutes for our previous meetings. The call occurs every second Friday at 10:00-10:45 AM PST. Dial in number is 1-888-421-0060 PIN: 482202

Minutes: May 16th 2014

Attendees: Will, Jeff, Iraj, Kilroy,

1. Mozilla - EME announcement, using Adobe DRM, let's ask Streeter for clarification. MSE implementation using VP9 for Youtube. Please vote on this bug for MSE: https://bugzilla.mozilla.org/show_bug.cgi?id=778617 . Will ask Google to address next DASH IF meeting in SF.
2. Kirk working on live improvements and TTML. Kilroy - keep core API consistent in player.
3. Will to start writing new index page, others can improve.
4. Clearkey support ? - is there a standard for MSE or for DASH? Not for DASH-AVC/264. Need to add clearkey to DRM descriptor. We should push this within DASH IF IOP. DRM task force - make new addition. Kilroy will add to action items.
5. Box parsing for event message? MS have developers who would like to contribute, but have to get open source license stuff out the way first.
6. SCTE-35 messaging, agreements between major companies by Kilroy. Looking positive.

Minutes: May 2nd 2014

Attendees: Will, Dan, Jeff, Kirk, Kilroy, Beatrice,

1. Video.js: Steve had written interface between dash.js and video.js. General consensus that this is great. Code should be placed in contrib directory. Dan has reached out, working with Steve about player UI and will also reach out to JWPLayer to see if they have a interest in integrating. Kirk also noted that there is a real advantage in simplicity to have a player directly using DASH.js. even if the native HTML5 UI lacks features such as live DVR support. Dan to ask Frank@Akamai if they will contribute some base control UI that is capable of handling live DVR.
2. Will suggested that the default index.html page not be a single player but instead be a launch page to several players, such as native, native+basic UI, wrapped with video.js, wrapped with jw etc. Kirk would like the ability to select a sample file from a pulldown and then launch it in any one of these players. Jeff/Will would also like a common set of test links to be available in each player. Each project could source this list from dash.js so that we can manage the sample links and keep them current.
3. Items for 1.2 release: multi-period support (Digital Primates might look if they have time), events handling (Frauenhofer), TTML (Microsoft), live improvements + bug fixes (Microsoft)- documents, Token support for content protection (Akamai). Agree on a two month target sprint, which puts us around 15th July.
4. Kilroy - feedback that its hard on how code works. Mikhail is looking at how to split out the buffer controller so that it can be rule-based. This is separate from the object model changes requested from the project which should still be considered.
5. Live compatibility with Elemental - issue with buffer empty under Chrome, also reloading of init segments. Kirk - HEAD requests still failing against Akamai - Will to get investigation going.Will also repoted an issue with the buffer emtpying after the first 15s of the live stream and will open a issue on the site around this. Also a bug around repeated reloading of the init segments after a manifest refresh.
6. Kirk - has a version of TTML working using the same pattern of pushing raw events to the videoElement , as was done for WebVTT support. THis means only simple TTML support with no support for styling or verification of the xml. It does check to see if the browser supports the mime-type first and only uses the manual approach if native support for TTML is not present.
7. Kilroy has seen some open source test vectors for TTML and will get that info to Waqar and also the dash.js group.
8. Update on other browser support. Will to ask Mozilla about Firefox.

Minutes: April 18th 2014

Attendees: Dan, Jeff, Ross, Iraj, Nathan

1. Dan is back and able to contribute to the project again!
2. Fraunhofer Update - Ross has emailed Fraunhofer - Responded with they are at NAB. Ross to follow up with them after todays meeting.
3. Jeff- Talks at NAB went well and looks like there is a lot of interest in DASH.js. Group out of Paris is interested in contributing. Follow up in next meeting to see where we are with this topic.
4. Ross - Kirk not on call today but does know that TTML is being worked on - not sure about the progress without consulting Kirk.
5. Dan - Follow up on public page listing players using Dash.js to make sure it is up to date. Dan will add the Akamai support player and will start a thread to group asking for URLs to players that are not listed.
6. Ross - Going to talk with Kirk to see if he can take some time to get Dan caught up on live and align efforts for live playback going forward.
7. No update on this topic - Elemental and Mikhail/Kirk around dash.js support for manifests which update availabnilityStartTime.

Minutes: April 4th 2014

Attendees: Will, Ross, Jeff, Kirk,

1. The DASH IF voted in Geneva last week on the features they would like to see in the next sprint 1.2. The 3 highest ranked features were TTML support, Event message handling, both at manifest and segment level and Multi-period support.
2. Microsoft would like to take on TTML and refactoring scheduler. Fraunhofer had expressed a prior interest in picking up event messaging and mulit-period. Digital Primates might be able to contribute a developer's time too.
3. Ross to contact Fraunhofer about contributing to 1.2.
4. BBC have signed the CLA. Welcome abord!
5. Current email thread with Elemental and Mikhail/Kirk around dash.js support for manifests which update availabnilityStartTime. Hope to get this resolved soon.
6. Will and Jeff will give a talk about dash.js at the DASH TALKS seminar at NAB next Tuesday April 8th.

Minutes: March 21st, 2014

Attendees: Will, Jeff, Kirk, Nathan, Iraj, Kilroy, Ross,

1. Will also sees issues with 33.0.1750 on Macbook Air. Problem seems specific to hardware acceleration on certain GPUs. Problem seemed resolved in Chrome Canary. @Kirk - add to release notes for 1.1.2
2. Multiperiod - is it possible to create a sourceBuffer and add video without appending to a videoElement? No results yet.
3. Voting and 1.1.2 release - multiple live streams that work in player, template and timeline, improvements in how may segments are requested. Reduced logging. Eventing for metrics, gets events. Note that any math in javascript that produces a result > 2^53 math results in a RTE. Kilroy - other precision limits? Plan to vote and release today. @Kirk to push to /master and @Will to copy to dashif.org.
4. Refactoring on scheduling - summary feedback. Player getting complex due to many factors including promise architecture. Kirk suggested reduce complexity to make scenarios rule-specific. More straightforward compositional sets of rules for each scenario. Scenarios include features such as buffer length, live vs VO. Iraj requested that parameters can be set simply on each rule set.
5. Daniel Silhavy (Fraunhofer) - discussion #114. Agreed opn approach but it requires changes almost every class. Invite him to create fork, communicate that community . Let's encourage him to start putting his time in to it. Thanks.
6. Orange email - declaration of intent to add smooth streaming support. Welcome them to fork the code to create a smooth-enabled implementation, and then make pull requests for changes against the main dash.js master branch. @Kirk - don't diverge from our current agenda of providing great quality DASH playback. Kilroy anticipates proprietary ad systems will cause similar splits. Suggest send events for ads and then handle them in external packages.
7. Get list of 1.2 features at the dash IF face-to-face. Timeline, suggest for 3 months, align with each successive face-to-face meeting.

• refactoring sets of rules.
• low latency mode for live
• basic TTML support (same pattern)
• Event message handling (SCTE-35 hand-off) segment parsing. (client side.
• multiperiod support (fixing).

Minutes: March 7th, 2014

Attendees: Will, Rich, Jeff, Nathan, Kirk, Iraj, Ross,

Discussion items

1. Rich reports users of 33.0.1750 Chrome have decode issues on certain codecs. Disabled GPU acceleration seemed to fix it. If possible, he will distribute a URL so that others can verify. Nathan suggested ot file a Chromium bug as Google are reactive at fixing.
2. Multiperiod support discussed at length. Current solution is that player will instantiate a new videoElement for the new period and overlay it on the primary videoElement. Nathan suggested there is a new append mode for source buffers that is not well supported in browsers yet, where the browser does not try to interpret the media time, but simply plays the content it is given. The code that is appending must manage appending the content in the correct order. Will suggested testing if a sourceBuffer can be created and media added without that source buffer being attached to a videoElement. If so, the new source buffer could be queued up and added very quickly.
3. Iraj - noted that MPEG committee is considering adding support for constant periods. This might address period switch problems by essentially avoiding it. It will be a wehile until this mode is supported in brtowsers however.
4. Discussion of how far back from live player should choose to sit. Will suggested that rather than trying to pick one number for everyone, that instead the player operate in two live modes - low latency and stable playback. Could be set by properties or context selection. Jeff commented that the switching rules would need to understand which mode it was operating in, which is true.
5. Kirk made note that the requirement to establish time synchronization and find the live edge carries a lot of complexity in the client. SegmentTimeline avoids any requirement of time. Adding r=-1 to SegmentTimeline or using segment template adds in this complexity. Suggestion that we simplify things by restricting usage to segmentTimeline and having a reasonable (30s?) manifest refresh period. Decision to bring this point up at the face-to-face meeting in Geneva.
6. Kirk has pushed latest changes to dev branch and stood up a 1.1.1 candidate for release. The code is here:

https://github.com/Dash-Industry-Forum/dash.js/tree/development

The player can be tested here:

http://msopentech-dash-js-1-1-1.azurewebsites.net/index.html?version=all

Release Notes:

• Improved support for dynamic mpd type
• Added search for live edge.
• Added support for overlapped segment requests.
• Added support for multiple buffer levels.
• Refined error type on the eventbus to be more uniform.
• Added manifestLoaded type on the eventbus
• Add reset() to MediaPlayer.
• Added ScheduleWhilePaused property to MediaPlayer.
• Added BufferMax property to MediaPlayer.

Minutes: February 21st, 2014

Attendees: Will, Beatrice, Nathan, Iraj, Kirk,

Discussion items:

1. Kirk - has made bug fixes to his stream, is working with the DASH IF live vectors, along with MobiTV stream in IE. It is not working in Chrome, due to lack of support for 64-bit tfdt headers. Suggested that we ask Torbjorn to revert stream to 32-bit and then have it restart every 24hrs at night.
2. In parallel, Nathan can assist Torbjorn in sending in the bug to Aaron@Google. Once Chrome supports 64-bit, then we can update the test vector. Will to mount init segment and segment on Akamai and introduce Nathan and Torbjorn. Nathan also needs the source buffer init string. (codec + mimetype)
3. Finding live point is now working more efficiently. Kirk notices issues if you try to start right at a segment boundary, so current algorithm for live first play avoids this by calculating latest available segment, backing off one and then adding half a segment duration, to put the player squarely away from any segment edge discontinuities.
4. For seek, to solve same problem, suggestion is to always add previous segment. This can increase post-seek start-up time. Beatrice suggested that these segments can be loaded in parallel. This is a good strategy if the client throughput >> bitrate being requested. Iraj also suggested that the prior segment could be requested at the lowest bitrate level. This is also a good optimization, although it has the downside that if the user ever seeks back through that content they will experience a pronounced quality drop for just that segment.
5. Aggressive buffering is on by default. It can be changed by extending the request logic, or by a property setting which changes the buffer length to a fixed value. Kirk suggested property should be extended to allow the settings of a %buffer lenght, along with a min and max. Default values of 50%, 30s min and 300s were agreed upon. Will to write up an issue and Kirk to implement.
6. Bart's stream, not working - Will to put Bart and Kirk in touch
7. Nathan - closed a bunch of low hanging bugs and responded to list questions - thanks for that!

Minutes: February 7th, 2014

Attendees: Will, Dan, Kirk, Jeff, Nathan, Iraj, Beatrice.

Discussion items:

1. Live is still struggling with two main issues - 1) mpds are missing the @start attribute in the first period and 2) The presentationTimeOffset is not used to allow the player to calculate the offset between presentation time and media time. If presentationTime and media time == 0 at the start, then this attribute is not needed, however Kurts finds streams where media time is not 0 at the start and presentationTimeOffset is not specified. ACTIONS - Will and Kurt to let the owners of these streams aware of their deficiencies and get them corrected.
2. UI to show whats available to user. Current native UI only works with media time and does not support DVR windows. Decision to introduce APIs to allow a Javascript UI to be built by the player which can show the DVR capabilities better than native controls. Dash.js player can then show a sample control interface for live, although library itself will not implement the UI.
3. This group should communicate with Romain over at GPAC and ensure that we test with an early version of DashCast that they may have functioning.
4. Goal is release the 1.1 version in time for the Geneva face-to-face meetinfg of the DASH IF. Target date is therefore March 7th, one month from now.

Minutes: January 24th, 2014

Attendees: Will, Iraj, Bart, Kirk, Beatrice.

Discussion items:

1. Status of 1.1: For time-addressed content, working well. For numerical addressed, long time to start due to up to 30s mismatch between client and server time and having to seaarch linearly for the starting point. The search can be done at most at half the availability window, which makes it slow for streams with small or zero availability window. Additionally, some mpds have periods where the video timestamp does not match the presentation timeline and no presentationTimeOffset or periodStart was present. It was suggested that these should be flagged as invlaid manifests rather than spinning cycles trying to accommodate them in the player. 1. Long discussion on the new r=-1 parameter suggested for segment timeline. At the end of the day it still requires the client and server to be closely synced in terms of time. Since servers are usually NTP synced, this means client needs a good UTC reference.
2. Proposal in front of MPEG right now for the server to add a list of time sources to which the client can refer as a reference. UNtil this is standardized and implemnted by encoders, Will suggests using the akamai time source at http://jnc-time.edgesuite.net/ as a practical work around which can be overrideen once mpds contains other time source references.
3. Will to start a list of live streams which the current 1.1 dev branch should play. We can work through this list and either fix the mpd or fix the player. Currently the Unified Streaming time addressed live stream works the best.
4. Input from Mozilla around Air Mozilla - there is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=881512) titled "Implement enough of MSE to run the YT demo player" that has no blocking bugs at the moment.
5. Orange Networks (former France Telecom) also interested in participating - let's help out both of these organizations if they choose to participate.

Minutes: January 9th, 2014

Attendees: Will, Nathan, Bart, Jeff, Dan

Discussion items:

1. The 1.1 release is at http://msopentech-dash-js-livestreaming.azurewebsites.net/index.html?version=all and is locking up for many users under Chrome. No errors thrown in console. Not successfully playing live samples which was its purpose. These issues need to be reported to Kirk.
2. Bart - mentioned that Steve from Intel, interested in contributing. He will reach out and get him involved.
3. Nathan reported that inband messages need to be supported. Will create issue to track inband messaging.
4. Digital Primates are busy next 6 weeks but will be able to review code in the interim.
5. GPAC have been contracted by DASH IF to improve mp4box and DASH Cast to enable some reference packaging of content. Will to send scope of wrok to Bart. Anyone else who wnats a copy who is a DASH IF member then contact Will.
6. Dan to check on his availability in next few weeks for coding.

Minutes: Dec 13th, 2013

Present: Ross, Iraj, Beatrice, Kirk, Bart, Nathan

Live - Pull request today, not a full implementation. Segment Templates without timeline does work but can be very slow to start. We need more test content for Templates. Goal is to encourage testing of the live implementation.

SMW - attendance a little lower than usual. Sessions were reasonably well attended with some very interesting discussions. General feeling was that MPEG-DASH is largely seen as a "done deal" - people were looking forward to the next stage (e.g. HEVC). DASH-IF will be less

F2F - Player performed very well on stream compatibility (played more than other players) but was not doing very well under constrained network conditions. MS plan to set up some testing for this and will focus on it as they move forward. DASH.js contributors strongly encouraged to focus on this aspect of performance.

Mozilla - Ross reached out to Mozilla via their public channels to offer our support in testing their MSE implementation. No significant progress as yet.

Issue triage - There is a small but growing number of issues that need classifying as an initial response. Assistance welcome.

Agenda: Nov 14th, 2013

Present: Will, Ross, Nathan, Kirk, Iraj, Beatrice,

1. Review of actions items since last meeting

2. Ross triage and organize: low, med, high, critical. Critical should be incorporate in next release. Ad hoc, with periodic review when items grow above 5. See wiki for details - https://github.com/Dash-Industry-Forum/dash.js/wiki/How-to-Contribute

3. Will - time service and front end - can test at http://jnc-time.edgesuite.net/ (GET or HEAD), http://jnc-time.edgesuite.net/?iso and http://jnc-time.edgesuite.net/?xml. Plan is to mount at time.akamai.com. still underway.

4. Ross - LA for issue #32 - under way.

5. Current issues:

6. Kirk - scheduling changes now include the ability to handle high latency urls. Segements are requested in parallel and the code does not wiat for the prior request to complete beforemaking the next request. Will reported video quality problems testing on Mac Air, as the aggressive preloading up to 100% of the video seemed to reduce rendering resources. Suggest we cap the max buffer that will be built. 30s for content < 10min and 300s for content > 10min. These thresholds can be set as modifiable properties versus extensions,

7. Kirk - still OK right now for Mid Dec. , wrap up scheduling improvements, email on live , reach out for feedback.

8. At SMW west, we have a session on Wed 20th at 1;45 pm on the dash.js project. Ross talking about governance and openess and demo on IE 11 under Win 8.1, Jeff will talk about the code and demo on Chrome . Richard Leider from Google will talk about Youtube's use of DASH as well as EME in general.

9. Question asked about Mozilla supporting MSE. Heard that end of year had been a target. Decided we should reach out proactively to Mozilla to see if we can ensure that the dash.js player is compatible with their implementaiton form the beginning. Ross to look through his contact list and Will to contact Chris Blizzard.

10. At DASH IF face-to-face on Nov 22, Iraj asked that we come prepared to contribute to developing a plan for 2014 dev priorities. Will to generate a features matrix. Also talk about Waqar and the compliance tests, as well as collaboration between dash.js and DASH IF. Kirk/Ross will demo some of the newer features they have added. Only have one hour allocated for demos and planning.

Agenda: Nov 1, 2013

Present: Will, Jeff, Dave, Tim, Bart, Sandeep, Nathan, Ross, Beatrice, Kirk,

1. Review of actions items since last meeting

2. Ross - Issue on CLA# 32 ongoing

3. Ross - track downloads not so easy out of github. If we mount copies on a CDN, we can track those much more simply.

4. Kirk - Microsoft Open tech have to focus efforts in their live branch around scheduling of segments and concurrent requests. This is driven by customer demands on their end. This may threaten milestone 1.1 goal of mid-december . Kirk will inform us at next call in two weeks what the status is.

5. New discussion topics

6. Fandor - have integrated dash.js with production web application. Clients in QA at Google. Problems playing films have unplayable sections, receiving bytes, buffer rejecting them or timestamps not in right range. Segments are being returned by the server. Nathan suggested that the timestamps on the segments may be out of the range the sourcebuffer is expecting. Fandor to examine detailed console logs and also open issue on Github with a link to the offending mpd.

7. presentationDelayOffset - this is optional, but can be specified in the manifest to help a client correct for delivery delay once a segment leaves the encoder and is propagated through a CDN. Its not required however, so if it's not present clients should take in to account that a segment may not practically be available when it says it is.

8. SMW show - Jeff/Ross/Will in session on "C203: Building an Open Source DASH-AVC/264 Player". Jeff will talk about and demo v1.0 of dash.js. Ross will follow with some new developments from the MS branch.

9. DASH IF face-to-face. Kirk will be there from the 19th and will coordinate any client testing using. Will/Jeff/Ross to present task force within interop. Items to cover: A) Road-map, including any changes to live support and B) Improvements to the DASH spec around encoder/client co-operating to sync on time.

10. Will to mount a universally accessible reference time service on akamai. Will distribute details once it is in place.

11. Will to look in to having Akamai front github for delivery and if not feasible (due to forced SSL, or rights) then look at access rights for committers. Nathan offered a nightly build driven by Jenkins that could automatically FTP.

12. Ross- ownership of triage on issue tracker. See if carve out some time.

Agenda: October 17, 2013

Present: Beatrice, Nathan, Kirk, Iraj, Kilroy

1. Review of action items from last meeting

2. Kirk - Make a new issue around start-up logic and how we can optimize it. Plan to integrate that with the Live Streaming work. Possible to split the simultaneous segment request that is available in the Live Streaming branch and push it separately before the Live Streaming. Kirk is working with several developers including Dan.

3. ROSS: Need a CLA for #32 - ongoing Ongoing, Ross will contact the developer and approve the CLA.

4. ROSS: Is #33 stale? - yes issue is stale, now closed.

5. ROSS: Can we track usage of the tool? Ross raised this on the mailing list. No feedback from community yet. Tracking number of downloads is a great idea. The measurements will not be definitive and there is no guarantee that the developers will accept to share the data.

6. Discussion topics

7. Kirk - Live Streaming and Fast Segment Scheduling: UPDATE -
   Kirk is making good progress and most of the issues are related to: content, scheduling issues. We discussed two specific concerns:(1)The time of the server is 30,35 seconds different from the time on the client; when you request the segment for the current time on the client and trying to find the live edge what you get back is that it is not available yet, the first segment is not available until the current moment 35sec later, (2)availability start time coincides with the presentation time and you cannot download it until you are supposed to display it.

Action items based on discussions about the issues above:

• Contact content provider to fix the content used for testing. The content does not show any of the segments in the time buffer window from their current time; they start describing segments at "that moment" instead of "moment-time shift buffer window"
• in dash.js design for the segment timeline, start with the last available listed segment in the most recently available segment and backwards from there and see if it works.
• MPEG spec or DASH IF could add an interpretation regarding the presentation delay. The spec should not conduce to the interpretation that the presentation delay should be added to the current time of the segment and not be played until that moment. 0 should be a special value and should be defined as you do not apply the attribute.

2. Static noise while switching audio bitrates. Track as issue #69. has anyone verified this issue? No, it is browser dependent and not reproducing with IE11. Either the developer help us with more investigations either will wait until Kirk and Nathan become available.
3. 1.1 Milestone issue review: see https://github.com/Dash-Industry-Forum/dash.js/issues?labels=&milestone=2&page=1&state=open Most of these issues are assigned to Kirk and resolved or to be resolved in the Live Streaming branch. Issue #32 CLA need Issue #80 Nathan could not repro, will look into it at some point
4. Seek fails on a specific Video (issue #75) - Senthil - confirmed on Chrome - can we duplicate. Pull request from developer to be accepted after Ross confirms CLA was signed.
5. Review of new issues, do any need to go into Milestone 1.1 - see https://github.com/Dash-Industry-Forum/dash.js/issues?state=open Issue #79 Kirk will close by design Issue #78 Kirk will play with it Issue #77 is an enhancement and Kirk could look into it when he has time.

Minutes: October 3, 2013

Present: Ross, Dan, Beatrice, Nathan, Kirk, Iraj, Senthil

1. Review of action items from last meeting

2. Kirk - Make new issue - UI to show target bandwidth #71 - DONE

3. Kirk - Make a new issue around start-up logic and how we can optimize it.

4. Discussion topics

5. Kirk - Live Streaming and Fast Segment Scheduling: UPDATE? Targetting end of November to submit to dash.js.

6. Static noise while switching audio bitrates. Track as issue #69

7. DASH-IF needs to supply a contributor who can focus on conformance if that is their primary desire. Discussed in IP meeting last Tuesday - a representative is testing conformance. We need to liaise better with IOP when major features are added. Longer term we could consider automating execution of the test vectors - how many of these don't require human observation. MS Open Tech have been working on an integration.

8. 1.1 Milestone issue prioritization. Ross closed 1.0 Milestone. created a 1.1 Milestone (Dec 16th). Moved open 1.0 issues to it. ACTION: identify other issues for 1.1 release

• DASH IF F2F is Nov 20th/21st - target this date for integration testing
• We reviewed open issues and assigned to Milestone 1.1 as appropriate

2. ROSS: Need a CLA for #32
3. Ross: Is #33 stale?
4. Seek fails on a specific Video (issue #75) - Senthil - confirmed on Chrome - can we duplicate

• Nobody has attempted to reproduce yet

2. Can we track usage of the tool? Ross to raise on the mailing list

MINUTES: September 20, 2013

Present: Will, Nathan, Jeff, Sandhin, Kirk,

1. Review of action items from last meeting
2. CLA from Nate Burr has been received
3. Nathan - Updated contributor list - done
4. Dan - captioning html file - done
5. Discussion topics
6. Kirk - A player using dash.js should be notified when the manifest is updated and be able to access a subset of the data in the manifest. Decision to use existing eventbus, with event 'ManifestUpdated'. Current UI only lets switch methods, method accepts value. Make new issue - UI to show target bandwidth.
7. Kirk - Live Streaming and Fast Segment Scheduling, in process. SegmentTemplate not working correctly.Predicts end of November to submit to dash.js.
8. Herman - Static noise while switching audio bitrates . Track as issue. On both browsers. #69
9. From last call - should performance logic be built into dash.js or is dash.js more of a conformance tool? Agreed that motivation of current participants is performance over conformance. DASH IF needs to supply a contributor who can focus on conformance if that is their primary desire.
10. Next milestone, which issues should we tackle and what number will it be - 1.1 or 2? Decided on 1.1 with a primary emphasis on Live. Would like to have fewer, smaller releases. End of November to submit to dash.js repository. Issues woith live; timestamp offset on media streams to presentaiton time to video player.
11. Senthil introduced himself. Based in Bangalore, individual contributor.
12. As part of live, Kirk is looking at parallel request in live branch. Each video/audio/text segment for a given time point is requested in parallel. Akamai is interested in extending to parallel sub-segment range requests.
13. Make a new issue around start-up logic and how we can optimize it.

MINUTES: September 06, 2013

Present: Dan, Jeff, Iraj, Nathan. Kilroy (My apologies, I believe I am missing one person from this list. Please email the group if you were present and not on this list.)

1. Review of actions items since last meeting

2. No update yet - We need the CLA from Nate Burr so can anybody please nudge him to send it in.

3. No update yet - File a bug with Chrome for handling AVC3 codecs

4. Bug was files for incorrect index being shown and a fix was submitted and integrated into dev branch.

5. Phase one of VTT caption support was discussed, completed, and has been integrated into dev branch.

6. Jquery has been removed from dash.js - Thanks for the effort from Nathan.

7. Release of 1.0

8. Nathan is updating the contributor list with the two that responded to his email.

9. Dan create a captioning.html file with caption test MPD as src.

10. Nathan is preparing the build today to be voted on. Please vote. Looking to get the release out by Monday.

11. Current pulls - what's in motion, problems, questions

12. #32 Leading 0's - Nathan believes that Kirk is following up on this but is not sure. Kirk is not present to confirm.

13. #65 Replace img - Nathan has not seen this contributor before so we need to follow up and see if CLA is signed/needed. Side note - This change is only three lines and so Nathan added the change to the dev branch manually.

14. 52 - Multilevel buffer - All agreed to push off the to 1.1 release since there is some question about startup on IE and Kirk (whom is out of the office) has not been able to confirm if the changes submitted this week by Dan fixed the issue.

15. Other Topics - Should performance logic be built into dash.js or is dash.js more of a conformance tool? How much time should be spent on trying to get performance perfect? This topic was raised based on multi-level buffer and startup times. Some proposed changes were:

16. Should we modify rules to not switch up as quickly at startup until the buffer length is stable. This will get us a faster startup time and less buffer underrun errors.

17. Logic to start on the most suitable index based on bandwidth measurements and other intelligence.

18. Fragment abandonment logic that tries to prevent a buffer underrun at startup.

19. Conclusion: We should add performance enhancements into dash.js but do so in a very extensible way.

MINUTES: August 23rd, 2013

Present: Will, Jeff, Kirk, Dan, Ross, Iraj, Nathan, Jan

1. Review of action items from last meeting

2. We need the CLA from Nate so can anybody please nudge him to send it in.

3. File a bug with Chrome for handling AVC3 codecs. Will

4. Current pulls - what's in motion, problems, questions

5. Dan found a bug with the incorrect max index being shown. He is going to file an issue and investigate it.

6. Concerning issue #33 on out-of-band captioning support. Dan has investigated and will pick up this issue. VTT is supported natively by both IE11 and Chrome. A subset of TTML is supported natively by IE11. Discussed implementation options and the group decided that implementation would be broken in to 2 phases. The goal for the MIlestone1 release will be Phase1 only: 2.2 Phase1: take VTT urls referenced in the manifest in Chrome (and VTT/TTML in IE11) and feed their bytes directly in to a SourceBuffer, along side the audio and video SourceBuffers already being created. This should always be done if the browser can handle the caption format natively. 2.2 Phase2: for incoming formats that are not supported on that browser, retrieve and parse the caption file and then use the TextTrack APIs to dynamically add a text track to the element and populate it with the appropriate cues.

7. Status on Milestone 1 and 1.0 release. (#22) - Will Withdraw (#18) - Kirk - close (#17) - Kirk multiperiod - close (#11) - Will withdraw but make make high priority for next milestone as several potential users ahve complained about the size of the library. Currently debug.js and error.js use JQuery to implement UI features. We should refactor the solution to move these out of the core library and in to the player implementation.

8. Other items.

9. Ross - add a wiki entry for a simple process, using existing github tools, for keeping a common and accessible list of filed CLAs.

10. Normal release for snapshot 0.2.6 by Friday Sept 30th. Nathan will mount DASH IF. Iraj will send out link for DASH IF community review until Friday Sept 6. All* Aim for the formal 1.0 release on Monday Sept 9th just in time for IBC :)

MINUTES: August 8th, 2013

Present: Will, Dan, Bart, Ross, Nathan, Kirk, Iraj, Kilroy, jan,

1. Approval of minutes of July 25th meeting - Approved.
2. Actions items
3. Need a CFA from Nate Burr - Will to ask.
4. Dan to restructure his submission to create a new "Adaptive Buffering" branch and add the enhancements to the DashContext instead of a separate AkamaiContext. Make sure new branch is off of latest dev branch. Cancel old pull request and isue a new pull request ocne this is done.
5. Status of pulls
6. #32 "Leading 0's in SementTemplate and IE11 meta tag" waiting on later fix by Nate Burr. Kirk is monitoring this.
7. #38 will should self-commit as there were no comments and it is text only.
8. #41 will be withdrawn and resubmitted (see Dan's item above).
9. Status of Milestone 1 issues.
10. For captioning, Kilroy to ask W3C for reference TTML implementation. Ross to send links to OS projects that have parsers. Dan to see if he would be able to work on it.
11. Adding Fork Me Ribbon, Did you know we have a page at http://dash-industry-forum.github.io/dash.js/ - Action Nathan add to index.html.
12. Other items
13. Seeking with numerical segments of variable duration. Kilroy pointed out that segmnetTimeline should be used as the adressing scheme any time there is any variability in the segment durations.
14. Kilroy is having someone examine the problem of figuring out the playback edge under live and VOD. ** Will** to send the document form Thomas that lays out the live use cases and the manifest @attributes to expect.
15. dash.js will particpate in the IBC virtual interop demo for both VOD and LIVE. Will to ask encoder particpants what segment addressing/duration they will be using. We'll get demo streams in late August and will test. Should prepare verison of player with just those streams available in the pull-down.
16. Test new mp4box demuxing capabilities for packaging content for DASH-AVC/264.
17. Handling AVC3 and HEVC init behavior - Kilroy to give info to Kirk to open up an issue to track this.

MINUTES: July 25th, 2013

Present - Will, Rich, Dan, Nathan, Kirk, Ross, Iraj, Beatrice,

1. Approval of minutes from July 12th meeting - correction, Ross was absent. Edited to fix.
2. Action items status - all complete fomr last week except
3. Will to adjust readme in master and dev to emphasize that pull requests should be against dev.
4. Tim Williams has a pull request waiting. Nathan or Kirk to review.
5. Kaltura need to sign CFA - Will to contact.
6. Open issues
7. New Thomson urls are using AVC3 codec, on the server is a duplicate version that is AVC1. Kirk to switch references URLs in pull-down stream
8. Dan has issue with charts having a fixed Y-max value - he will investigate
9. Akamai suggesting that index.html be modified to allow a different context (and player instance)to be used with each LOAD. Dan to mount prototype for comment prior to issuing pull request.
10. Report on the client comparison tests run by DASH IF in San Jose - competed with a Qualcomm, BuyDRM clients. Run dash.js under IE and Chrome. dash.js performed poorly in the concurrent playback tests, where multiple clients were competing for scarce bandwidth. BuyDRM client uses parallel requests to dominate bandwidth. We should implement a similar scheme - Will open issue to track this.
11. 0.2.5 Release went out. Latest player available at http://dashif.org/reference/players/javascript/0.2.5/index.html
12. For Milestone 1.0, EME and Multiperiod support are underway and picked up by Kirk. Captioning support: VOD only. Feature must be able to detect a cpation URL in the manifest, XHR it and then feed it in to the video.text buffer. If the browser does not support that format, then it should parse the caption file, sync it and display it in a div over the video object.
13. Create wiki page for users to register their players which are derivatives of dash.js. (Example: Kaltura). Will to make.

MINUTES: July 12th, 2013

Present - Will, Beatrice, Angelo, Jan, Nathan, Iraj, Kirk,

1. Approval of minutes from June 14th meeting - approved. Items marked as in-progress for Ross are complete.
2. Review open bugs - 2. #30 - Support for Edit List, necessary to support Universal Pictures initiative for EME playback 2. #22 - Autoplay not working correctly 2. #21 - Snowy video - test on Ubuntu be generating a progressive asset and if that is also snowy then close bug as wont-fix. 2. #18 - playing EME content. Kirk to open a new branch for dev of EME features. IE11 carries EME support for playready, but not clearkey. 2. #17 - multi-period support, Fraunhofer Fokus already have an implementation. Will to ask if they are interested in submitting.
3. External contributors submitted to master. Nathan to merge with dev. Will to update read-me to make it clear that pull requests shouold be against dev.
4. 0.2.5 Release - voted down by Jeff/Nathan since test vector support in Chrome has regressed since 0.2.3. Issue #31 opened to address this issue. Kirk to take a look.
5. DASH IF conducting tests on Tuesday morning July 16th. Jeff will manage testing against client under Chrome and Kirk under IE. Use the best version for the job if it is not 0.2.4 or 0.2.5
6. We have a one hour section allocated to the reference client during dash.js f2f on Tuesday at 6.30pm. We'll do some demos and also discuss feature priority. Will to create table of DASH spec requirements and dash.js capabilities.
7. New test vectors from Thompson causing codec errors in both IE and Chrome. Decided to track these errors as issues with a TEST_VECTOR prefix and see how that works. Push back to Waqar - Nathan and Kirk
8. Congrats to Ross to being elected President of the Apache Software Foundation. Appreciate you experience on this project.

---

MINUTES: June 14th, 2013

Present: Ross, Jeff, Jan, Kirk, Iraj, Beatrice

Approval of Minutes from May 31st Meeting

Minutes of May 31st Meeting were approved with the [no changes/the following changes]

Status Update

Outstanding Actions

1. DONE: Ross Add issue to remove JQuery library
2. DONE: Ross Add issue to add JS library concatenation and minification to build
3. DONE: Ross To share blog post with Jeff and Iraj
4. IN PROGRESS: Ross to mount gov doc on wiki. 1. DONE: Need new page to list roles (see https://github.com/Dash-Industry-Forum/dash.js/wiki/governance-model) 1. DONE: Describe decision making process (see https://github.com/Dash-Industry-Forum/dash.js/wiki/governance-model) 1. Expand contribution process 1. DONE: Define draft release process 1. DONE: Map GitHub roles to project roles

Release management

We agreed to adopt a feature branch management process. It was noted that we need to also define a release management process. Since MS Open Tech is nearing completion of an important feature we would like to agree the release process now, so that we are ready to implement it when the time comes.

Ross has written an outline process at https://github.com/Dash-Industry-Forum/dash.js/wiki/Release-Management and will add details to this as necessary.

Questions:

• what is a reasonable time to allow for feature branch review?
  • that is how long is Lazy Consensus on a pull request?
  • 96hrs minimum, account for long weekends etc.
• how long does the IWG need to test and approve a release candidate?
  • not needed for minor releases
  • assumption is that developers have run tests
  • 2 weeks needed for approval
• do we need a release branch for official releases?
  • Kirk: to drive to discussion on the mailing list
• in what form should the release candidate be provided to the IWG?
  • delayed this discussion item in the interests of time
• how is the website updated once a release is made?
  • Jeff has access to the javascript landing page and can add a link to the latest version
  • Will does the rest of the website
• who should perform the website updates?
  • Iraj: can give appropriate people access to website
  • Iraj: we can have candidate releases on the website
  • When there is an approved release main website will change to showcase the approved release
• How do we publicise release
  • delayed this discussion item in the interests of time
  • for 0.*.0 releases?
  • for 0.2.* releases?
  • for 1.0.0 release?

Role identification

Ross has created a new GitHub team for DASH.js committers. This allows us to map governance model roles to git roles (updated the wiki page accordingly).

Should any of the current "project coordinators" be moved to the "committer" role?

Next release

Given that MS Open Tech will be creating a new release in the near future (to incorporate their recent work) we ought to set a target date and expected features.

Future Release planning

What process should we adopt for release planning?

• Do we want to create a roadmap or be responsive to community contributions?
  • DASH-IF would like a roadmap
  • Defined by a collaboration between IOP and DASH.js
  • Roadmap should be managed by IOP, DASH.js follow in Issue tracker
  • DASH.js have the discussion and prioritise in issue tracker based on available resources and interest
• Do we want a regular release cycle?
  • delayed this discussion item in the interests of time

What constitutes a 0..0 release and a 0.12. release? - delayed this discussion item in the interests of time

What is our target for a 1.0 release? - DASH-AVC/264 fully implemented

Outreach activities

• June 13th Press event cancelled
  • Press release scheduled June 19th
  • Press conference scheduled June 27th
• MS Open Tech blog delayed at request of PWG
  • Currently planned for June 20th

DRAFT MINUTES: May 31st, 2013

Present: Ross, Jeff, Will, Iraj, Kirk, Nathan, Beatrice, Kilroy,

Approval of Minutes from May 17th Meeting

Minutes of May 17th Meeting were approved with the no changes.

Status Update

Actions from May 17th Meeting

1. DONE: Add read-me for how-to run grunt and tests - Kirk
2. DONE: Ross to add Kirk as Admin, to take role of Project Committer
3. IN PROGRESS: Ross to mount gov doc on wiki.
   1. DONE: Need new page to list roles (see https://github.com/Dash-Industry-Forum/dash.js/wiki/governance-model)
   2. DONE: Describe decision making process (see https://github.com/Dash-Industry-Forum/dash.js/wiki/governance-model)
   3. Expand contribution process
   4. Map GitHub roles to project roles
4. DONE: Bart sends out doc for integration changes - http://nvie.com/posts/a-successful-git-branching-model/
5. DONE: Nathan response to pull request from Adam and **Ross **will follow-up with him about procedure.
6. DONE Send copy of any signed feedback agreements to DASH IF Exec Director for safe-keeping. Will to do.
7. DONE: Ask Google for logo to add to contributors section of player - Will.
8. DONE: Will to make bullet points for Jan. Jan to pimp Jeff's session at SME next week.
9. DONE Nathan send Kirk list of test vectors that don't work in Chrome to test in IE.
10. DONE: At SME, the general DASH session will announce the project and demo the player. Jeff goes in to deeper dive. Current status is that project is announced but we will defer 1.0 release until broader compatibility is achieved against test vectors after browser upgrades.

Discussion Items

Feedback from Streaming Media East

Jeff provided feedback from his session at Streaming Media East.

• Couple of good sessions.
• Lots of good feedback and interest.
• Will observed that in the demo it was hard to see debug player details, e.g. unable to see it was a 6Mb stream at 1080p, and unable to see bandwidth throttling.
  • Perhaps have some other items of importance, e.g. overlay advertising.

Code Coordination Strategy

Bart proposed a branching strategy

Kirk suggests the project is not large enough yet, but Nathan recognised it as the process used internally at Digital Primates. Since the process does not add significant overhead it was agreed that the project will adopt this process of code management now so that we are ready to scale as appropriate.

There is an open issue with respect to how the project agrees that branches are pushed to master. This will be addressed by active developers over the coming weeks and months.

Better JS Library management

Will observes we need all these external libraries to function. (UI excluded)

<!-- Libraries -->
<script src="app/lib/jquery/js/jquery-1.8.3.min.js"></script> 94KB
<script src="app/lib/q.js"></script> 46KB
<script src="app/lib/dijon.js"></script> 22KB
<script src="app/lib/xml2json.js"></script> 10KB
<script src="app/lib/objectiron.js"></script> 7KB
<script src="app/lib/long.js"></script> 23KB
<script src="app/lib/Math.js"></script> 1KB

<!-- Minified Dash -->
<script src="dash.min.js"></script> 72KB

Do we really need all of these? Could we replace the entire library with a few functions that are actually used? Right now we have a download of 275KB to play adaptive content. The Flash code we have to do the same is 42KB.

The general goals could be expressed as:

1. using as little of external libraries as possible
2. keeping the minimum code necessary for playback to < 50KB.
3. if having a external libraries is unavoidable, then can we aggregate while minimizing so that there is a single dash.min.js which in a single GET request delivers all the necessary code for playback.

Jeff suggests JQuery might be removable Will requests that other files are bundled an minimized Jeff Perhaps we should to make this happen at build time

It was agreed to create issues for the removal of JQuery and the automation of bundling of libraries at build time.

Keeping the project community informed.

Ross observes that bi-weekly meetings can be productive but they can also exclude community members unable to attend.

Ross proposes that no decisions are made in meetings. Such meetings should create proposals which will be submitted to the mailing list and subject to the appropriate decision making process this will ensure maximum participation and oversight from project members. Meeting minutes will therefore be shared via the mailing list after each meeting.

After we clarified that these items need not be voted upon in most cases (approved by lazy consensus) this proposal was accepted.

Proposed Decision making process

Ross Shared a document on decision making process via the mailing list. This is under review via the lazy consensus process.

Ross encouraged attendees at the meeting to review the page and raise any issues on the mailing list.

Using mailing list

The team are encouraged to use the mailing list as much as possible for communications as this encourages third parties to participate in the project.

Press coverage

DASH-IF press conference week of June 10th press release

ACTIONS:

1. DONE: Ross Add issue to remove JQuery library
2. DONE: Ross Add issue to add JS library concatenation and minification to build

Minutes: May 17, 2013

Present Will, Jeff, Bart, Kirk, Angelo, Nathan, Alex, Ross, Jan, Iraj, Kilroy, Beatrice

Agenda

1. Confirm time for meeting or ask for adjustments - stick with time. 10h00 PST every two weeks starting May 17th
2. Switch over to DASH IF audio and webex for future calls - from next meeting. Will to update meeting invite.
3. Summarize updates to site
4. License headers added to files
5. "How to contribute" section added to wiki, along with links to the feedback agreement.
6. Reference player updated to v0.2.3
7. MS code - fixes for other browsers, test infrastructure, using grunt.
8. Add read-me for how-to run grunt and tests - Kirk.
9. Ross to add Kirk as Admin, to take role of Project Committer.
10. Governance doc distributed by Ross - discussed and approved by those present. . Need continuous integration later. Ross to mount gov doc on wiki. Need new page to list roles.
11. Bart sends out doc for integration changes - http://nvie.com/posts/a-successful-git-branching-model/ - please review.
12. Open pull requests - who is reviewing - Nathan is looking. **Nathan **response to pull request from Adam and **Ross **will follow-up with him about procedure.
13. Send copy of any signed feedback agreements to DASH IF Exec Director for safe-keeping. Will to do.
14. Ask Google for logo to add to contributors section of player - Will.
15. Will to make bullet points for Jan. Jan to pimp Jeff's session at SME next week.
16. Nathan send Kirk list of test vectors that don't work in Chrome to test in IE. . 13 At SME, the general DASH session will announce the project and demo the player. Jeff goes in to deeper dive. Current status is that project is announced but we will defer 1.0 release until broader compatibility is achieved against test vectors after browser upgrades.

Minutes: April 26, 2013

Present Will, Doug, Ross, Bart, Angelo, Yojak, Jeff, Steve, Nathan, Kirk, John, Rich, Vishal, Makoto,Charles

Agenda

1. Introduction and welcome.
2. Legal Summary - DASH IF members are now covered by changes to the Bylaws and IPR declaration, which allow for members submission to open Source projects administered by the Forum, under BSD-3 clause license. Non-DASH IF members can also contribute, but must first sign the Feedback agreement Feedback Agreement. Will will mount these on a wiki page. All submitters must sign prior to requesting a pull. Will will ask Google to sign feedback agreement.
3. All files must carry the new BSD header - Will to provide to Nathan.
4. Get firm commitments from those interested in submitting: Digital Primates, Akamai, Microsoft, Path1.
5. Establish procedure and process for a) reviewing pull-requests. Submitters will be able to nominate admin. Review to be described in doc shortly after call, sent out by Ross.
6. Establish procedure and process for bug submission, triage,and assignment. Admin will respond to bugs. Noted that may outgrow github bug submission quickly, but will start with that.
7. Establish procedure and process for establishing scope and timelines. Requirement to satisfy DASH-AVC/264 test vectors is a common requirement for DASH IF members.
8. Everyone should join the "dashjs" Google Group listserver at https://groups.google.com/d/forum/dashjs.
9. Establish a bi-weekly working call. Suggest Friday at 10h00 PT every two weeks starting today. I need a volunteer to run the calls if I am out. Ross volunteers.
10. Other items? Iraj, suggest create new repro to make a clean transition. Will objected as being disruptive to what has already been established. Compromised on a code review by Jeff/Ross within the next two weeks and a commitment to have legal coverage for the one non-DASH IF submission within the same time period.
11. Kirk (MS) noted that submitted Google test code not directly applicable to player. Ross suggests two repositories. Another suggestionfor same repo, different directory. Bart seconds one repro, separate directory. We'll go with a separate Test directory for now.