-
Notifications
You must be signed in to change notification settings - Fork 404
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
Fix initial network type #384
base: main
Are you sure you want to change the base?
Fix initial network type #384
Conversation
…workTypeObserver which is used to calculate initial bitrate estimate.
"http://video.com/baseUrl/a/video/video_0_452000.m4s", | ||
"http://video.com/baseUrl/a/video/video_0_250000.m4s", | ||
"http://video.com/baseUrl/a/video/video_0_700000.m4s", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test errors a chunk download, excludes the respective track, picks another track and downloads the chunk in a loop until a replacement track is not available and then validates the order of the tracks.
As the initial network type was C.NETWORK_TYPE_UNKNOWN, It was picking a track closer to 700 Kbps (1 Mbps x 0.7 BANDWIDTH_FRACTION) and the order was 700 Kbps, 452 Kbps, 250 Kbps and 1.3 Mbps.
After the change, we use the default network type (2G) from robolectric for which exo's default bandwidth estimate is 574 Kbps (820Kbps x 0.7 BANDWIDTH_FRACTION) and so the order changed to 452 Kbps, 250 Kbps, 700 Kbps and 1.3 Mbps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jfyi, Default Locale from robolectric is en_US
.
I encountered this issue in a different way. Related PR: google/ExoPlayer#10729 |
@microkatz Any updates on this? TIA. |
Issue:
NetworkTypeObserver initialises the default network type as
C.NETWORK_TYPE_UNKNOWN
and then registers for connectivity change callback. This works fine if we receive a connectivity change update quickly.But, sometimes this callback takes time and so DefaultBandwidthMeter assumes network type as unknown and initialises the initial bitrateEstimate as 1Mbps (DEFAULT_INITIAL_BITRATE_ESTIMATE). This initial bitrate estimate is used to select the initial track in playback and so it is vital to get the correct initial bitrate estimate based on the network type. Otherwise even when using a high-speed Wifi connection, initial bitrate estimate will be 1Mbps and forces the player to select a representation with initial bitrate as 1 Mbps (1Mbps X BANDWIDTH_FRACTION).
Eg from Pixel2:
Note that there was a 127ms interval between the time when the
NetworkTypeObserver
was queried byDefaultBandwidthMeter
and the time when theNetworkTypeObserver
was able to update itself based on the connectivity change update.Related discussion explains that it was done this way to differentiate between 4G and 5G NSA. But it affects more playbacks as we get network type as unknown even for wifi or ethernet connections.
Solution:
Use
ConnectivityManager#ActiveNetworkInfo
to pick an optimal initial network type and then let connectivity-change-update callbacks to alter the network type.