Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BANDWIDTH format change on Twitch playlists #72

Closed
ilyalissoboi opened this issue Jul 14, 2016 · 3 comments
Closed

BANDWIDTH format change on Twitch playlists #72

ilyalissoboi opened this issue Jul 14, 2016 · 3 comments

Comments

@ilyalissoboi
Copy link

ilyalissoboi commented Jul 14, 2016

It appears that Twitch.tv is breaking/changing specification by producing master playlists that have bandwidth described by a floating point number instead of an integer.

An example of such a playlist can be seen here.

Is it possible to accommodate that change by changing the expected bandwidth format in the module?

@leandromoreira
Copy link
Contributor

leandromoreira commented Jul 14, 2016

BANDWIDTH

The value is a decimal-integer of bits per second.  It represents the peak segment bit rate of the Variant Stream.

I think we should let it parsed to int as is stated by the "official spec"

Maybe in the "worst" case we could normalize the value but that would imply that all values should be normalized (based on formats...), I don't know if this is good either.

Or a better solution would be returning a wrapper around int parser that removes any decimal float but then we're might hiding a non-expected spec....

@leandromoreira
Copy link
Contributor

@globocom/videos3 any thoughts?

@flavioribeiro
Copy link
Contributor

based on the example provided by @ilyalissoboi we can receive as float and cast to int

birme added a commit to Eyevinn/m3u8 that referenced this issue Oct 11, 2016
leandromoreira added a commit that referenced this issue Oct 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants