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

Http request properties #4361

Closed
shri-hari93 opened this issue Jun 9, 2018 · 13 comments
Closed

Http request properties #4361

shri-hari93 opened this issue Jun 9, 2018 · 13 comments
Assignees

Comments

@shri-hari93
Copy link

shri-hari93 commented Jun 9, 2018

Im working on a project to collect the metrics of the exoplayer. For my metrics, I'm looking forward to extract the http request properties(http list in dash.js) when the player request for fragments. Is there any possible way in the current api to get what I am looking for?

@shri-hari93 shri-hari93 changed the title Im working on a project to collect the metrics of the exoplayer. For my metrics, I'm looking forward to extract the http request properties(http list in dash.js) when the player request for fragments. Is there any possible way in the current api to get what I am looking for? Http request properties Jun 9, 2018
@FD-
Copy link

FD- commented Jun 9, 2018

I believe one possibility would be to use the OkHttp extension. When creating the OkHttpClient to be passed to the OkHttpDataSourceFactory constructor, install an Interceptor. From within the Interceptor, you should be able to read the request header fields.

@AquilesCanta
Copy link
Contributor

AquilesCanta commented Jun 9, 2018

All media sources -I guess you are interested in DASH- allow you to inject a DataSourceFactory. You can provide your own DataSource implementation which intercepts all requests. Please let me know if this does not cover your needs. Have a look at the DefaultDashChunkSource.

@AquilesCanta
Copy link
Contributor

Also, maybe @tonihei can provide better advise.

@tonihei
Copy link
Collaborator

tonihei commented Jun 11, 2018

You'll get some request details as a listener callback when you add an AnalyticsListener with SimpleExoPlayer.addAnalyticsListener and check for onLoadStarted, onLoadCompleted, onLoadCanceled and onLoadError. All these callback have a LoadEventInfo class containing the uri, byte range and post body of the request (in DataSpec).

However, I suppose you refer to the HTTP request headers and/or response headers? These are not currently part of the callback, but we can add them to LoadEventInfo as this information may be of general interest. Marking as an enhancement to track this.

@tonihei tonihei reopened this Jun 11, 2018
@tonihei tonihei assigned tonihei and unassigned AquilesCanta Jun 11, 2018
@shri-hari93
Copy link
Author

Thanks for your help. I will explore this and really looking forward for the enhancement. To clarify @tonihei doubt of what I'm looking for: http://cdn.dashjs.org/latest/jsdoc/streaming_vo_metrics_HTTPRequest.js.html
The metrics similar to the members of the class listed in above link

@tonihei
Copy link
Collaborator

tonihei commented Jun 11, 2018

Thanks. I think we already have all of the information in this class available and just need to add the response headers.

ojw28 pushed a commit that referenced this issue Jun 22, 2018
Both values are helpful for event reporting, but are only available while
the data source is open. Similar to bytesLoaded, they need to be reported
through the Chunk.

Issue:#2054
Issue:#4361

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=201664907
@shri-hari93
Copy link
Author

shri-hari93 commented Jul 15, 2018

@tonihei , as you said the members of the following class http://cdn.dashjs.org/latest/jsdoc/streaming_vo_metrics_HTTPRequest.js.html are already available in exoplayer library. Is it possible to extract these information in one of the event listener methods onLoadCompleted, onLoadStarted etc.

I checked the dataspec object returned from loadEventInfo, it doesn't really return the information tht I'm looking for.(trace, trequest, tresponse, tfinish). However I managed to find media duration, bytes loaded and source uri 👍

Could you suggest a way to get the following information:
Trace: Throughput traces, for successful requests
trequest: Time at which request is sent
tresponse: The real time at which the first byte of the response was received
tfinish: The real time at which the request finished

@tonihei
Copy link
Collaborator

tonihei commented Jul 16, 2018

"Time at which request is sent" - that corresponds to the elapsedRealtimeMs parameter in the LoadEventInfo of onLoadStarted.
"The real time at which the request finished" - same value in the onLoadCompleted callback.
"The real time at which the first byte of the response was received" - For more detailed information on that, you need to add a TransferListener to the DataSource which has a onBytesTransferred method which is called whenever new bytes are received.
"Throughput traces, for successful requests" - If you use a TransferListener as above, you'll get these traces as well (by listening to onBytesTransferred).

@shri-hari93
Copy link
Author

Thanks @tonihei for your suggestion. Seems like I have my solution here.

However, I have small clarification on Transfer listener. I'm already using DefaultBandwidthMeter implemented with bandwidthMeter.EventListener in DataSource. Is it possible to implement Transfer listener along with it? I tried this but it didn't seem to work.

Moreover I could not override the DefaultBandwidthMeter since it is final class and it implements TransferListener.

@tonihei
Copy link
Collaborator

tonihei commented Jul 16, 2018

Good point. It's currently not possible to have multiple transfer listeners. However, we already changed the code to allow multiple transfer listeners per data source in the future. Will be in one of the next releases.

@shri-hari93
Copy link
Author

@tonihei Thanks for the clarification. 👍

Regarding your suggested solution, I could able to get the information that I needed but the issue that I'm facing right now is that, I have to collect these metrics periodically when the load is completed and send it to metric server, since I'm listening to multiple event methods (onLoadingStarted, onLoadingCompleted and onBytestransferred) the veracity of the data is lost as these methods are called immediately which does seem like it doesn't happen in sequential manner.

My approach was, I created a class for HTTPList with the attributes as the details that I'm looking for and I write the data to object of this class during the execution of these event methods.

Is there a better way of implementation to overcome this issue. I'm sure having a class like this http://cdn.dashjs.org/latest/jsdoc/streaming_vo_metrics_HTTPRequest.js.html in library would be of great help in future. But for now, any suggestion from your perspective would be helpful.

Moreover, the media duration for the bytes that is transferred, is it possible to get it as well?

@tonihei
Copy link
Collaborator

tonihei commented Jul 19, 2018

I don't understand where the problem is with getting the callbacks immediately? Note that the TransferListener callbacks are called on the loading thread and AnalyticsListener callbacks on the main thread. Maybe that's the reason why you think there not called in sequential manner.

The media duration is often only known after the load finished. Please listen to updates in onTimelineChanged to check whether the duration is available.

ojw28 pushed a commit that referenced this issue Aug 24, 2018
The response headers of the last load are available from the loading source
when creating media source events and can be easily forwarded.

Issue:#4361
Issue:#4615

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209900693
@tonihei
Copy link
Collaborator

tonihei commented Sep 10, 2018

Closing the issue. The response headers are now part of the LoadEventInfo data.

@tonihei tonihei closed this as completed Sep 10, 2018
@google google locked and limited conversation to collaborators Jan 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants