-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Comments
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. |
We also see this problem with Dash live-stream and tunneling enabled. |
I think you're right. Calling
Does this mean that we should disable speed adjust (as per above) when tunneling is enabled? |
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). |
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? |
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. |
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 Until we can prioritize looking into that bug, I'll make a fix to ignore the playback parameters when using video tunneling. |
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! |
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. |
This will be fixed in 2.13.1. |
The fix is 5e229b4. |
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:
When tunneling is disabled, the stream works.
I have sent a bugreport to dev.exoplayer@gmail.com
The text was updated successfully, but these errors were encountered: