-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Add rawResponse field to BaseChunkSampleSourceEventListener.onLoadCompleted #1414
Comments
Please provide more detail. Are you using DASH, SmoothStreaming or HLS? Is this for live streaming or for on-demand? I don't think the callback to which you refer is invoked for manifest load or refresh for DASH or SmoothStreaming. |
We need this functionality for live HLS playback, but I imagine it'd also make sense for DASH or SS. Is there a different callback that could be used to handle all the cases? |
For DASH and SmoothStreaming custom data can be embedded directly into the media in EMSG boxes, which we'll be adding support for in 2.x. I'm not really sure what the best approach would be. Can you provide an example of what these fields look like and do, how other players provide you with access, and when you expect to receive them? |
The fields are custom tags in the HLS source -- they're proprietary, and give us playback-time metadata about the video as it's playing. For example, on iOS, we use the Resource Loader Delegate to get access to the raw HLS variant data after it's downloaded. We see them as each HLS variant is downloaded and can update our internal state as playback proceeds. |
Question - Is there a reason why you don't burn your metadata into the stream as ID3, which I think would be the normal way to do something like this in the context of HLS. See this, for example. ExoPlayer already supports metadata delivery via ID3. |
We're adding this extra metadata to the stream in real time; adding ID3 tags would require us to rewrite individual fragments at delivery time. This allows us to accomplish the same result with simple text manipulation instead, and also allows us to include fragments that might not originate on our servers. Another solution we'd considered, but which seemed more complicated, was to emulate / co-opt the onMetadata interface to emit events for any unrecognized tags in the master or variant M3U8 files. Would something like that make more sense to you? |
Would you be more amenable to a more targeted approach? What if, instead of adding on to the OnDownloadComplete event, we added a new event called like OnHlsVariantDownload or something like that? Or, we could add a new event that could be dispatched when HLS tags are parsed. Or if you want to go further up the stack, we could introduce something like the AVPlayer's Resource Loader Delegate -- a class that could act as a proxy for data downloads, which we could implement to do whatever we liked with the data as it's being downloaded. |
hi @ojw28. I work with @alanra & @Skrewtape as well. Do you have any thoughts on the pull request? We're going to be using Exo for lots of high profile projects, and it'd be great if we can all stay on the same codebase, to benefit from each other's work. I think this feature will actually enable a number of other HLS manipulators in the market, not just ours. |
I replied to the pull request. No particular objection to providing a way to do this, but not in the way the PR is currently structured. |
I believe your requirements were addressed by the patch you sent; so closing this one. Thanks! |
Our backend can insert several custom fields into the manifest of a video stream, which we need to interpret at playback time. It doesn't make sense to have ExoPlayer read, parse and understand these fields, but it would be nice if we could read them as they're downloaded by the player.
In order to solve this problem, we'd like to add a field called "rawResponse" to the method signature for the onLoadCompleted event callback, which would contains the raw bytes downloaded for that request, and would be populated for any files that have the type set to Chunk.TYPE_MANIFEST; i.e. DASH or HLS manifest files.
Alternately, if you can think of an alternate way to accomplish this same goal, we'd be more than willing to explore that path.
The text was updated successfully, but these errors were encountered: