Почему мой Exoplayer2 CacheDataSource не записывает загруженный поток в назначенный кеш?

ОБНОВЛЕНИЕ, май 2021 г.

Я создал образец приложения на GitHub, которое показывает работу этого кэшированного источника данных для всех читателей, которые интересно это увидеть.

Нажатие на верхнюю кнопку в приложении запускает средство выбора на основе SAF для выбора локального видео (поэтому кеш не требуется и не используется). Uri выбранного файла отображается в EditText, и вы можете нажать «Воспроизвести видео», чтобы просмотреть его.

Однако по умолчанию образец Uri в EditText находится в Интернете, и, поскольку это не локальный Uri (семантика которого не является чем-то действительно официальным, просто простое разграничение, которое я создал для целей этого тестового приложения), он использует настраиваемая фабрика источников данных кеша, которая запускает механику кеширования Exoplayer.

Вы можете просмотреть различия в LogCat во время работы приложения и увидеть, что после первого воспроизведения видео, передаваемого из Интернета, при втором запуске вы начинаете получать обращения из кеша, о чем свидетельствуют вызовы обратного вызова onCachedBytesRead ().

Вы также можете открыть обозреватель своего устройства во время его работы на аппаратном устройстве, подключенном к Android Studio, и вы должны увидеть что-то в этом роде:

Как видите, после первого просмотра видео оно было кэшировано в указанном мной месте, и после этого Exoplayer2 берет видео оттуда, а не из Интернета.

Для потокового видео убедитесь, что вы используете URL-адрес, например:

https://www.learningcontainer.com/wp-content/uploads/2020/05/sample-mp4-file.mp4.

а НЕ что-то уникальное, например, просмотр YouTube, т.е.

https://www.youtube.com/watch?v=Cn8PiqIXEjQ

Кроме того, в этом примере используется источник мультимедиа типа Exoplayer2 Progressive для потоковой передачи Uri из Интернета (который теперь является стандартом по умолчанию, так как тип Extractor был объявлен устаревшим некоторое время назад). Если URL-адрес, введенный в это приложение, указывает на файл, требующий типа DASH, очевидно, что это не сработает.

В Исходном коде Exoplayer2 есть пример приложения, которое выполняет гораздо более сложную работу по тестированию различных реализаций источников мультимедиа. против целевого Ури, пока он не найдет правильного onw.

здесь есть хорошее базовое руководство по Exoplayer2.

====

Оказывается, что это не кеширование является поведением по умолчанию, тогда в обычном процессе управления DataSource оно в большинстве случаев включено. В моем случае это было не так, потому что рассматриваемый Uri был content: // Uri, указывающим на Dropbox, который разрешается настраиваемым поставщиком SAF, который использует API Dropbox для потоковой передачи видео обратно. Таким образом, длина файла никогда не распознается, поэтому поведение по умолчанию не изменяется.

Оливер Вудман из команды Exoplayer предложил два решения. Первый (самый быстрый) заключался в изменении моей пользовательской реализации DataSourceFactory с возврата CacheDataSource на возврат настраиваемого DataSource, который обертывает CacheDataSource - перенаправление вызовов методов из интерфейса DataSource в экземпляр CacheDataSource, за исключением метод open (). В этом случае он сначала изменяет аргумент DataSpec, а затем передает его:

/**
 * Class specifically to turn off the flag that would not cache streamed docs.
 */
private class InTouchCacheDataSource implements DataSource {
    private CacheDataSource cacheDataSource;
    InTouchCacheDataSource(CacheDataSource cacheDataSource) {
        this.cacheDataSource = cacheDataSource;
    }

    @Override
    public void addTransferListener(TransferListener transferListener) {
        cacheDataSource.addTransferListener(transferListener);
    }

    @Override
    public long open(DataSpec dataSpec) throws IOException {
        return cacheDataSource.open(dataSpec
                .buildUpon()
                .setFlags(dataSpec.flags & ~DataSpec.FLAG_DONT_CACHE_IF_LENGTH_UNKNOWN)
                .build());
    }

    @Nullable
    @Override
    public Uri getUri() {
        return cacheDataSource.getUri();
    }

    @Override
    public void close() throws IOException {
        cacheDataSource.close();
    }

    @Override
    public int read(byte[] target, int offset, int length) throws IOException {
        return cacheDataSource.read(target, offset, length);
    }
}

Затем этот класс используется настраиваемой фабрикой следующим образом:

@Override
public DataSource createDataSource() {
    CacheDataSource dataSource = new CacheDataSource(InTouchUtils.getMediaCache(),
            defaultDatasourceFactory.createDataSource(),
            new FileDataSource(),
            new CacheDataSink(InTouchUtils.getMediaCache(), maxCacheFragmentSize),
            CacheDataSource.FLAG_BLOCK_ON_CACHE | CacheDataSource.FLAG_IGNORE_CACHE_ON_ERROR,
            listener);
    return new InTouchCacheDataSource(dataSource);
}

Это работает отлично, и Оливер уверяет меня, что Exoplayer поступит правильно, даже если поток заполнит кеш (т.е. сначала вызовет выселитель, а затем, если это не удастся, прекратите попытки записи в кеш и просто продолжите поток).

Другой вариант - написать собственный источник данных с использованием ContentDataSource в качестве начала и включить в него настроенный SAF (поскольку, по крайней мере, в моем случае я действительно знаю размер файла, но стандартные методы SAF используются для предоставления возможности чтобы передать это обратно в стандартный подход поставщика / распознавателя SAF).