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

Did something change with audio track sync from 2.8.2 to 2.8.4? #4774

Closed
ebr11 opened this issue Sep 4, 2018 · 8 comments
Closed

Did something change with audio track sync from 2.8.2 to 2.8.4? #4774

ebr11 opened this issue Sep 4, 2018 · 8 comments
Assignees
Labels

Comments

@ebr11
Copy link

ebr11 commented Sep 4, 2018

We recently upgraded from 2.8.2 to 2.8.4 and now have some content where audio plays out of sync with the video. Move back to 2.8.2 and the sync issue is gone.

I can try to provide a sample if needed but wanted to check if there is some known change that we can adjust to.

Thanks.

@tonihei
Copy link
Collaborator

tonihei commented Sep 5, 2018

We are not aware of any change which causes synchronization problems. Also depends on the type of media you are using to answer that question. Can you provide us with an example? If you don't want to post it publicly, please send it to dev.exoplayer@gmail.com with "Issue #4474" in the subject.

@tonihei tonihei self-assigned this Sep 5, 2018
@ebr11
Copy link
Author

ebr11 commented Sep 5, 2018

Sample emailed.

Thanks.

@tonihei
Copy link
Collaborator

tonihei commented Sep 5, 2018

Thanks for the sample. It seems this commit of 2.8.3 fixed #4348 but broke your sample.

The reason is that in both cases the file contains edit lists which do not start from a keyframe.

  1. In your case, it's the first (and only) edit list. Although we don't properly support this, we can safely ignore the problem. It only means that at the very beginning there is only audio and a frozen video until the time of the first video keyframe is reached. This is barely noticeable in your case.
  2. In the case of Some videos getting distorted... #4348, the second edit list also doesn't start with a keyframe. In that case, we can't just ignore it because the video decoder will mix up all samples and seriously distort the video because there is no valid keyframe at the beginning of the second edit list.

Will push a fix which keeps the edit lists disabled for cases as in #4348, but keeps them if only the first edit list doesn't start with a keyframe.

@ebr11
Copy link
Author

ebr11 commented Sep 5, 2018

Thanks very much.

@ebr11
Copy link
Author

ebr11 commented Sep 10, 2018

Hi. Has this been addressed yet?

@tonihei
Copy link
Collaborator

tonihei commented Sep 10, 2018

Yes, it will be part of the next release.

@ebr11
Copy link
Author

ebr11 commented Sep 10, 2018

Okay, thanks. Just out of curiosity, can you point me to the commit :).

@ojw28
Copy link
Contributor

ojw28 commented Sep 10, 2018

The commit will appear in this thread when it's pushed to GitHub.

ojw28 pushed a commit that referenced this issue Sep 12, 2018
…keyframe.

Ignoring all edit lists if they don't start with a keyframe causes A/V sync
issues when valid edit lists are applied at the beginning.

This change allows such edit lists again but removes all samples before the
first keyframe (these samples would be ignored by the renderer anyway if at
the beginning OR cause visible distortions when appended to an unrelated
keyframe).

Issue:#4774
Issue:#4348

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212244407
@ojw28 ojw28 closed this as completed Sep 12, 2018
@google google locked and limited conversation to collaborators Jan 31, 2019
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

3 participants