Comments 9
Их главное отличие — в HLS у нас два критических похода по сети до первого кадра, а в DASH — один. Для нас это было ключевым пунктом при выборе
Не могу понять эту логику. Если воспроизведение стартует на холодную, то до первого кадра вы делаете больше десятка походов по сети чтобы загрузить базовую html-страницу, несколько мегабайт джаваскрипта разбитого на бандлы, код самого плеера, первый сегмент видео. Если страница уже загружена и распаршена, то к моменту начала воспроизведения у вас уже было все время на свете чтобы предзагрузить мастер-плейлист. И даже если этот лишний запрос действительно настолько критичен, мастер-плейлист это буквально несколько строчек текста, передайте их попутно с чем-то еще и скормите плееру на стороне клиента.
Классный поинт. Однако нам он не подходил. Мы - универсальная библиотека для воспроизведения видео на разных сервисах Яндекса с разными сценариями.
Например, на Кинопоиск - сервис, где пользователь может выбрать один из огромного количества фильмов. Мы не можем предзагружать плейлисты всех фильмов, предлагаемых рекомендациями. А после того, как пользователь нажмет кнопку «Смотреть», он ожидает мгновенного запуска.
И причина не в том, сколько весит плейлист (хотя в случае с лайвом hls может весить прилично), а именно в походе за данными. Если у пользователя большой rtt, то это будет критично.
По нашим экспериментам DASH vs HLS, DASH показывает себя лучше.
Сколько мучений ради того, чтобы реклама была не отличима от основного контента и ее было сложнее заблокировать =(
В итоге выбрали Shaka Player, поскольку она весила меньше, чем dash.js
(177кб против 214кб. Ну ладно, допустим, это весомый аргумент)
Но в Shaka Player обнаружилось несколько "архитектурных проблем". А Dash.js подробнее не изучали прежде, чем начать свою реализацию пилить?
Простите, а зачем на погоде видео крутить? :)
Это закрытая библиотека Яндекса или её можно будет использовать на своих проектах?
Свой плеер для DASH: вошли и вышли, приключение на 20 минут. Доклад Яндекса