-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Is possible to disable trackSelector performance checks? #11003
Comments
Hello @fgl27. Without logs and based on your description, it seems that the quality is being limited by the bandwidth of your network and device. If your players are downloading at the same time, then your available bandwidth per player is essentially halved.
Yes in theory. There is a DefaultBandwidthMeter attached to your player that is used by the AdaptiveTrackSelection class. It estimates that the player cannot download and play at the higher bitrate successfully so one of the lower bitrate streams is selected.
There are some ways to disable it. One is to limit your trackselector to higher bitrates using Parameters::setMinVideoBitrate. Or override a method like selectTracks to remove the option of a lower bitrate track. You could override AdaptiveTrackSelection::canSelectFormat to return false on those lower bitrate tracks. There are different options. A last suggestion, though quite a bit more complicated, is adding some 'synchronization' logic between the downloaders of your two players so that they don't download at the same time. Hope this helps! |
Hey @microkatz This is related to this issue fgl27/SmartTwitchTV#138 I know about bandwidth or network issues, I already verified this with the user and it isn't a network problem, I say because the way I have set up the player the user can block unwanted resolutions manually if the user does that it plays just fine at highest resolution possible. The device is a Chromecast with google tv, the issue is new for this user only, network speeds are OK 80+Mb, it 1080p60 demands only 15Mb. I already revise all that I can. My thought was that as I recently updated exoplayer from a version of August of last year to January of current year then after the issue, something new was added to analyze the performance and is causing the resolution change. In this case it seems a exoplayer bug, I will update to the latest version of dev2 and share some logs. Is that OK? Do you advise something else now that I explain it better? |
Thank you for the additional information. We did add a performance check change in the release that you picked up. In the logs, if the an AnalyticsListener was added to your player, you should see that the 1080p60 track fails the PerformancePoint coverage check, line 517 in the file of the commit I posted. If you remove the software decoder from possible formats, then the logs printing the available tracks will say "supported=NO_EXCEEDS_CAPABILITIES" for the 1080p60 track. Another user reported a similar issue to yours: #10898 as the Chromecast does not programmatically report support for 60 fps. For a solution you can also manually adjust the selection with |
OK, that explains, I will see what I can do to improve the user experience from the app side. Thanks for the help and explanations. No more doubts for now. |
I'm using trackSelector to play an hls playlist, the trackSelector will choose the highest quality stream if I have a single player playing, once a second one starts (Picture and picture mode) the quality will drop from 1080p60 to 720p30 or even 480p30 to both players.
This seems to be a performance check from exoplayer, but I can't find it.
Is this correct? Do we have a performance check?
Is it possible for me to disable it?
I know that I can remove tracks, but I don’t want to in scenarios of network related lag the player can drop and come back once internet speed is fine, I just wanna remove the performance check.
I'm using dev2 branch head is 128fed8 from last jan 25 https://github.com/google/ExoPlayer/commits/dev-v2?after=9170e6f5118ae56a21cac29bee3b7e909cc5ae6b+174&branch=dev-v2&qualified_name=refs%2Fheads%2Fdev-v2
The text was updated successfully, but these errors were encountered: