Каждый, кто хоть раз смотрел видео в интернете, понимает эту боль: видео запускается быстро, но в ужасном качестве. Или, наоборот, приходится по несколько секунд ждать, когда контент прогрузится сразу в высоком качестве. Как решить эту проблему, придумала команда онлайн-кинотеатра KION. О релизе новой функции и первых успехах рассказали продакт-менеджер Дмитрий Пискунов и разработчик Денис Чорный.
Суть проблемы
В стриминге есть актуальная и до сих пор толком не решенная проблема — как определить, в каком качестве начинать воспроизводить видео. Понятно, что благодаря адаптивному битрейту любой контент со временем подстроится: если есть возможность поднять качество, плеер это сделает. Но что делать на старте, какое качество выбрать?
Некоторые сервисы онлайн-кинотеатров сразу замахиваются на самое высокое качество. И потом зритель со слабым интернетом долго смотрит на «бублик» загрузки, ожидая начала воспроизведения.
Другие запускают видео с самого низкого качества вне зависимости от пропускной способности сети — и неприятно удивляют размазанной картинкой зрителей с хорошим интернет-сигналом. Если на мобильных гаджетах это еще не очень заметно, то на умных телевизорах сразу бросается в глаза.
До апреля этого года мы в KION стартовали с дефолтного качества — 480p. Но это решение не оптимально, оно не затрагивает крайности: тех, у кого очень медленное и нестабильное подключение, и тех, у кого интернет очень быстрый.
Мы понимали, что негативный опыт на старте просмотра может отразиться на всем впечатлении от платформы. Особенно, если речь о первом взаимодействии пользователя с продуктом. Поэтому для нас было важно быстрее решить проблему.
Та самая механика
В поисках оптимального решения мы разработали механизм, который замеряет скорость интернета, а потом, на основании этих данных, подбирает качество для старта воспроизведения. Например, если в конкретный момент пользовательская пропускная способность в диапазоне 6-8 Мб/сек и выше, мы можем предложить пользователю смотреть контент в качестве Full HD на старте воспроизведения.
Когда мы успеваем измерить скорость интернета? Мы делаем замеры везде, где запускается плеер. То есть проверяем пропускную способность сети на:
баннерах на платформе;
трейлерах в карточке контента;
трейлерах непосредственно перед контентом;
на этапе загрузки приложения и других элементах — об этом мои коллеги рассказали в статье «Как мы загрузочный экран приложения в полезный для пользователя инструмент превратили».
Потом мы учитываем данные о качестве подключения уже при показе основного контента. Например, когда вы выбираете контент и перед ним смотрите рекламу, плеер уже работает и в том числе замеряет пропускную способность сети. Данные о вашем подключении плеер хранит определенное время — мы называем его valid time. А потом с учетом собранных данных о подключении запускает контент соответствующего качества. Если ваше подключение будет меняться, плеер адаптирует качество контента.
Все видеобаннеры на старте, на главной странице, трейлеры и так далее — это ExoPlayer. Под капотом в них используется bandwidthMeter, который может передавать информацию о текущем битрейте. Ее мы и собираем.
Реализуется это так:
bandwidthMeter.addEventListener(Handler(Looper.getMainLooper())) { _, _, bitrateEstimate ->
// получение текущего значения битрейта bitrateEstimate
bandwidthManager.provideNewBitrate(bitrateEstimate)
}Для сбора информации по текущей пропускной способности и ее хранения в кэше был создан менеджер (BandwidthManager). Его контракт:
interface BandwidthManager {
/**
* Предоставить новый доступный битрейт
* @param bitrate новый битрейт
*/
fun provideNewBitrate(bitrate: Long)
/**
* Текущее значения битрейта
*/
val currentBandwidth: StateFlow<Long>
}Как долго будет храниться значение, регулируется динамически с помощью Remote Configs. Если по истечении заданного времени мы не получаем новых данных о битрейте, то сбрасываем значение на дефолтное.
Теперь перейдем к использованию значения пропускной способности из менеджера. Нужно обеспечить старт на хорошем качестве в тех случаях, когда пользователь сидит на «хорошем интернете», то есть тип подключения не ниже 4G LTE или устройство подключено к Wi-Fi.
Для Android TV хорошее и стабильное подключение — через Ethernet-кабель. Специфика Android TV в том, что подключение по проводу или Wi-Fi не обеспечивает нам стабильную пропускную способность. Телевизор может находиться на даче, за пределами города, где плохо ловит интернет, есть перебои со связью. Поэтому старт воспроизведения контента с максимального качества в таком случае не будет правильным решением.
Если же речь о «хорошем интернете», нам следует обеспечить пользователю хорошую пропускную способность на старте. Делаем это через билдер BandwidthMeter:
override fun getCustomBandwidthMeter(
context: Context,
defaultInitialBitrate: Long?
): DefaultBandwidthMeter {
val currentBitrate = bandwidthManager.currentBandwidth.value
return DefaultBandwidthMeter.Builder(context)
.setInitialBitrateEstimate(defaultInitialBitrate ?: DEFAULT_BITRATE)
.setInitialBitrateEstimate(NETWORK_TYPE_4G, currentBitrate)
.setInitialBitrateEstimate(NETWORK_TYPE_5G_SA, currentBitrate)
.setInitialBitrateEstimate(NETWORK_TYPE_5G_NSA, currentBitrate)
.setInitialBitrateEstimate(NETWORK_TYPE_WIFI, currentBitrate)
.setInitialBitrateEstimate(NETWORK_TYPE_ETHERNET, currentBitrate)
.build()
}Фабрика по созданию BandwidthMeter может быть использована вместе с подключением слушателя битрейта:
override fun getBandwidthMeterWithListener(
context: Context,
bandwidthMeter: DefaultBandwidthMeter
): DefaultBandwidthMeter = bandwidthMeter.apply {
addEventListener(Handler(Looper.getMainLooper())) { _, _, bitrateEstimate ->
bandwidthManager.provideNewBitrate(bitrateEstimate)
}
}Для этого в качестве параметра bandwidthMeter можно передать из метода getCustomBandwidthMeter().
Еще стоит учитывать, что в случае Android TV и мобильной платформы время жизни актуального битрейта разное. Например, с мобильным устройством мы можем ехать в метро и постоянно ловить проблемы с интернетом, поэтому искомый параметр не должен быть актуальным долгое время. В случае же с Android TV мы говорим о более стабильной сети. К тому же экраны в Android TV выглядят иначе, чем в смартфоне, и мы не всегда можем попасть на загрузку какого-либо видеобаннера или трейлера перед тем, как начнет проигрываться контент. Поэтому значения времени жизни актуальной пропускной способности мы сделали разными для разных платформ. Пока это эксперимент, он в процессе.
Мы выяснили, что разное время жизни дало нам больше стартов с высокого качества на Android TV, чем если бы мы выбирали одинаковое время жизни информации о битрейте для обеих платформ.
Первые результаты
Всего за две недели с момента внедрения функции мы добились довольно впечатляющих результатов.
На Android Mobile мы на 0,33% улучшили конверсию в осознанный просмотр. Осознанным просмотром мы считаем любой просмотр контента дольше пяти секунд.
Кроме того, если посмотреть, с какого качества стартует контент на мобильных устройствах, то после внедрения функции просмотр контента стал на 171% чаще стартовать с самого высокого качества — Full HD 1080p. При этом доля сессий с плохим стартовым качеством уменьшилась на 50%.
Единственный показатель, который немного просел, это join time — время от нажатия кнопки «Смотреть» до показа первого кадра. Это вполне ожидаемо: из-за того, что мы подстраиваемся под текущий битрейт пользователя и улучшаем качество видео, банально увеличивается размер файла с контентом. Чем больше файл, тем дольше он скачивается и запускается, поэтому после релиза фичи на запуск контента мы стали тратить на 141 мс больше. Теперь это наша новая точка роста, и мы и уже работаем над функциями, которые позволят нам сократить время между нажатием кнопки «Смотреть» и показом первого кадра.
Что касается Android TV, доля сессий с максимальным стартовым качеством (Full HD 1080p) улучшилась еще значительнее — на 1594%. При этом долю сессий с плохим стартовым качеством мы уменьшили на 55%.
На Android TV время с момента нажатия кнопки «Смотреть» до старта воспроизведения тоже немного увеличилось — на 168 мс. Впрочем, как и с Android Mobile, мы планируем в ближайшее время нивелировать это увеличение запуском новой фичи.
Из-за технических особенностей функция пока доступна только на мобильных устройствах на базе Android и на Android TV. Но мы планируем разрабатывать и реализовывать подобную механику и на iOS.
На этом все. Спасибо, что читали! Если есть вопросы, обязательно пишите в комментариях. На все ответим!