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

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

Closed
Stonos opened this issue Feb 9, 2021 · 11 comments
Assignees
Labels

Comments

@Stonos
Copy link

Stonos commented Feb 9, 2021

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
Copy link
Collaborator

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
Copy link

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

@Stonos
Copy link
Author

Stonos commented Feb 9, 2021

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
Copy link
Collaborator

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
Copy link
Author

Stonos commented Feb 9, 2021

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
Copy link
Collaborator

tonihei commented Feb 9, 2021

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
Copy link
Collaborator

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
Copy link
Contributor

ojw28 commented Feb 9, 2021

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
Copy link
Collaborator

tonihei commented Feb 9, 2021

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
Copy link
Contributor

ojw28 commented Feb 12, 2021

This will be fixed in 2.13.1.

@ojw28 ojw28 closed this as completed Feb 12, 2021
@ojw28
Copy link
Contributor

ojw28 commented Feb 12, 2021

The fix is 5e229b4.

@google google locked and limited conversation to collaborators Apr 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants