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

Fix initial network type #384

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

balachandarlinks
Copy link
Contributor

@balachandarlinks balachandarlinks commented May 9, 2023

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:

15:33:36.221 12556-12556 DefaultBandwidthMeter          D  InitialBitrateEstimate: 1000000
15:33:36.348 12556-12556 NetworkTypeObserver            D  Network type changed from 0 to 2

Note that there was a 127ms interval between the time when the NetworkTypeObserver was queried by DefaultBandwidthMeter and the time when the NetworkTypeObserver 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.

"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",

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.

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.

@microkatz microkatz self-assigned this May 10, 2023
@vishnuchilakala
Copy link
Contributor

I encountered this issue in a different way. Related PR: google/ExoPlayer#10729

@balachandarlinks
Copy link
Contributor Author

@microkatz Any updates on this? TIA.

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

Successfully merging this pull request may close these issues.

4 participants