Exoplayer: Support Renderers that don't consume tracks

[pakerfeldt]

Previously with ExoPlayer 1 we were using two custom Renderers. One for showing debug information overlaid on top of the surface and another one to periodically report back to a listener when 15s of media was played. Both of them, well at least the latter, not really a Renderer per se but it felt pretty clean, we didn't need to periodically poll the position and we didn't need to manage any additional threads.

With ExoPlayer 2 we run into some difficulties trying to maintain this approach. There are no Formats in the MediaPeriod associated with these Renderers so they are not returned by DefaultTrackSelector. I suppose we could implement our own DefaultTrackSelector and return these two Renderers when needed but this leads me to the question whether or not this is a bad approach? Sure, we could go the same approach as DebugTextViewHelper for our first use case even though I prefer to view it as a Renderer and handle it accordingly. But what about the other use case of reporting back whenever (roughly) 15s of media has been played. What would be your recommended way of dealing with that?

Thoughts and comments much appreciated.

[ojw28]

We've been meaning to add support back into V2 for this for a while. Marking as an enhancement.

[pakerfeldt]

I take it as the approach is not all that crazy. Is there any reason to believe a custom DefaultTrackSelector wouldn't work in the meantime?

[ojw28]

I don't really understand what your approach is. What does it mean for a track selector to return a renderer? A track selector returns track selections, and (I think?) the problem in this case is that there aren't any tracks to actually select for the renderers to consume.

I don't think it would work to invent some dummy tracks in the selector. You'd probably need to have your MediaSource actually expose some dummy tracks (in which case you may as well give them a format). The proposed enhancement would be to allow a TrackSelector to specify that a renderer should be enabled whilst not providing any corresponding selection for it to consume.

[pakerfeldt]

Sorry, maybe I was not thinking straight. The idea was to create a sort of dummy TrackSelection for these renderers but perhaps that's not possible. All these concepts are still new to me.

[ojw28]

You would probably need to create dummy tracks in the MediaSource, and then have the TrackSelector select them. The TrackSelector can't invent dummy tracks directly. The approach is certainly possible, but it's pretty convoluted. We should add proper support for this.

[pakerfeldt]

So, we tried to go this route and indeed we need to do some hacks to get it right. One thing we ran into was that DefaultLoadControl is not handling Renderers of custom type, i.e. who's track type is based on C.TRACK_TYPE_CUSTOM_BASE. We end up in an IllegalStateException in Util.getDefaultBufferSize() and would have to implement our own LoadControl to get around this. Would you say there's an easier way around that particular issue until there's proper support in ExoPlayer 2?

[ojw28]

If that's the only issue, can you just have your renderer say that it's type TRACK_TYPE_METADATA (you must be using a custom type of some kind to be triggering that IllegalStateException)?

[ojw28]

We've added support for this in dev-v2 (extend NoSampleRenderer). Please give it a try and let us know if this is sufficient for your needs. Thanks!