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

Preserve and expose original track index #770

Closed
IanDBird opened this issue Sep 8, 2015 · 2 comments
Closed

Preserve and expose original track index #770

IanDBird opened this issue Sep 8, 2015 · 2 comments

Comments

@IanDBird
Copy link
Contributor

IanDBird commented Sep 8, 2015

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?

@ojw28
Copy link
Contributor

ojw28 commented Sep 8, 2015

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.

@IanDBird
Copy link
Contributor Author

IanDBird commented Sep 8, 2015

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.

ojw28 added a commit that referenced this issue Sep 28, 2015
@ojw28 ojw28 closed this as completed Sep 28, 2015
@google google locked and limited conversation to collaborators Jun 28, 2017
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

2 participants