diff options
| author | Leena Winterrowd <lenhardw@codeaurora.org> | 2014-12-04 14:03:03 -0800 |
|---|---|---|
| committer | Lajos Molnar <lajos@google.com> | 2015-01-28 21:52:09 -0800 |
| commit | a93fd2be99d21629bed504b9b7df035fc2f54562 (patch) | |
| tree | bacc1924137d3e0e749a1ba47756f3c80eaa1718 /services | |
| parent | 9aff25fb41f516ac26f9d1983a25402909f1e77a (diff) | |
| download | frameworks_av-a93fd2be99d21629bed504b9b7df035fc2f54562.zip frameworks_av-a93fd2be99d21629bed504b9b7df035fc2f54562.tar.gz frameworks_av-a93fd2be99d21629bed504b9b7df035fc2f54562.tar.bz2 | |
stagefright: httplive: Decouple block size from bandwidth estimate
A very small block size in PlaylistFetcher can lead to framework
overhead and difficulty streaming high bitrate content, but since
HTTPBase keeps a constant history of the past 100 HTTP reads, the
block size directly affects bandwidth estimation and in turn,
switching latency.
Add setBandwidthHistorySize() to HTTPBase to allow setting the
history size for bandwidth estimation. Call this within LiveSession
based on the current block size to ensure that the number of bytes
used for estimating bandwidth does not change if the block size is
changed in PlaylistFetcher.
Since a single TCP/IP packet can contain up to 64k of data, increase
the block size in PlaylistFetcher from 2k to lcm(188, 1024) or 47k to
avoid inaccuracies in read timings due to up to a comparable 47 reads
from the same locally-cached packet instead of from the network.
Also make HTTPBase::addBandwidthMeasurement() virtual to allow
bandwidth estimation extensions that do not rely on a history list.
Bug: 18821145
Change-Id: I5f957be01f5346e74cfb7eeb150ca4b397ad5798
Diffstat (limited to 'services')
0 files changed, 0 insertions, 0 deletions