Content-Length: 285721 | pFad | https://github.com/google/ExoPlayer/issues/7943

DC The video blocked when audio stop(The duration of audio track is less than video)? · Issue #7943 · google/ExoPlayer · GitHub
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.

Sign up for GitHub

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

Jump to bottom

The video blocked when audio stop(The duration of audio track is less than video)? #7943

Closed
friskyliu opened this issue Sep 18, 2020 · 6 comments
Closed

The video blocked when audio stop(The duration of audio track is less than video)? #7943

friskyliu opened this issue Sep 18, 2020 · 6 comments
Assignees
@tonihei
Labels
bug

Comments

@friskyliu
Copy link

I played a video(mp4 format), the audio track duration is 6 seconds and the video duration is 40 seconds. When it is played to 6 seconds, the video will be blocked。
@friskyliu friskyliu changed the title The video blocked when music stop(The duration of audio track is less than video)? The video blocked when audio stop(The duration of audio track is less than video)? Sep 18, 2020
@icbaker icbaker self-assigned this Sep 18, 2020
@icbaker
Copy link
Collaborator

icbaker commented Sep 18, 2020

Please provide complete information as requested in the issue template. The issue template can be found here. If you're unable to share bug reports or test content publicly, please send them to dev.exoplayer@gmail.com using a subject "Issue #7943". Please also update this issue to indicate you’ve done this.

To debug this we certainly need:

  • Sample media that demonstrates the problem
  • The version of ExoPlayer and Android used

@friskyliu
Copy link
Author

[ https://github.com/friskyliu/exoplayerbug7943.git ] is the demo for Issue #7943

Exoplayer version：2.12.0
Android version: Android 9.0

@icbaker
Copy link
Collaborator

icbaker commented Sep 18, 2020

Thanks for the app link - I can repro the behaviour you describe when running your app.

However when playing the same media in the demo app at 2.12.0 it plays to the end of the video (i.e. I don't see the behaviour you describe).

So it looks like it's something about the way your app is integrating ExoPlayer. I had a scan through the code and spotted these possible culprits:

  • player.setRepeatMode(Player.REPEAT_MODE_ONE): Changed the demo app to do this - didn't cause problems.
  • player.setSeekParameters(SeekParameters.EXACT): Changed the demo app to do this - didn't cause problems.

Passing this over to @andrewlewis to take a look.

@icbaker icbaker assigned andrewlewis and unassigned icbaker Sep 18, 2020
@friskyliu
Copy link
Author

It seems the code setLoadControl caused the problem. After delete LoadControl, it plays to the end.

Is the params wrong when using LoadControl?

        this.exoPlayer = new SimpleExoPlayer.Builder(context)
            .setTrackSelector(trackSelector)
    //        .setLoadControl(loadControl)   
            .setClock(Clock.DEFAULT)
            .build();

@icbaker
Copy link
Collaborator

icbaker commented Sep 21, 2020

Ah good find. I tried swapping in some different values for MAX_BUFFER_MS in your app. I found:

  • 50_000 allowed the video to play to completion reliably
  • 15_000 allowed it to play a few times, but it would eventually get stuck

I was able to repro in the demo app by including your LoadControl and the repeat mode (it didn't repro without the repeat mode):

player =
    new SimpleExoPlayer.Builder(/* context= */ this, renderersFactory)
        .setMediaSourceFactory(mediaSourceFactory)
        .setTrackSelector(trackSelector)
        .setLoadControl(
            new DefaultLoadControl.Builder()
                .setBufferDurationsMs(
                    /* minBufferMs= */ 5_000,
                    /* maxBufferMs= */ 10_000,
                    /* bufferForPlaybackMs= */ 1500,
                    /* bufferForPlaybackAfterRebufferMs= */ 3500)
                .build())
        .build();
player.setRepeatMode(Player.REPEAT_MODE_ONE);

cc @tonihei who might also have some thoughts

@andrewlewis andrewlewis assigned tonihei and unassigned andrewlewis Sep 21, 2020
@tonihei
Copy link
Collaborator

tonihei commented Sep 21, 2020

Thanks for all the reproduction details - it looks as if this is a bug that got introduced as part of 652c2f9. We'll provide a fix for that.

kim-vde pushed a commit that referenced this issue Sep 25, 2020
@tonihei @kim-vde
Don't require the existence of the next period to wait for its stream.
25e3174 
We have a workaround for uneven sample stream durarions in playlists that
assumes a renderer allows playback if it's reading ahead or waiting for
the next stream.

652c2f9 changed this logic to no longer require to
wait until the next stream is prepared due to a change in how we advance
media periods in the queue. However, the code falsely still requires the
next stream to exist (even if it's not prepared). This can cause a stuck
buffering state when the difference in the duration of the streams is more
than what we buffer ahead because we never create the next stream in such
a case.

Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic
and also doesn't require the next stream to be present.

Also fix a test that seemed to rely on this stuck buffering case to test
stuck buffering detection. Changed the test to not read the end of stream
to ensure it runs into the desired stuck buffering case.

Issue:#7943
PiperOrigin-RevId: 333050285
@ojw28 ojw28 closed this as completed Sep 25, 2020
ojw28 pushed a commit that referenced this issue Oct 21, 2020
@tonihei @ojw28
Don't require the existence of the next period to wait for its stream.
9394847 
We have a workaround for uneven sample stream durarions in playlists that
assumes a renderer allows playback if it's reading ahead or waiting for
the next stream.

652c2f9 changed this logic to no longer require to
wait until the next stream is prepared due to a change in how we advance
media periods in the queue. However, the code falsely still requires the
next stream to exist (even if it's not prepared). This can cause a stuck
buffering state when the difference in the duration of the streams is more
than what we buffer ahead because we never create the next stream in such
a case.

Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic
and also doesn't require the next stream to be present.

Also fix a test that seemed to rely on this stuck buffering case to test
stuck buffering detection. Changed the test to not read the end of stream
to ensure it runs into the desired stuck buffering case.

Issue:#7943
PiperOrigin-RevId: 333050285
@google google locked and limited conversation to collaborators Nov 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@tonihei tonihei

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@andrewlewis @icbaker @ojw28 @friskyliu @google-oss-bot @tonihei








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://github.com/google/ExoPlayer/issues/7943

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy