Может ли протокол `dat` эффективно поддерживать потоковое видео в реальном времени?

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

Здесь написано:

Протокол dat:// не поддерживает частичные обновления на уровне файлов, а это означает, что при наличии нескольких записей в одном файле каждый раз, когда пользователь добавляет запись, любой, кто следует за этим пользователем, должен синхронизировать и повторно загружать весь файл. По мере увеличения размера файла производительность будет снижаться. Помещение каждой записи в отдельный файл намного эффективнее: когда запись создается, одноранговые узлы в сети загружают только вновь созданный файл.

Однако в нем также говорится здесь dat использует отпечатки пальцев Рабина для создания детерминированных фрагментов файлов, поэтому, по-видимому, клиент данных сможет легко идентифицировать фрагменты, которые он уже скачал, по их хэшу и, следовательно, должен иметь возможность загружать только самые последние последний кусок файла, если это единственная часть, которая изменилась.

А также здесь, в часто задаваемых вопросах, говорится:

Тип дерева Меркла, используемый Dat, позволяет одноранговым узлам сравнивать, какие части конкретной версии набора данных у них есть, и эффективно обмениваться дельтами для завершения полной синхронизации.

Существует гипервидение, но, исходя из моего элементарного понимания того, как оно работает, похоже, что оно сохраняет свое " bundle.js" для видеоданных, я не уверен, как он обеспечивает потоковую передачу, но это не совсем то же самое, что я пытаюсь достичь, а именно способность эффективно передавать произвольно большой и расширяющийся файл, например, видеопоток .ts или .mkv.

Итак, мой вопрос: является ли эффективная прямая трансляция видео (т.е. без повторной загрузки уже загруженных фрагментов) чем-то, что просто в настоящее время не поддерживается и может быть добавлено в будущем, или это что-то, что изначально недостижимо с использованием протокола dat?


person localhost    schedule 30.07.2018    source источник


Ответы (1)


Короче говоря, низкоуровневый протокол Hypercore, на основе которого построен Dat, должен хорошо работать для видео и других видов потоковой передачи в «мягком реальном времени». Однако абстракция файла/каталога гипердиска, на которой строится Dat (приложение), в настоящее время не подходит для этих случаев использования. Ничто не мешает гипердрайву хорошо работать с одним «произвольно большим и расширяющимся файлом», но он не был оптимизирован для этого конкретного случая использования.


Насколько я знаю, все современные прототипы потокового видео работают путем кодирования видеоконтента непосредственно в гиперядро, а не в абстракцию гипердиска «файлы и каталоги». Это похоже на разницу между записью необработанных байтов на жесткий диск вместо использования файловой системы. Потоковое видео и аудио P2P были явными целями разработки Hypercore. Обратите внимание, что может быть или не быть прямого сопоставления с существующими форматами файлов или потоковыми протоколами; абстракция гиперядра представлена ​​в виде потока фрагментов байтов, каждый из которых ограничен размером около мегабайта.

Небольшая деталь: протокол dat/hypercore и форматы на диске не определяют какой-либо конкретный механизм "фрагментирования". Были проведены эксперименты с фрагментацией Рабина, но по умолчанию почти все клиенты используют фрагментацию фиксированного размера вместо этого для простоты и скорости (что не означает, что в будущем невозможно реализовать производительную фрагментацию с учетом местоположения). Теоретически клиенты в любом случае смогут обнаруживать повторяющиеся фрагменты и избегать повторной загрузки (и дублирования хранилища на диске), но по состоянию на лето 2018 года эта оптимизация не была реализована.

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

person bnewbold    schedule 31.07.2018
comment
Это разочаровывает... Было бы здорово иметь возможность комбинировать dat с существующими кодировщиками видео для прозрачной прямой трансляции. Спасибо за подробное объяснение. Не могли бы вы расширить примечание о том, что могут быть или не быть прямые сопоставления с существующими форматами файлов или частью протоколов потоковой передачи? - person localhost; 31.07.2018
comment
Я имею в виду, что могут быть видеоформаты или контейнеры с естественным разбиением на фрагменты (например, в каждом ключевом кадре) или протоколы с естественным кадрированием или разбиением на фрагменты, которые можно легко преобразовать в гиперядерные фрагменты. Это выходит за рамки моей области знаний. Video-over-Hypercore интересует несколько человек; Насколько я знаю, это один из лучших из существующих протоколов dweb для этого варианта использования, поэтому, возможно, стоит провести больше исследований или спросить в IRC. - person bnewbold; 31.07.2018
comment
Спасибо еще раз. Лично я не думаю, что создание фрагментов будет большой проблемой, поскольку кажется, что фрагменты обычно имеют размер порядка 16 КБ. Так что, даже если есть некоторая задержка - это всего 16 КБ позади ... Более серьезная проблема заключается в том, чтобы заставить его работать вообще без необходимости каждый раз повторно загружать весь файл! Я рад слышать, что есть люди, заинтересованные в этом варианте использования. - person localhost; 31.07.2018
comment
Я нашел ссылку, в которой прямо говорится, что снятие отпечатков пальцев Рабина отключено github.com/datproject /обсуждения/вопросы/ - person localhost; 06.08.2018