Stream/App freeze in DASH Multi-Period Live-Stream #1698
Comments
|
Thanks for sharing the details of the problem. It's unfortunately not quite clear what could cause this problem or how d292f809 can trigger such a behavior. Do you have an actual stream link you could send to android-media-github@google.com for testing? I tested with other multi-period DASH live streams and none of them show any problem similar to yours, so I suspect the problem may only be triggered by a specific property of the stream itself, or is device-specific (I only tested on Pixel 7). Please report back here once you've sent something, thanks! |
|
Just to let you know i'm facing the same issue with this message |
|
@tonihei happy to see that you react on it. FYI we will remove this from our version. it's clearly visible on our playback and if you check the video dev chat we are not the only one. I understand the inconstancy point but the reality is that now we can't use any official release for any SSAI stream. https://video-dev.slack.com/archives/CJJ0ELF1U/p1725290886523239 |
|
We are also affected by this problem. Cannot update to recent versions of Exo. |
|
We are facing the same issue unfortunately. We would really appreciate if this problem could be resolved! |
|
Same issue here. Please fix it. |
|
Hi ExoPlayer team, Happy to support in the investigation of this issue but look like it's quite impacting a lot of person. Thanks a lot |
|
I tested with the stream provided in the second comment (https://d24rwxnt7vw9qb.cloudfront.net/v1/dash/e6d234965645b411ad572802b6c9d5a10799c9c1/All_Reference_Streams/6ba06d17f65b4e1cbd1238eaa05c02c1/index.mpd), on release 1.4.1 and can't observe any freezing visually and also logging the update intervals that may be affected by d292f809 do not show any unusual gaps.
If you can reproduce, it may also be helpful to see the output of an attached |
|
Hi @tonihei Let me give you more information
I will try to extract event logger too. do you want it on the main ? |
|
Okay, I think I've found something odd, but its root cause is a slightly unfortunate update of the DASH stream. Whenever this test stream switches from the last ad (the silent AWS elemental splash screen) back to the content, the duration of the DASH period and the actual media don't add up. The ad period has segment with 6 seconds of media, but the content period starts about 4.5 seconds after the start of the ad period already. The DASH spec allows this type of mismatch and expects the player to trim the actual media to the declared duration of 4.5 seconds. What I'm unsure about is whether the type of update is allowed by DASH (an update that shortens a period duration from 6 seconds to 4.5 seconds). ExoPlayer handles the duration mismatch correctly if it knows about it. You can see a much smoother transition when you seek back in the stream to the same point later. However, when playing close to the live edge, the following happens:
@Iragne: Is that what you are observing too and does that match the problem you saw with your own streams? (=a mismatch of media segment duration and period duration close to the live edge). |
|
Look the same use case. To be honest I don't know why this commit cause the issue but we had no issue reverting it ... strange and agree with you |
|
Let me check on my side too |
|
Hi @tonihei, thanks for investigating this issue and sorry for the late reply. To answer your questions:
Only at some period transitions. I'd say every 3rd to 4th ad.
In our case it's reproducible on all devices we tested. I've ran the test on my Pixel 7 Pro and it has the same issues as the TV-Sticks.
Only on streams that are using SSAI. However we are not using any ads SDK. Apart from that: I've tried again after reverting 38b9a5d, unfortunately the issue is still reproducible. Regarding d292f80: We've tried back and forth with and without this commit and only after reverting it the issue disappeared. With that being said: I share the confusion with you why this change should be the reason. Our Stream is ~20 seconds behind the Live Edge. I'll try to figure out if I can observe a mismatch of media segment duration and period duration in our stream as well. |
When transitioning to the next media position parameter checkpoint we estimate the position because the audio processor chain no longer provides access to the actual playout duration. The estimate using the declared speed and the last checkpoint may have drifted over time, so we currently estimate relative to the next checkpoint, which is closer and presumably provides a better estimate. However, this assumes that these checkpoint are perfectly aligned without any position jumps. The current approach has two issues: - The next checkpoint may include a position jump by design, e.g. if it was set for a new item in the playlist and the duration of the current item wasn't perfectly accurate. - The sudden switch between two estimation methods may cause a jump in the output position, which is visible when we add new media position checkpoints to the queue, not when we actually reach the playback position of the checkpoint. We can fix both issues by taking a slightly different approach: - Continuously monitor the estimate using the current checkpoint. If it starts drifting, we can adjust it directly. This way the estimate is always aligned with the actual position. - The change above means we can safely switch to using the estimate based on the previous checkpoint. This way we don't have to make assumptions about the next checkpoint and any position jumps will only happen when we actually reach this checkpoint (which is more what a user expects to see, e.g. at a playlist item transition). Issue: #1698 PiperOrigin-RevId: 690979859
|
@mikef-dk: Did you figure out if your stream issues also occur at places if a duration mismatch between the period and the sum of all its segments? If not, would you be able to share a test stream with us that would let us see and reproduce the issue in the demo app? @Iragne: Did you get around to see if reverting 38b9a5d or including the fix in 7c0cffd helps to alleviate the issue you were seeing? |
When transitioning to the next media position parameter checkpoint we estimate the position because the audio processor chain no longer provides access to the actual playout duration. The estimate using the declared speed and the last checkpoint may have drifted over time, so we currently estimate relative to the next checkpoint, which is closer and presumably provides a better estimate. However, this assumes that these checkpoint are perfectly aligned without any position jumps. The current approach has two issues: - The next checkpoint may include a position jump by design, e.g. if it was set for a new item in the playlist and the duration of the current item wasn't perfectly accurate. - The sudden switch between two estimation methods may cause a jump in the output position, which is visible when we add new media position checkpoints to the queue, not when we actually reach the playback position of the checkpoint. We can fix both issues by taking a slightly different approach: - Continuously monitor the estimate using the current checkpoint. If it starts drifting, we can adjust it directly. This way the estimate is always aligned with the actual position. - The change above means we can safely switch to using the estimate based on the previous checkpoint. This way we don't have to make assumptions about the next checkpoint and any position jumps will only happen when we actually reach this checkpoint (which is more what a user expects to see, e.g. at a playlist item transition). Issue: #1698 PiperOrigin-RevId: 690979859 (cherry picked from commit 7c0cffd)
|
Sorry i was on a lot of other issue. i will test it again tomorrow |
|
@tonihei just to let you know i'm running my tests now. I will let you know shortly |
|
@tonihei So i had been able to extract additional result
So for me and my test i like following fix 7c0cffd |
|
@tonihei Once we reverted the d292f80 in media3 1.4.0, playback starts working. This commit might not be the root cause, but somehow it might exposed some unknown issue during manifest updating. ========= SOME UPDATE =========== ========= SOME MORE UPDATE =========== we should add the condition that: requiredIntervalUs > 0 |
|
@tonihei |
|
@tonihei Sorry for the late reply. I've sent a test stream to #edit followed by the log output that we were observing before as well: |
|
I missed the updated comment of @linhai326 regarding the @tonihei Does this make any sense to you - especially in conjunction with the commit that we blamed initially? (d292f809) |
|
The proposed code change seems to fix the issue on our side, too. Hoping to have a solution included in an official exoplayer release soon! |
|
Me too |
|
Thanks for all the investigation and sorry for the delay in looking in to this. The first part of the issue was solved by 4b6e886, but the second part needs to be solved by an additional check as proposed in #1947. The reason this infinite update loop is happening is that the manifest ends at the end of the ad and ExoPlayer tries refreshing the manifest to find the next period. But the next period is only added once the live window catches up with the end of the ad period. |
|
#1947 is merged as well and will be released with Media3 1.6.0. The only remaining task here is to look into the duration change I explained here: #1698 (comment). We should be able to improve the behavior at the last ad-content transition by actually trimming the samples instead of trying to decode and skip all of them. This part is more of an enhancement though and not a bug fix. |
DASH periods can have a duration that is less than the end of the last chunk in the period. In these cases, the sample data needs to be clipped to the declared period duration. This already happens IF the period duration is known at the point where we start loading the media chunk. However, if the duration becomes known later or is reduced (e.g. in a live stream), the existing media chunks are not clipped. This causes unclean transitions across periods where the player tries to transition to the next period, but renderers struggle to output all the remaining surplus samples that should have been clipped. This can be fixed by asking ChunkSampleStream to discard surplus samples that were loaded beyond a clipped duration when evaluating the sample queue between chunk loads. Issue: #1698 PiperOrigin-RevId: 713288221
|
The enhancement to handle changing durations is also done now (b321c8d), which results in a much cleaner transition for streams where this happens (like the one shared in #1698 (comment)). I'm closing this issue now as there is no other problem left as far as I'm aware. |
Version
Media3 1.4.1
More version details
Issue reproduced in 1.4.1 and 1.4.0 - 1.3.1 is working fine.
After doing some
git bisectwe were able to pin down the issue to commit d292f809. If we revert this particular commit on version 1.4.1 we cannot reproduce the issue anymore.We observe the following Logcat messages when the issue occurs. In this particular case the "freeze" started at around 13:20:47 and application resumed at around 12:20:53.
I've sent a video of the issue, the
adb bugreportas well as the logs via Mail.Devices that reproduce the issue
Any device. We tested it specifically on AFTMM Fire TV (Android 7) stick and our own Android TV Stick (Android 11)
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Not tested
Reproduction steps
Play a DASH Multi-Period Live Stream
Expected result
Stream plays smoothly without interruption
Actual result
Application freezes (including Audio & Video) for a brief moment
Media
Not applicable
Bug Report
adb bugreportto android-media-github@google.com after filing this issue.The text was updated successfully, but these errors were encountered: