Live stream that worked with 2.12 does not work with 2.13.0 when tunneling is enabled

[Stonos]

I'm in the process of updating from ExoPlayer v2.12.3 to v2.13.0, and during testing I discovered that a particular DASH live stream does not work when tunneling is enabled (it works fine with v2.12). More specifically, the stream starts playing, but after a few seconds the following exception is thrown:

com.google.android.exoplayer2.demo E/ExoPlayerImplInternal: Playback error
      com.google.android.exoplayer2.ExoPlaybackException: Unexpected runtime error
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:586)
        at android.os.Handler.dispatchMessage(Handler.java:103)
        at android.os.Looper.loop(Looper.java:214)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: java.lang.IllegalStateException
        at com.google.android.exoplayer2.util.Assertions.checkState(Assertions.java:86)
        at com.google.android.exoplayer2.audio.DefaultAudioSink.writeBuffer(DefaultAudioSink.java:912)
        at com.google.android.exoplayer2.audio.DefaultAudioSink.processBuffers(DefaultAudioSink.java:852)
        at com.google.android.exoplayer2.audio.DefaultAudioSink.drainToEndOfStream(DefaultAudioSink.java:1012)
        at com.google.android.exoplayer2.audio.DefaultAudioSink.handleBuffer(DefaultAudioSink.java:754)
        at com.google.android.exoplayer2.audio.MediaCodecAudioRenderer.processOutputBuffer(MediaCodecAudioRenderer.java:630)
        at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.drainOutputBuffer(MediaCodecRenderer.java:1854)
        at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:824)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:947)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:477)
        at android.os.Handler.dispatchMessage(Handler.java:103) 
        at android.os.Looper.loop(Looper.java:214) 
        at android.os.HandlerThread.run(HandlerThread.java:67) 

When tunneling is disabled, the stream works.

I have sent a bugreport to dev.exoplayer@gmail.com

[andrewlewis]

I think this is possibly (non-obviously) related to #8560. That apparently affects HLS streams that don't have program date time information and treats them as low latency live streams, at which point playback speed adjustment will be used, and speed adjustment is incompatible with tunneling causing the failure.

[janeriksamsonsen]

We also see this problem with Dash live-stream and tunneling enabled.

[Stonos]

I think you're right. Calling setLiveMaxPlaybackSpeed(1f) solves the issue, but you obviously lose the new low-latency improvements.

speed adjustment is incompatible with tunneling causing the failure

Does this mean that we should disable speed adjust (as per above) when tunneling is enabled?

[andrewlewis]

I need to look at this in a bit more detail as it's not clear why speed adjustment isn't just becoming a no-op when tunneling is enabled (which is the expected behavior).

[Stonos]

I see, thanks!.

I have one more question: Is the automatic speed adjustment supposed to be enabled for all live streams or just for those that support low latency?

[tonihei]

It supposed to be enabled for live streams that define a target live offset in the media. This should be the case for most DASH and HLS live streams as they define the target offset either directly or in the spec.

[andrewlewis]

This actually isn't related to #8560, but it's just that apps are more likely to hit the bug (that setting playback parameters with tunneling doesn't work) now that playback speed adjustment is used 'automatically' for some streams.

#4803 tracks adding support for using video tunneling and speed adjustment together. Part of this involves calculating timestamps for audio buffers after the SonicAudioProcessor, which are needed to write the A/V sync header on buffers written to the audio track in tunneling mode. We probably also need to tweak the video input buffer timestamps so the TV sees a high frame rate stream (so this implies we need to use the duration of PCM audio output by Sonic to calculate the audio timestamps). This approach ensures that any frame rate conversion done by the TV won't behave strangely due to the higher than expected rate of frames.

Until we can prioritize looking into that bug, I'll make a fix to ignore the playback parameters when using video tunneling.

[ojw28]

That sounds like the right fix for now!

@tonihei - For live streaming, I'm assuming that the initial live offset is at least "sensible" in the case where playback speed adjustment needs to be disabled. A slightly more nuanced question is whether we'd calculate it differently at all if it's known that playback speed adjustment will be disabled. For example, if there's anything in the live streaming implementation that deliberately starts a bit behind the target offset and then movies closer over time, would we turn that off if we knew playback speed adjustment is unavailable? I'm fairly sure that this is either not a concern at all, or a very minor point that probably doesn't need looking at any time in the near future. Just thought I'd check for completeness!

[tonihei]

Playback tries to start exactly at the target live offset(which is used as the "default position" in the media model), so this should be fairly sensible already. As we need to load media before actual playback can start, the practical live offset with tunnelling enabled (and speed adjustment disabled) will be slightly larger than intended for this reason.

[ojw28]

This will be fixed in 2.13.1.