frame frozen appears when playing short video in loop mode

[duduniao]

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

[AquilesCanta]

@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.

[tonihei]

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?

[akurni]

I think this problem is related to the issue i encountered #3829.

[sunshangfeng]

@tonihei 您好我是中国开发者，我也遇到这个问题 我想请问如何禁用编辑列表的无间隙信息处理并让音轨编辑列表通过标准的方式运行 期待你的回答

[andrewlewis]

@sunshangfeng If you want edit lists to be ignored, pass FLAG_WORKAROUND_IGNORE_EDIT_LISTS to DefaultExtractorsFactory.setMp4ExtractorFlags.

[sunshangfeng]

thank you very much，我尝试一下

[tonihei]

I think the original issue hasn't been addressed yet.

[pbertsch]

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

[tonihei]

We found the reason for the regularly reported AudioTrack discontinuities (see here) and will provide a fix for that.

Note that:

1. This doesn't fix the original issue with the gapless info handling.
2. Also not sure whether it will fix the problem with the freezing frames after more than a day (with the FLAG_WORKAROUND_IGNORE_EDIT_LISTS flag enabled).

[hunanqi]

thank you very much，我尝试一下

亲，我也遇到这种问题了，循环播放1天以上就卡在某一帧，请问这种处理方式有效吗。

[tonihei]

@hunanqi Can you try the dev-v2 branch and check if your problem is fixed?

[hunanqi]

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.

[ojw28]

Are you checking using the latest dev-v2 branch?

[hunanqi]

@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.

[tonihei]

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.

[hunanqi]

@tonihei Is there any good solution to this problem?

[tonihei]

@hunanqi Working on it. We'll post updates here as soon as we have something.

[tonihei]

The issue should be solved now (with and without applying edit lists).

[zwz-coding]

@tonihei I also have the same issue. So, there are two solution for this issue now.

1. Use FLAG_WORKAROUND_IGNORE_EDIT_LISTS for workaround.
2. Use dev-v2 branch.
   Am I correct?

[tonihei]

@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.

[ojw28]

The 2.9.0 release that includes the bug fix is scheduled for this week, so the easier version of option (2) is to wait a couple of days and then update your dependency.

[zwz-coding]

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?

[andrewlewis]

@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.

[hunanqi]

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，

[hunanqi]

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。

[andrewlewis]

@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.

[hunanqi]

@andrewlewis From logcat, there are several times that the following logs appear.
LoadTask: OutOfMemory error loading stream
06-15 05:26:22.500 7182 7207 E LoadTask: java.lang.OutOfMemoryError: Failed to allocate a 65552 byte allocation with 41576 free bytes and 40KB until OOM, max allowed footprint 100663296, growth limit 100663296
06-15 05:26:22.500 7182 7207 E LoadTask: at com.google.android.exoplayer2.upstream.DefaultAllocator.allocate(DefaultAllocator.java:102)
06-15 05:26:22.500 7182 7207 E LoadTask: at

so,
Is it possible? this player.release(); Memory is not released completely.

This problem should be a bug in exoplayer, because it's okay to play several videos in a long loop without calling player. release ()

[andrewlewis]

@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.