Allow setting playback parameters for a future position (including media item transitions)

[brAzzi64]

Hi,

I'm using ConcatenatingMediaSource to play a sequence of videos, some of which need to be played at a different speed / pitch, while keeping a smooth playback.

The doc for Player#setPlaybackParams() states that "Playback parameters changes may cause the player to buffer.", so an approach that "monitors playback progress" and applies any updated params when necessary would not work well here.

I also noticed digging through setPlaybackParams() that any pending samples are not flushed out of the AudioTrack, so when calling this method during playback, you can still hear samples transformed with previous settings for a few milliseconds.

Is there any mechanism that I could use to let the player know up front that when buffering from timestamp t1, it should start doing so using a different set of playback params?

I'm currently on ExoPlayer 2.8.

Would appreciate any tips on this. Thanks!

[andrewlewis]

There was some related discussion in #3419. There is no built-in support for this at the moment so I've marked this as an enhancement (I'm not sure when we'll get round to it, though, so you may want to implement a workaround from that issue if you need this soon).

[brAzzi64]

Hi @andrewlewis!

It's funny to see that that issue + workaround are actually my own, but from a couple of years back... Totally forgot about it. It was actually a different problem then, was mostly using ConcatenatingMediaSource to build a playlist of audio-only files, while here I'm trying trying to play videos at different speeds, but... should've rung a bell :)

Unfortunately that workaround won't work this time, both because we can't afford a silence gap between segments (since we are dealing with a continuous audio track here) and because it might be hard for us to allow a fork of ExoPlayer to support our feature.

Do you think your suggestion there about a custom MediaCodecAudioRenderer is still something worth exploring? Otherwise, I'll be trying out the on-the-fly changing of speed params, and see how much it'd impact playback; or worst case scenario we'll have to resort to transcoding / pre-processing the video segments that should play at != speed.

--

Sorry for the unrelated note, but I finally got cycles to get back to #6103 and I'm still running into trouble with your suggestion. Is there a way we could re-open that issue, or should I create a new one about the same thing?