-
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
Unexpected runtime error (When Chunks have different playlist urls) #8937
Comments
Note: Looks like a duplicate of #8890. |
@tonihei can you take a look? |
Yes, this is a bug introduced by 8349d78 (in 2.13.0). The method We'll provide a fix soon. |
@tonihei Thanks for the feedback! |
Preload chunks may still need to be discarded. However, we don't currently support discarding spliced-in chunks. Thus, we need to avoid loadng a preload chunk that needs to be spliced-in. Issue: #8937 #minor-release PiperOrigin-RevId: 374851661
We need to avoid reading and skipping into preload chunks as they may need to be discarded. The current code iterates over all chunks, but this can be simplified by just checking the last chunk knowing that the preload chunk must always be the last one. As a result, we avoid calling getFirstSampleIndex on all chunks. This is a bug since the method is not allowed to be called for chunks that have been spliced in. This still leaves the smaller issue of potentially calling this method for spliced-in preload chunks, which will be solved separately. Issue: #8937 #minor-release PiperOrigin-RevId: 375053638
Issue should be fixed by the two commits above. |
Preload chunks may still need to be discarded. However, we don't currently support discarding spliced-in chunks. Thus, we need to avoid loadng a preload chunk that needs to be spliced-in. Issue: #8937 #minor-release PiperOrigin-RevId: 374851661
We need to avoid reading and skipping into preload chunks as they may need to be discarded. The current code iterates over all chunks, but this can be simplified by just checking the last chunk knowing that the preload chunk must always be the last one. As a result, we avoid calling getFirstSampleIndex on all chunks. This is a bug since the method is not allowed to be called for chunks that have been spliced in. This still leaves the smaller issue of potentially calling this method for spliced-in preload chunks, which will be solved separately. Issue: #8937 PiperOrigin-RevId: 375053638
Hi, I have caught an unexpected runtime error when I use HLS and codecNeedsSetOutputSurfaceWorkaround = true. For example, A xiaomi device like MiBox4 returns true, because it was established in the parent class - MediaCodecVideoRenderer.
When I change the configuration of a mobile phone or hide an app - ExoPlayer passes a nullable Surface to clear/release codec inside MediaCodecVideoRenderer. The error happens when chunks have differents playlists, for instance, I dived to the source code and found out that ExoPlayer has this kind of a code’s snippet like:
HlsMediaChunk.java 139 line - Where ExoPlayer checks playlist between the last and current chunk:
playlistUrl.equals(previousChunk.playlistUrl) // so, They are not equal.
then, 144 line:
as, isFollowingChunk is false and the right block too, I have shouldSpliceIn true
and the end of all, when ExoPlayer checkes state with Assertions.class in 319 line it converts true expression to false and checks state. For example:
How to replay the issue:
In conclusion, the error happens, when the method codecNeedsSetOutputSurfaceWorkaround returns true and the render has chunks with different playlist urls inside. I consider that it's normal behaviour to have different urls in a queue. Full error stack:
The text was updated successfully, but these errors were encountered: