Адаптивная потоковая библиотека (shaka / dash.js), которая не очищает буферизованное видео при поиске?
Кажется, что большинство адаптивных потоковых плееров очищают весь буфер всякий раз, когда вы ищете (до времени, которое не буферизуется). Даже YouTube - например, воспроизвести видео YouTube, искать на несколько минут вперед, а затем вернуться к исходному местоположению. Есть небольшая задержка, так как видео необходимо перезагрузить
dash.js и shaka ведут себя одинаково, и нет простого способа изменить их
Я был в состоянии исправить патч DASH.js, отключив эту функцию, и это работает - но приводит к некоторому нежелательному поведению, такому как сегмент с низкой скоростью передачи данных буферизуется и никогда не обновляется даже при избыточной пропускной способности
Chrome фактически буферизует несколько диапазонов по умолчанию, если вы транслируете обычный mp4, но это не DASH / адаптивный. Кто-нибудь знает о реализации DASH, которая поддерживает это?
0 ответов
Я не знаю ни одного, но я расскажу, почему Shaka Player этого не делает.
Когда вы не очищаете буфер, браузер имеет несколько диапазонов буферизованного содержимого. Это сложно отследить, какие регионы буферизуются, а какие сегменты отображаются на эти регионы. Намного проще отследить последний добавленный сегмент и двигаться дальше оттуда. Если мы играем вперед и попадаем в область, которая уже буферизована, нам нужно будет отследить, какие сегменты связаны с этим буферизованным диапазоном, чтобы мы могли выбрать, где мы остановились. Это не невозможно, но гораздо проще начать все сначала.
Браузер ограничивает объем содержимого, которое мы можем буферизовать. Таким образом, мы очищаем контент, который слишком далеко отстает. Это сотрет части уже буферизованных областей. Так что если есть область от 30-50, которая отображается на сегменты 6-8, которые мы уже буферизировали; если мы очистим некоторые данные и теперь будем буферизовать только 40-50, мы не знаем, какие сегменты все еще буферизируются. Обратите внимание, что мы не всегда можем посмотреть время из манифеста, чтобы определить, какое время соответствует каким сегментам, поскольку оно может быть неточным.
Мы отслеживаем, сколько мы буферизовали перед точкой воспроизведения, чтобы избежать слишком большой буферизации (опять же из-за ограничений браузера). Наличие нескольких буферизованных диапазонов усложняет способ расчета. Тем более, что когда мы добавляем сегменты последовательно, могут также быть пробелы. Таким образом, мы не можем просто посмотреть на конец текущего диапазона, чтобы определить, сколько мы буферизовали. Кроме того, большое количество HD-буферизации в конце видео не помогает, когда мы в начале, поэтому нам нужно очистить это, чтобы освободить место.
Вы также упоминаете, что сегменты низкого качества никогда не исчезают. Это произошло бы и в Shaka Player. Мы никогда не заменяем уже загруженные сегменты. Это опять-таки для простоты (и это может произойти только в разумных пределах). Поэтому, когда мы попадаем в уже буферизованную область, мы просто пропускаем ее, даже если бы мы могли загружать HD. Достаточно сложно определить, какой поток следует воспроизводить последовательно, чтобы продолжить воспроизведение в режиме реального времени; добавление к этому необходимости определить, достаточно ли у нас дополнительных ресурсов для замены уже буферизованного контента, будет слишком сложным.