In segmented streams, "segment-by-segment" resolution generates a high volume of requests that could be reduced. This is especially noticeable in live/premiere HLS: since segments are usually short (e.g., ~1s), maintaining playback requires continuously resolving new URLs, resulting in several repeated calls just to advance playback.
The suggestion is to extend POST /resolve_url with an optional mode to resolve more than one URL per call, returning a small list of the next URLs already resolved and ready for use, with a fixed and low limit (e.g., 5 items). This allows the client to advance several segments at once and reduce the frequency of calls to the service, while the limit prevents this from becoming "resolving a large quantity at once" and reduces the potential for abuse.
For SABR, the proposal is the same: instead of resolving a single segment per call, allow resolving a small list of URLs at once. In practice, the client keeps the next segments already prepared in memory and consumes them as needed, without having to call the service for each advancement.
Request example (same endpoint, list mode)
{
"player_url": "https://.../base.js",
"signature_key": "sig",
"streams": [
{
"index": 1,
"stream_url": "https://.../videoplayback?...&sq=100&sig=ENCRYPTED&n=ENCRYPTED",
"encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE",
"n_param": "ENCRYPTED_N_VALUE"
},
{
"index": 2,
"stream_url": "https://.../videoplayback?...&sq=101&sig=ENCRYPTED&n=ENCRYPTED",
"encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE",
"n_param": "ENCRYPTED_N_VALUE"
},
{
"index": 3,
"stream_url": "https://.../videoplayback?...&sq=102&sig=ENCRYPTED&n=ENCRYPTED",
"encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE",
"n_param": "ENCRYPTED_N_VALUE"
},
{
"index": 4,
"stream_url": "https://.../videoplayback?...&sq=103&sig=ENCRYPTED&n=ENCRYPTED",
"encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE",
"n_param": "ENCRYPTED_N_VALUE"
},
{
"index": 5,
"stream_url": "https://.../videoplayback?...&sq=104&sig=ENCRYPTED&n=ENCRYPTED",
"encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE",
"n_param": "ENCRYPTED_N_VALUE"
}
]
}Response example
{
"results": [
{ "index": 1, "resolved_url": "https://.../videoplayback?...&sq=100&sig=DECRYPTED_SIG&n=DECRYPTED_N" },
{ "index": 2, "resolved_url": "https://.../videoplayback?...&sq=101&sig=DECRYPTED_SIG&n=DECRYPTED_N" },
{ "index": 3, "resolved_url": "https://.../videoplayback?...&sq=102&sig=DECRYPTED_SIG&n=DECRYPTED_N" },
{ "index": 4, "resolved_url": "https://.../videoplayback?...&sq=103&sig=DECRYPTED_SIG&n=DECRYPTED_N" },
{ "index": 5, "resolved_url": "https://.../videoplayback?...&sq=104&sig=DECRYPTED_SIG&n=DECRYPTED_N" }
]
}
We're introducing Sabr to NodeLink; it's not 100% yet, but this would be useful for both HLS and Sabr.
In segmented streams, "segment-by-segment" resolution generates a high volume of requests that could be reduced. This is especially noticeable in live/premiere HLS: since segments are usually short (e.g., ~1s), maintaining playback requires continuously resolving new URLs, resulting in several repeated calls just to advance playback.
The suggestion is to extend
POST /resolve_urlwith an optional mode to resolve more than one URL per call, returning a small list of the next URLs already resolved and ready for use, with a fixed and low limit (e.g., 5 items). This allows the client to advance several segments at once and reduce the frequency of calls to the service, while the limit prevents this from becoming "resolving a large quantity at once" and reduces the potential for abuse.For SABR, the proposal is the same: instead of resolving a single segment per call, allow resolving a small list of URLs at once. In practice, the client keeps the next segments already prepared in memory and consumes them as needed, without having to call the service for each advancement.
Request example (same endpoint, list mode)
{ "player_url": "https://.../base.js", "signature_key": "sig", "streams": [ { "index": 1, "stream_url": "https://.../videoplayback?...&sq=100&sig=ENCRYPTED&n=ENCRYPTED", "encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE", "n_param": "ENCRYPTED_N_VALUE" }, { "index": 2, "stream_url": "https://.../videoplayback?...&sq=101&sig=ENCRYPTED&n=ENCRYPTED", "encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE", "n_param": "ENCRYPTED_N_VALUE" }, { "index": 3, "stream_url": "https://.../videoplayback?...&sq=102&sig=ENCRYPTED&n=ENCRYPTED", "encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE", "n_param": "ENCRYPTED_N_VALUE" }, { "index": 4, "stream_url": "https://.../videoplayback?...&sq=103&sig=ENCRYPTED&n=ENCRYPTED", "encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE", "n_param": "ENCRYPTED_N_VALUE" }, { "index": 5, "stream_url": "https://.../videoplayback?...&sq=104&sig=ENCRYPTED&n=ENCRYPTED", "encrypted_signature": "ENCRYPTED_SIGNATURE_VALUE", "n_param": "ENCRYPTED_N_VALUE" } ] }Response example
{ "results": [ { "index": 1, "resolved_url": "https://.../videoplayback?...&sq=100&sig=DECRYPTED_SIG&n=DECRYPTED_N" }, { "index": 2, "resolved_url": "https://.../videoplayback?...&sq=101&sig=DECRYPTED_SIG&n=DECRYPTED_N" }, { "index": 3, "resolved_url": "https://.../videoplayback?...&sq=102&sig=DECRYPTED_SIG&n=DECRYPTED_N" }, { "index": 4, "resolved_url": "https://.../videoplayback?...&sq=103&sig=DECRYPTED_SIG&n=DECRYPTED_N" }, { "index": 5, "resolved_url": "https://.../videoplayback?...&sq=104&sig=DECRYPTED_SIG&n=DECRYPTED_N" } ] }