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

Blank/Slow Frame Render for videos (Shortform Demo) #1853

Open
prateek54 opened this issue Nov 3, 2024 · 3 comments
Open

Blank/Slow Frame Render for videos (Shortform Demo) #1853

prateek54 opened this issue Nov 3, 2024 · 3 comments
Assignees
Labels

Comments

@prateek54
Copy link

Unfortunately we can't answer all questions. Unclear questions or questions with
insufficient information may not get attention.

Before filing a question:

When filing a question:

Describe your question in detail.
I've been trying to implement functionality similar to the Shortform app, but encountered an issue during video transitions. While my implementation is based on a single player with a "Next" button, I noticed two main issues:

  1. The first video takes extra time to render its initial frame. Additionally, when moving to the next video, intermittent delays appear on some videos (typically the 0th, 3rd, or 4th in the sequence). These delays occur regardless of how I order URLs from MediaItemDatabase. If I go through videos from 0 -> 5 and then back from 5 -> 0, the initial frame delay reappears, especially for the 0th video.
  2. Although I use a single player in my implementation, switching between videos is occasionally slow, causing a visible lag for the initial frame of some videos. In the Shortform demo app, the transition is smoother, though I sometimes notice similar initial frame lags on the first and a few middle videos.

I'm attaching recordings of both the Shortform app issue and my implementation for reference.

Could you help me identify possible causes for the render delays in my implementation, and why it performs slower compared to the demo app? Additionally, I’d appreciate insights into the primary issues faced in the Shortform demo app as well.

Issue in Shortform App Issue Faced in my internal demo app(Similar to shortform )

In case your question refers to a problem you are seeing in your app:

  • Output of running $ adb bugreport in the console

In case your question is related to a piece of media:

  • URI to test content

  • For protected content:

    • DRM scheme and license server URL
    • Authentication HTTP headers

Don't forget to check ExoPlayer's supported formats and devices, if applicable
(https://developer.android.com/guide/topics/media/exoplayer/supported-formats).

If there's something you don't want to post publicly, please submit the issue,
then email the link/bug report to [email protected] using a
subject in the format "Issue #1234", where #1234 is your issue number (we don't
reply to emails).

@prateek54
Copy link
Author

Alongside i have another follow up question in reference to TargetPreloadStatusControl what does different value for status stage means & what value should we ideally set for these ?
STAGE_LOADED_TO_POSITION_MS
STAGE_TRACKS_SELECTED
STAGE_SOURCE_PREPARED

@prateek54 prateek54 changed the title Blank/Slow Frame Render for videos Blank/Slow Frame Render for videos (Shortform Demo) Nov 3, 2024
@tianyif tianyif self-assigned this Nov 4, 2024
@tianyif
Copy link
Contributor

tianyif commented Nov 5, 2024

Hi @prateek54,

Thanks for reporting!

why it performs slower compared to the demo app

In the shortform app, we use a pool of three players by default. This is because that even we have preloaded the media samples separately already, it still takes time to get the renderer ready and decode the some amount of the samples until the first frame displays.

For the followup question about the status:

  • STAGE_SOURCE_PREPARED - When in this status, source preparation is done. For DASH or HLS media source as example, this means that the manifest is loaded.
  • STAGE_TRACK_SELECTED - When in this status, we already have the track information and selected the tracks based on the device capabilities and bandwidth conditions. But for now we haven't loaded the content samples.
  • STAGE_LOADED_TO_POSITION_MS (I think now it has been changed to STAGE_LOADED_FOR_DURATION_MS), and this should come with a value suggesting the duration - When in this status, we already have loaded the samples of the specified duration from the default start position.

These status are progressive according to the above ordering. So basically you can set the status for each media sources based on their distance to the current playing one - the closer it is to the current playing source, then the more "ready" it should be. For the extra value coming with STAGE_LOADED_TO_POSITION_MS, it is up to you, but it has to be no less than the bufferForPlaybackMs you set for ExoPlayer's DefaultLoadControl , otherwise when the source is set to the player, the player will attempt to load more to fulfill the bufferForPlaybackMs before starting playback, which also takes time.

And as for

In the Shortform demo app, the transition is smoother, though I sometimes notice similar initial frame lags on the first and a few middle videos

I haven't got a concrete idea, but there is probably some issue with the coordination within the player pool. Will take a look.

@prateek54
Copy link
Author

Sure @tianyif
Sounds like a sufficient explanation for the status while for the blank video issue do let me if there are any info on that in future

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

No branches or pull requests

2 participants