-
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
Preserve and expose original track index #770
Comments
How would you propose representing format indices for DASH / HLS, where there can in theory be two dimensions of index (i.e. index in the manifest + index in the selected stream)? I've also seen live HLS streams where the ordering of streams swaps around during playback, which is awkward. There are also adaptive tracks to think about, which don't exist in the original media. |
If i'm honest, I didn't consider the HLS and DASH scenario. Selfishly, we only ever have a single variant / format when streaming via those and therefore a "stream selection" is a notification back to the server to start an entirely new stream. The particular scenario I was attempting to handle was an extractor based renderer. However, I guess it's possible that someone is streaming via HLS / DASH an audio (or subtitle) stream which is not natively supported by ExoPlayer and therefore silently removed. I would "try" and argue that if someone is using HLS/DASH to stream unsupported streams to the client, they are holding it wrong. Those protocols are specifically to help stream video efficiently and therefore to include unusable streams is just a waste. The case when you need to play back a static file, is when you really don't have any control of the source media. |
I've been testing the latest stream selection changes available on the dev (thanks for the feature!). One problem that I'm having though is that ExoPlayer will parse the video file and build tracks for only supported mime types. The original index of the track within the container is lost.
The problem we have in our application is that we allow the user to select from any available track from the source media. If the track isn't supported by ExoPlayer natively, we kick off a transcode and convert that track to something else (via HLS). This means that the track selection we present to the user is from the original video. When the user performs a selection, we have to translate the selected index from the original video to the player's representation. In order to do this, we have to have a map of what audio stream types are supported for the different extractors. This is very fragile as if/when we update ExoPlayer, it would break this translation whenever a new audio format is supported.
Would it be possible at all to expose the original track index? This means that translation is super simple between source media to player representation, and is not affected by the player's capabilities changing?
The text was updated successfully, but these errors were encountered: