Skip to content

Numeric Period IDs incorrectly parsed into Number type when should be kept as a string

Created by: matt-hammond-001

Environment
  • Dash.js version: 2.3
  • Browser name/version: Google Chrome 52.0.2743.116 (64-bit)
  • OS name/version: Mac OS X 10.11.6
Steps to reproduce
  1. Create an MPD where there is a period with id="1"
  2. Play the stream using a MediaPlayer
  3. Try calling mediaPlayer.time("1")
  4. Try calling mediaPlayer.time(1)
Observed behaviour

Step (3) returns null when it should return current time relative to start of period "1". Step (4) returns a time position since start of period "1".

Cause

The dash parser matcher for numbers [1] matches any attribute that can be parsed as a numeric value, including attributes such as @id which, according to the dash schema should be treated as strings.

Consequence

The numeric matcher converts the attribute using parseFloat(). This means that two differently named periods could end up with the same period ID, for example:

> parseFloat("1.0")
1
> parseFloat("1")
1

[1] https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/dash/parser/matchers/NumericMatcher.js

I will work on a PR to address this.