Video Download Acceleration: 2.5× Optimization for iOS Apps

Video Download Acceleration, 2.5× Optimization

Background

Video caching has become a standard feature of many video App s, and the usage volume is large each month. Improving caching performance is therefore crucial for user experience.

On the Sohu Video iOS client, caching differs from iQiyi: there is no multi‑video simultaneous caching feature, and the cache fragments are downloaded serially. After an m3u8 file is cached, the ts segments are fetched sequentially, resulting in low network utilization.

To enhance user experience and increase cache speed, a speed‑optimization scheme was designed.

Design

Analysis

The core of the caching scheme is to maximize network utilization, not merely increase concurrent download count, which could cause device overheating and resource contention. The number of parallel fragments should be decided dynamically based on network speed and device performance.

Because the network already uses the quic protocol, low‑level improvements are limited; optimization must occur at the upper layer.

Caching Scheme

If a new caching task lacks recent speed data (e.g., after a pause or restart), the concurrency is set based on network type: 2 for cellular, 4 for Wi‑Fi, derived from empirical testing.

Concurrency is adjusted dynamically during each download by re‑measuring speed and updating the parallel count. When the network environment changes, a new speed test restarts the process.

The underlying quic implementation uses the cronet library, which does not expose long‑connections; it manages concurrency via up to six threads per port, capped at sixteen threads overall, so higher‑level logic must control concurrency.

Since most videos are in m3u8 format, the acceleration applies only to m3u8 streams; drm and mp4 formats remain unchanged and would require server‑side slicing for acceleration.

Speed‑Test Scheme

The speed‑test considers four key factors:

Network environment (Wi‑Fi vs. cellular) – Wi‑Fi can fully utilize bandwidth.

Network speed – the primary factor; low speed limits any optimization.

Device performance – high concurrency on low‑end devices may cause stutter or overheating.

Video type – series with many ts segments benefit from higher concurrency.

Concurrency is kept within a reasonable range to avoid request congestion and timeouts, while also ensuring it does not starve other network requests.

Test Data

Test Method

Data were collected from console logs (the feature is not yet released) under multiple network conditions. Movies and TV series were cached simultaneously, comparing the original version with the accelerated version on both Wi‑Fi and cellular networks.

Results show a clear speed boost for movies (large files) under fast networks, and about a 50% improvement for TV series.

Wi‑Fi

Average speed increase: 2.35×.

Cellular

Average speed increase: 1.50×.

Playback Smoothness

Tests confirm that accelerated caching does not affect playback smoothness; video frames remain stable at 60 fps in both Wi‑Fi and cellular environments.

Code Implementation

The core logic is illustrated in the following pseudo‑code, focusing on the speed‑test and dynamic concurrency adjustment.

/// Calculate current concurrent download count; a single value is used for all cache tasks.
/// The core principle is to maximize real bandwidth utilization.
- (void)calculateDownloadSpeedWithTask:(SVDownloadTask *)downloadTask {
    /// Set concurrent download count based on speed (mb/s)
    CGFloat currentSpeed = downloadTask.downloadingSpeed / 1024.f / 1024.f;
    NSInteger maxConcurrentCount = 4.f;
    /// Example thresholds for TV series (ts size ~1‑2 MB)
    if (currentSpeed > 0.f) {
        if (currentSpeed < 0.5f) { maxConcurrentCount = 2; }
        else if (currentSpeed >= 0.5f && currentSpeed <= 1.f) { maxConcurrentCount = 4; }
        else if (currentSpeed >= 1.f && currentSpeed <= 2.f) { maxConcurrentCount = 5; }
        else if (currentSpeed >= 2.f && currentSpeed <= 3.f) { maxConcurrentCount = 6; }
        else if (currentSpeed >= 3.f && currentSpeed <= 4.f) { maxConcurrentCount = 7; }
        else if (currentSpeed >= 4.f && currentSpeed <= 5.f) { maxConcurrentCount = 8; }
        else if (currentSpeed >= 5.f && currentSpeed <= 7.f) { maxConcurrentCount = 10; }
        else if (currentSpeed >= 7.f && currentSpeed <= 10.f) { maxConcurrentCount = 12; }
        else if (currentSpeed >= 10.f && currentSpeed <= 12.f) { maxConcurrentCount = 16; }
        else if (currentSpeed >= 12.f && currentSpeed <= 16.f) { maxConcurrentCount = 18; }
        else if (currentSpeed >= 16.f) { maxConcurrentCount = 20; }
        NSInteger dataType = downloadTask.dataType;
        if (downloadTask.downloadSuccessCount < 6 && currentSpeed > 0.3f) { maxConcurrentCount += 2; }
        else if (dataType == videoFeeFilm && currentSpeed > 1.f) { maxConcurrentCount += 2; }
    }
    CGFloat cpuUsage = [UIApplication sharedApplication].cpuUsage;
    int64_t memoryActive = [UIDevice currentDevice].memoryActive / 1024 / 1024;
    CGFloat batteryLevel = [UIDevice currentDevice].batteryLevel;
    if (cpuUsage > 1.f && maxConcurrentCount > 4) { maxConcurrentCount -= 2; }
    else if (memoryActive == -1) { /* nothing */ }
    else if (memoryActive <= 100.f && maxConcurrentCount > 4) { maxConcurrentCount -= 2; }
    else if (batteryLevel == -1) { /* nothing */ }
    else if (batteryLevel <= 0.02f) { maxConcurrentCount -= 2; }
    if (maxConcurrentCount < 2) { maxConcurrentCount = 2; }
    self.maxConcurrentDownload = maxConcurrentCount;
}

Benefits

Cache Speed Improvement

In a home Wi‑Fi environment, average speed increased from 4.32 MB/s to 14.96 MB/s, with peaks above 20 MB/s under optimal conditions.

Additional Gains

During development, the codebase was cleaned up, adding over 500 lines of comments and 50 log statements, facilitating future maintenance. Several bugs were also discovered and fixed, such as incorrect handling of network‑switch prompts.