-
Notifications
You must be signed in to change notification settings - Fork 133
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
"No CDN to request" thrown when using templated MPD with relative paths #1190
Comments
Hi, You're right :/ The issue seems to happen only when there's no That's definitely a RxPlayer issue and I'll start work on a fix very soon but thankfully, it seems easy to work-around: you can set a Thanks for the report. I'll keep you updated through this issue. |
Thanks for taking a look and proposing a workaround. It works! I assume this is a good a time as any to sincerely thank you for your great work with this project. I think it's a stellar example of a well-managed project. Your in-depth release notes are always a fun read! |
Thanks a lot :), this is appreciated |
…rl and without BaseURL elements Fixes #1190 We brought in the last v3.29.0 a regression which made it impossible to play a DASH content in very specific conditions. Thankfully, the conditions to reproduce it are relatively rare and easy to work-around (as written in the issue). Basically it only happens when all following conditions are true: 1. You're playing a DASH content 2. You didn't communicate an `url` for the MPD (for now only works if you at least communicated either a `initialManifest` or a `manifestLoader`) 3. You didn't communicate about the MPD URL in the `manifestLoader` if you used one 4. The MPD does not contain any `<BaseURL>` element, or it does but only inside `<Representation>` elements (which means basically directly for each segments, e.g. in a `<SegmentList>` element). When those conditions are met, you will receive a `PIPELINE_LOAD_ERROR` error with the message `"No CDN to request"` when the RxPlayer is trying to request its first segment. --- This happens because since the RxPlayer v3.29.0, we try to identify one or multiple CDN through which segments may be requested. This is done at the `<Representation>` level. Under the specific conditions written earlier, MPD parsers will indicate an empty array as the CDN that can be used to reach that Representation's segments, because it has no way of defining even one root URL. In the corresponding `Manifest`'s structure documentation (the protocol-agnostic structure defined by the RxPlayer for a Manifest), an empty array is then documented as `An empty array means that no CDN are left to request the resource. As such, no resource can be loaded in that situation.`. So an empty array is for explicitly telling that the segment should be reachable through a potential CDN, but that no CDN is usable, at least right now. That's why the `"No CDN to request"` error was sent: the logic performing segment requests just wanted to load a segment, but saw that right now no CDN can be requested for it. To fix this situation, we could set that value to `null`, which exists, instead of an empty array. But this is how a `null` value is defined in the same `Manifest` structure: `null if there's no CDN involved here (e.g. resources are not requested through the network).` In that specific issue, the segment may perfectly be reachable through the network, we just don't know the root URL. We also risk breaking functional use cases if a full URL was actually declared for each segment. I thus hesitated between redefining the empty array and not throw in that case, redefining `null`, or to invent a third special case. For now, I chose to explicitly allow a new way of telling that an URL may exist, but should be entirely associated to each segment: by setting the empty string instead. This basically technically indicates - by following the logic already there - that all following URL are either absolute or relative to the page doing the requests, so it may imply a new strange behavior here when only relative segment URL are present (resulting in the browser considering the current page as the root URL), but I don't know how we should realistically act anyway in that specific case.
…rl and without BaseURL elements Fixes #1190 We brought in the last v3.29.0 a regression which made it impossible to play a DASH content in very specific conditions. Thankfully, the conditions to reproduce it are relatively rare and easy to work-around (as written in the issue). Basically it only happens when all following conditions are true: 1. You're playing a DASH content 2. You didn't communicate an `url` for the MPD (for now only works if you at least communicated either a `initialManifest` or a `manifestLoader`) 3. You didn't communicate about the MPD URL in the `manifestLoader` if you used one 4. The MPD does not contain any `<BaseURL>` element, or it does but only inside `<Representation>` elements (which means basically directly for each segments, e.g. in a `<SegmentList>` element). When those conditions are met, you will receive a `PIPELINE_LOAD_ERROR` error with the message `"No CDN to request"` when the RxPlayer is trying to request its first segment. --- This happens because since the RxPlayer v3.29.0, we try to identify one or multiple CDN through which segments may be requested. This is done at the `<Representation>` level. Under the specific conditions written earlier, MPD parsers will indicate an empty array as the CDN that can be used to reach that Representation's segments, because it has no way of defining even one root URL. In the corresponding `Manifest`'s structure documentation (the protocol-agnostic structure defined by the RxPlayer for a Manifest), an empty array is then documented as `An empty array means that no CDN are left to request the resource. As such, no resource can be loaded in that situation.`. So an empty array is for explicitly telling that the segment should be reachable through a potential CDN, but that no CDN is usable, at least right now. That's why the `"No CDN to request"` error was sent: the logic performing segment requests just wanted to load a segment, but saw that right now no CDN can be requested for it. To fix this situation, we could set that value to `null`, which exists, instead of an empty array. But this is how a `null` value is defined in the same `Manifest` structure: `null if there's no CDN involved here (e.g. resources are not requested through the network).` In that specific issue, the segment may perfectly be reachable through the network, we just don't know the root URL. We also risk breaking functional use cases if a full URL was actually declared for each segment. I thus hesitated between redefining the empty array and not throw in that case, redefining `null`, or to invent a third special case. For now, I chose to explicitly allow a new way of telling that an URL may exist, but should be entirely associated to each segment: by setting the empty string instead. This basically technically indicates - by following the logic already there - that all following URL are either absolute or relative to the page doing the requests, so it may imply a new strange behavior here when only relative segment URL are present (resulting in the browser considering the current page as the root URL), but I don't know how we should realistically act anyway in that specific case.
…rl and without BaseURL elements Fixes #1190 We brought in the last v3.29.0 a regression which made it impossible to play a DASH content in very specific conditions. Thankfully, the conditions to reproduce it are relatively rare and easy to work-around (as written in the issue). Basically it only happens when all following conditions are true: 1. You're playing a DASH content 2. You didn't communicate an `url` for the MPD (for now only works if you at least communicated either a `initialManifest` or a `manifestLoader`) 3. You didn't communicate about the MPD URL in the `manifestLoader` if you used one 4. The MPD does not contain any `<BaseURL>` element, or it does but only inside `<Representation>` elements (which means basically directly for each segments, e.g. in a `<SegmentList>` element). When those conditions are met, you will receive a `PIPELINE_LOAD_ERROR` error with the message `"No CDN to request"` when the RxPlayer is trying to request its first segment. --- This happens because since the RxPlayer v3.29.0, we try to identify one or multiple CDN through which segments may be requested. This is done at the `<Representation>` level. Under the specific conditions written earlier, MPD parsers will indicate an empty array as the CDN that can be used to reach that Representation's segments, because it has no way of defining even one root URL. In the corresponding `Manifest`'s structure documentation (the protocol-agnostic structure defined by the RxPlayer for a Manifest), an empty array is then documented as `An empty array means that no CDN are left to request the resource. As such, no resource can be loaded in that situation.`. So an empty array is for explicitly telling that the segment should be reachable through a potential CDN, but that no CDN is usable, at least right now. That's why the `"No CDN to request"` error was sent: the logic performing segment requests just wanted to load a segment, but saw that right now no CDN can be requested for it. To fix this situation, we could set that value to `null`, which exists, instead of an empty array. But this is how a `null` value is defined in the same `Manifest` structure: `null if there's no CDN involved here (e.g. resources are not requested through the network).` In that specific issue, the segment may perfectly be reachable through the network, we just don't know the root URL. We also risk breaking functional use cases if a full URL was actually declared for each segment. I thus hesitated between redefining the empty array and not throw in that case, redefining `null`, or to invent a third special case. For now, I chose to explicitly allow a new way of telling that an URL may exist, but should be entirely associated to each segment: by setting the empty string instead. This basically technically indicates - by following the logic already there - that all following URL are either absolute or relative to the page doing the requests, so it may imply a new strange behavior here when only relative segment URL are present (resulting in the browser considering the current page as the root URL), but I don't know how we should realistically act anyway in that specific case.
With v3.29.0, I cannot load a DASH playlist. I get the
No CDN to request
error (PIPELINE_LOAD_ERROR
). I assume this is due to the changes made to content steering in v3.29.0The playlist looks like this:
I use a custom segment loader to fetch the segments from a base path communicated via other means.
I've tried to find potential issues looking through #1165, but I didn't find anything concrete. I assume it could be due to the logic not being able to identify any CDN due to the use of relative paths.
The text was updated successfully, but these errors were encountered: