bbert
commented
1 year ago Hi @Sergears and all,
I think you can achieve all you need using current available API, by using the RequestModifier and by getting metrics from the player (player.getDashMetrics().getCurrentHttpRequest() or player.getDashMetrics().getHttpRequests()) or by listening new metrics being generated (player.on('metricAdded')).
However, I think this is the opportunity to define like a common "standardized" API to enable any applications to:
- catch the requests in order to:
- modify the url
- add/remove headers
- ...
- catch the responses (before being processed by the player) in order to:
- get request metrics (length, ttfb, duration etc)
- modify/patch the received data
- ...
We could define an API as following, for requests event:
player.onRequestSend(e: RequestSendEvent)
type RequestSendEvent = {
// HTTP request related properties
url: string,
method: string,
range?: string,
headers?: { [key: string]: string },
credentials?: boolean,
timeout?: number,
// Media request related properties that could be useful
requestType: RequestType, // "manifest", "initializationSegment", "mediaSegment" etc
mediaType?: MediaType, // "video", "audio" etc
bitrate?: number,
segmentDuration?: number
...
}and for responses event:
player.onRequestReceived(e: ResponseReceivedEvent)
type ResponseReceivedEvent = {
// HTTP request related properties
url: string,
redirectedUrl?: string,
responseCode: number,
method: string,
range?: string,
headers?: { [key: string]: string },
credentials?: boolean,
// Media request related properties
requestType: RequestType,
mediaType?: MediaType,
bitrate?: number,
segmentDuration?: number
// Response data
length: number,
data: any,
// HTTP metrics
tcpid?: number,
tSend: number,
tFirstByte: number,
tEnd: number,
traces?: RequestTrace[]
}The properties lists are not exhaustive and can be completed, and the objective would be to design an API that could fit to every player type. But starting with dash.js is a good option to prove the concept.
This same API could also be used for license requests.
Also, to go further, beyond CDN load balancer topic, we can consider any other potential uses case for which one would like to execute the requests instead of the player itself. For this purpose we could extend this API in order to:
- enable the application to indicate to the player to avoid executing the request
- enable the application to signal to the player any progress, error etc and end of request loading end
This would avoid to implement force solutions redefining some parts of each player. For example:
type RequestSendEvent = {
...
// Request processing related properties
cte?: boolean, // support for chunked transfer encoding
catched: boolean, // if set to true by the application, then the player shall not execute the request
onprogress?: (e: ProgressEvent) => void, // callback for the player
onload?: (e: ProgressEvent) => void,
onloadend?: (e: ProgressEvent) => void,
onabort?: (e: ProgressEvent) => void,
ontimeout?: (e: ProgressEvent) => void,
onerror?: (e: ErrorEvent) => void,
}
Sergears
dsilhavy
littlespex
Context For the integration with the open source client-side CDN load balancer, we need to observe and modify HTTP requsts. The key role of the load balancer is to rewrite the URLs of the segment and manifest requests, for which the existing
RequestModifiershould work fine. However, we also need the additional capabilities described below.What is needed 1) For successful segment requests we need to read: - the timestamp when the HTTP request was made - the timestamp when the HTTP response was received - the byte size of the received payload - (optional) the time to first byte to measure latency The currently existing
SegmentResponseModifierdoes not have access to this info as it only receives an internally fabricatedchunkobject. For example, in shaka player, this info is accessible withResponseFilterthat gives access the the wholeresponseobject. 2) For timeouts and errors: - we need to know which URL resulted in the timeout / error This could be possible if there is some kind of event listener foronErrorandonTimeoutthat gives access to the event object containing the URL. Or, alternatively, anonRetrylistener triggered when the player retries the segment request.Alternative solution All of these can be probably be implemented by heavily intervening and extending the low level
XHRloaderandFetchLoaderfunctions, and wrapping the methodshttpRequest.onload,httpRequest.onerror,httpRequest.ontimeoutof the passedhttpRequest. However this is a brute force solution. Instead, we would want to have the official methods to achieve the needed functionality. They would then be potentially useful for other needs beyond the CDN load balancer.P.S. We would eventually also want to integrate with the content steering functionality of dash.js, for which additional APIs may be needed, but this topic deserves a separate issue.