-
Notifications
You must be signed in to change notification settings - Fork 0
mpd: map top-level cenc and mspr values in mpd element #12
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
Conversation
| XsiNS *XmlnsAttr `xml:"xsi,attr,omitempty"` | ||
| XsiSchemaLocation *XsiSL `xml:"schemaLocation,attr,omitempty"` | ||
| XsiCENC *XmlnsAttr `xml:"cenc,attr,omitempty"` | ||
| XsiMSPR *XmlnsAttr `xml:"mspr,attr,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick q because idk enough about dash and drm, but this tag seems specific to PlayReady, was wondering if we were going to come across the same issues with Widevine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When looking at the P+ manifests, this covered the cases being outputted by Shaka for DASH + WV/PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krystalmejia24 I believe that should be fine.. for widevine it's the cenc & pssh block contains the details abt key/algo etc...
Q: @zsiec does this mean it will try to append this header on every manifest passing through bakery or does it have a way to check to only append these for drm manifests ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good. Curious if the idea is to leave this in a branch and stack changes on top of it for bakery? Do we plan on getting these up to master branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷🏽 Personally I don't like to leave branches like this. I would have preferred the other branch stay open until this is merged and we update the dependency sha on the bakery PR and a test case for this.
But seems like that is merged already upstream... so upto Thomas I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zsiec does this mean it will try to append this header on every manifest passing through bakery or does it have a way to check to only append these for drm manifests ?
My changes were mainly to support parsing and writing the values. They will only be added in bakery if they were parsed from the source MPD.
Yeah this branch should get merged (after we add a test), we should tag here and use that tag in Bakery when loading this lib. We should also see if there's interest in getting this patch merged upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.. perfect. I am just deploying bakery Image with this fix and can check a couple manifests and see how it works out.
No description provided.