Skip to content
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

Closed
duduniao opened this issue Jul 24, 2018 · 28 comments
Closed

frame frozen appears when playing short video in loop mode #4559

duduniao opened this issue Jul 24, 2018 · 28 comments
Assignees
Labels

Comments

@duduniao
Copy link

duduniao commented Jul 24, 2018

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
Copy link
Contributor

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

@AquilesCanta AquilesCanta assigned tonihei and unassigned AquilesCanta Jul 24, 2018
@tonihei
Copy link
Collaborator

tonihei commented Jul 25, 2018

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?

@tonihei tonihei assigned andrewlewis and unassigned tonihei Jul 25, 2018
@akurni
Copy link

akurni commented Aug 13, 2018

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

@sunshangfeng
Copy link

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

@andrewlewis
Copy link
Collaborator

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

@sunshangfeng
Copy link

thank you very much,我尝试一下

@ojw28 ojw28 closed this as completed Aug 28, 2018
@tonihei
Copy link
Collaborator

tonihei commented Aug 28, 2018

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

@tonihei tonihei reopened this Aug 28, 2018
@pbertsch
Copy link

pbertsch commented Sep 6, 2018

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
Copy link
Collaborator

tonihei commented Sep 7, 2018

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

ojw28 pushed a commit that referenced this issue Sep 12, 2018
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
@hunanqi
Copy link

hunanqi commented Sep 13, 2018

thank you very much,我尝试一下

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

@tonihei
Copy link
Collaborator

tonihei commented Sep 13, 2018

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

@hunanqi
Copy link

hunanqi commented Sep 13, 2018

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
Copy link
Contributor

ojw28 commented Sep 17, 2018

Are you checking using the latest dev-v2 branch?

@hunanqi
Copy link

hunanqi commented Sep 18, 2018

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

@ojw28 ojw28 closed this as completed Sep 18, 2018
@tonihei
Copy link
Collaborator

tonihei commented Sep 18, 2018

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 tonihei reopened this Sep 18, 2018
@hunanqi
Copy link

hunanqi commented Sep 18, 2018

@tonihei Is there any good solution to this problem?

@tonihei
Copy link
Collaborator

tonihei commented Sep 18, 2018

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

ojw28 pushed a commit that referenced this issue Sep 21, 2018
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
ojw28 pushed a commit that referenced this issue Sep 21, 2018
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
@tonihei
Copy link
Collaborator

tonihei commented Sep 24, 2018

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

@zwz-coding
Copy link

@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
Copy link
Collaborator

tonihei commented Sep 26, 2018

@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
Copy link
Contributor

ojw28 commented Sep 26, 2018

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
Copy link

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
Copy link
Collaborator

@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
Copy link

hunanqi commented Nov 1, 2018

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
Copy link

hunanqi commented Nov 1, 2018

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
Copy link
Collaborator

@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
Copy link

hunanqi commented Nov 1, 2018

@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
Copy link
Collaborator

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

10 participants