-
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
frame frozen appears when playing short video in loop mode #4559
Comments
@tonihei, would you mind looking at this? The issue is only reproducible after a several loops of repeat mode, increasingly noticeable. It's caused by the audio track somehow drifting from the video. If you disable the audio, the issue does not reproduce. If you don't think it's related to repeat mode, just assign back to me. |
It seems the issue is somehow produced by having edit lists in the audio and video track of the file. The audio edit list is handled using gapless metadata and the video edit list is handled by the standard procedure of editing each sample timestamp. It seems this somehow causes the occasional audio underruns after some loop iterations. If I force disable the gapless info handling of edit lists (and let the audio track edit list go through the standard procedure), the underruns disappear. @andrewlewis Can you take a look at this? |
I think this problem is related to the issue i encountered #3829. |
@tonihei 您好我是中国开发者,我也遇到这个问题 我想请问如何禁用编辑列表的无间隙信息处理并让音轨编辑列表通过标准的方式运行 期待你的回答 |
@sunshangfeng If you want edit lists to be ignored, pass |
thank you very much,我尝试一下 |
I think the original issue hasn't been addressed yet. |
I have the same problem with version 2.8.4. As @akurni correctly states, it happens after hours of playing the same playlist in a loop. I figured it had something to do with the AudioTrack so I disabled it for testing purposes. I will try the FLAG_WORKAROUND_IGNORE_EDIT_LISTS and get back to you |
We found the reason for the regularly reported AudioTrack discontinuities (see here) and will provide a fix for that. Note that:
|
When the stream is changed in the audio renderer, the timestamps of the samples can no longer be expected to match the calculations in the AudioSink. This change tracks the samples at which the stream is changed and notifies the AudioSink of the discontinuity. Issue:#4559 Issue:#3829 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=212435859
亲,我也遇到这种问题了,循环播放1天以上就卡在某一帧,请问这种处理方式有效吗。 |
@hunanqi Can you try the dev-v2 branch and check if your problem is fixed? |
Hello, I'm testing FLAG_WORKAROUND_IGNORE_EDIT_LISTS to see if it works, and the four machines do the same thing. Bug appears every time. It will take at least one day to verify FLAG_WORKAROUND_IGNORE_EDIT_LISTS. I will tell you if there is any result. |
Are you checking using the latest |
@tonihei After verification, adding FLAG_WORKAROUND_IGNORE_EDIT_LISTS has solved bug。Dev-v2 branch is not used because it is too time-consuming to verify this problem.Thank you for your attention to this problem. |
Reopening - The original issue is still not fixed :) Just to summarize: We set the edit list as gapless information to the audio track instead of removing the samples. The gapless info is, however, only applied once in the renderer for the first iteration. For every subsequent loop iteration, the audio edit list is not applied. As the video edit list is still applied though, audio and video get further out of sync with every iteration. |
@tonihei Is there any good solution to this problem? |
@hunanqi Working on it. We'll post updates here as soon as we have something. |
After a period transition the first buffer queued has the sum of previous period durations added to its source presentation timestamp. These durations take into account gapless edits, but the check on the timestamp was based on the submitted frame count, not the frame count after trimming. This change fixes an issue where audio/video would gradually drift apart due to accumulated error in the audio track position, which could lead to freezing due to the audio renderer stopping being ready and switching to the standalone media clock. Issue: #4559 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213819908
After a period transition the first buffer queued has the sum of previous period durations added to its source presentation timestamp. These durations take into account gapless edits, but the check on the timestamp was based on the submitted frame count, not the frame count after trimming. This change fixes an issue where audio/video would gradually drift apart due to accumulated error in the audio track position, which could lead to freezing due to the audio renderer stopping being ready and switching to the standalone media clock. Issue: #4559 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213819908
The issue should be solved now (with and without applying edit lists). |
@tonihei I also have the same issue. So, there are two solution for this issue now.
|
@KevinChiu2Note Yes, that's correct. Option 1 disables the edit lists, and Option 2 includes a bug fix handling this type of edit list correctly. |
The |
Hi men, I saw the 2.9.0 version was released today. But I still have a question, if I want to play the video in a loop by using the 2.9.0 exoplayer, do I need to keep using the flag FLAG_WORKAROUND_IGNORE_EDIT_LISTS? |
@KevinChiu2Note If you stop using the flag you shouldn't see the issue originally reported here, though to get gapless playback working perfectly the edit lists/durations in the container should be consistent and accurate. |
Hi men,I saw the 2.9.0 version was released today.No use the flag FLAG_WORKAROUND_IGNORE_EDIT_LISTS,Circular execution(Initialization player ,Play 10 videos and release-> pause for a while.)A day later,frame frozen appears 。Appear in log,Media server died,Media server started, |
Here is the complete log,https://raw.githubusercontent.com/hunanqi/Retrofit_Two/master/log.log ,The time should be,11-01 01:56:43.521。 |
@hunanqi This looks like a device-specific issue that would need to be fixed by the OEM via a system update. The mediaserver dies due to a segmentation fault in libOMX.WMT.Video.Decoder.so. |
@andrewlewis From logcat, there are several times that the following logs appear. so, This problem should be a bug in exoplayer, because it's okay to play several videos in a long loop without calling player. release () |
@hunanqi This doesn't seem related to the freeze frame issue tracked here, so please file a new issue and include all the information requested in the new issue template. The logging attached above doesn't seem to include an out of memory error, so please include a full bug report on the new issue, and provide steps to reproduce the problem if possible. |
Issue description
use exo-player play a short video in loop mode, after about 20 time, frame frozen occurred.
below is the video:
https://vimeo.com/user87631413/review/281380616/9f0f3586bd
Reproduction steps
play short video in loop mode, use the video i uploaded in ExoPlayer demo can reproduce.
https://vimeo.com/user87631413/review/281379544/f9af9bbd5a
Link to test content
play short video in loop mode
Version of ExoPlayer being used
2.8.0, 2.8.1, 2.8.2 has problems, and only 2.7.3 is ok
Device(s) and version(s) of Android being used
Samsung Galaxy S7 edge, SM-G9350
Android 6.0.1
Using video that I uploaded, after 20 loops, there's a high probability of that happening
A full bug report captured from the device
07-24 10:57:04.176 10914-10932:caller.live.screen.log
The text was updated successfully, but these errors were encountered: