Почему видеохостинг такой дорогой
Из всех видов статических файлов, используемых на веб-сайтах, с видеороликами связаны наиболее жёсткие требования к хостингу:
- Стили, картинки и особенно скрипты задерживают время готовности страницы к использованию, поэтому важно время отклика. С другой стороны, размеры таких файлов обычно невелики, кэшируемость хорошая, частичная загрузка не важна.
- Видеофайлы имеют большие размеры, кэшируемость плохая (большинство зрителей смотрят конкретный ролик впервые), при этом пользователь может захотеть посмотреть произвольную часть видео. С другой стороны, важна быстрота доставки, чтобы ролик можно было смотреть без перерывов на буферизацию.
- Загружаемое программное обеспечение имеет сравнительно большие размеры, однако скорость доставки не так критична, как в случае видео.
Аренда серверов для видеохостинга в США значительно дешевле (за исходящий гигабайт), чем во многих других странах. Однако доставка видео с американских серверов на другие континенты редко бывает достаточно быстрой, чтобы фильм можно было смотреть без перерывов на буферизацию, и чтобы время ожидания перед началом воспроизведения было приемлемым. Поэтому хозяевам сайтов с видеороликами, выходящих на международную аудиторию, приходится арендовать местные сервера в разных частях света поближе к своим пользователям. Показ ролика пользователю из России, например, обходится типичному видеосайту в несколько раз дороже, чем показ того же ролика американцу. Приходится или дороже платить, или снижать качество видео для зарубежных зрителей. Вот и выходи после этого на международный рынок.
Чтобы решить эту проблему, нам пришлось сделать софт умнее.
Что представляет собой типичный сервер статических файлов? Открыть запрашиваемый файл на нужном месте и слать его в канал. Типичный видеоплеер, работающий в браузере? Запросить файл с нужного места, ждать некоторого минимального наполнения буфера, показывать видео, при этом продолжая его загружать. Если буфер опустеет, ждать наполнения.
Пять серверов вместо одного
Технология Hola CDN вносит улучшения и в клиентский, и в серверный софт. Плеер, работающий в браузере, загружает видео не с одного, а с пяти различных серверов. Один из них — это тот самый надёжный, близкий к пользователю, но дорогой сервер, о котором я писал выше. Он принадлежит к CDN, которой наш заказчик пользовался до нас. Остальные четыре выбираются из пула серверов, которые Hola арендует у различных провайдеров виртуальных серверов там, где это дешевле, — в США, Франции, Нидерландах.
Пользователю важно, чтобы воспроизведение видео началось как можно раньше. Поэтому первый фрагмент в начале видео или после прыжка вперёд загружается с дорогого и быстрого сервера. Зато остальные фрагменты загружаются «впрок» с серверов Hola CDN. Из-за географического расположения пользователя эти фрагменты могут загружаться дольше времени их воспроизведения, а какой-нибудь один из вторичных серверов и вовсе может быть недоступен. Но умный клиентский софт умеет загружать фрагменты с разных серверов параллельно, а также исключать использование недоступных серверов. В результате большая часть видеофайла загружается по частям с дешёвых серверов, а затем незаметно для зрителя склеивается в непрерывный видеопоток. Клиентский код непрерывно измеряет показатели загрузки с разных серверов и принимает решения о том, откуда загружать каждый следующий фрагмент и сколько фрагментов нужно держать «впрок».
К тому же клиентский код Hola CDN качественно кэширует загруженные фрагменты видеоролика. Даже если зритель то и делает, что скачет туда-сюда по длинному фильму, ни один из уже загруженных фрагментов не придётся загружать снова, как это часто случается с большинством распространённых сейчас веб-плееров.
Что касается серверов Hola CDN, то они представляют собой умные зеркала. Они загружают с первичного CDN и хранят у себя копии популярных видеофайлов, причём пофрагментно.
Другие меры по экономии трафика
Ещё одна важная мера, направленная на снижение хостинговых издержек, — не загружать слишком много видео «впрок». Очень часто пользователь не досматривает видеоролик до конца. При этом большинство веб-плееров загружают столько, сколько могут загрузить, и если у пользователя быстрое соединение, вполне могут успеть скачать ролик целиком за то время, пока пользователь посмотрит четверть и решит дальше не смотреть. Наш плеер загружает только ограниченную длину видео, достаточную для бесперебойного воспроизведения. Последние две функции доступны бесплатно и экономят трафик даже тем, кто не пользуется серверами Hola CDN.
Hola CDN умеет работать как в браузерах с поддержкой HTML5 video, так и в тех, где для воспроизведения видео по-прежнему приходится использовать Flash. Мы рекомендуем заказчикам собственный Hola Player, построенный на основе video.js, но можем работать и с JW Player, а также с любым плеером, основанным на HTML5. Мы используем технологию Media Source Extensions для того, чтобы поставлять HTML5-видеоплееру загруженные по отдельности фрагменты.
Поиграться
Для читателей Хабра мы впервые публикуем ссылку на наш внутренний инструмент для тестирования клиентского кода на различных комбинациях плееров, форматов и сценариев использования. Добро пожаловать, можно поиграться! Естественно, мы не гарантируем, что всё это работает, что оно не изменится в будущем, и что мы вообще эту страницу не решим когда-нибудь убрать. Многие комбинации там совершенно точно не работают, а некоторые вообще невозможны даже теоретически.
Приходите к нам
У нас уже появляются первые довольные заказчики, в то время как множество других потенциальных клиентов находятся в стадии наладки и тестирования. Нам ещё много предстоит сделать: добавить поддержку живых видеопотоков, различных форматов видео, плееров… Поэтому нам нужны хорошие программисты. Работа удалённая (либо в офисе, если Вы живёте в Израиле), график гибче не бывает, высокий заработок. Наш отбор от тестового задания до успешного прохождения испытательного срока проходит в среднем один из 250 кандидатов. Вы должны отлично знать JS, который мы применяем как на клиенте, так и на сервере.
Если Вас интересует работа в Hola, или Вы знаете кого-то, кто может нам подойти, пишите мне на alexey@hola.org. Если Вы приведёте кого-то, кто пройдёт отбор и проработает у нас первые три месяца, мы заплатим Вам 7000 USD.
Комментарии (56)
kstep
29.10.2015 15:05+1Torrent в браузере?
feldgendler
29.10.2015 15:12Мы с этим экспериментировали. На практике оказывается нереально обеспечить бесперебойное воспроизведение.
g0dlike
29.10.2015 16:25А на чем реализовывали клиентскую(браузерную) часть во время экспериментов — просто интересно:)
feldgendler
29.10.2015 16:31У нас нет реализации BitTorrent на чистом JS, и это, скорее всего, вообще невозможно. Есть модуль на C, в котором использована сторонняя библиотека для загрузки торрентов. Этот модуль запускается как отедльный процесс под Windows и Android.
Dim0FF
29.10.2015 18:22+1Webtorrent не смотрели? Он и на гитхабе есть.
feldgendler
29.10.2015 20:37Спасибо, интересный проект. Правда, там написано, что протокол модифицирован и не совместим с BitTorrent, но всё равно потенциал есть.
at0mic
02.11.2015 04:29Еще пару лет назад бразилец один написал bem.tv, со свармом, блекджеком ну и остальным. Работает он правда только в хроме, MSE нужен.
И оно работало, и даже неплохо. Плохо только дл live стримов неприменимо.
Еще есть peer5, кстатиfeldgendler
02.11.2015 12:39Для всего остального, что мы вытворяем, тоже нужен MSE. Но теперь это есть не только в Chrome, но и в Firefox, Opera и даже новейших IE.
Xfrid
29.10.2015 20:02А в чем, на ваш взгляд, была причина? Недостаток протокола торрента/udp?
feldgendler
29.10.2015 20:37Много времени занимает изначальный поиск источников, нет никаких гарантий. Всё-таки в коммерческом видеохостинге нужны гарантии, что видео начнёт играть через разумное время после запуска и не остановится посередине.
Возможно, если технологию совместить с обычной загрузкой по HTTP, можно достичь успеха.kstep
30.10.2015 12:32+1Ну можно в качестве надёжных пиров использовать те же сервера CDN-а, которые всегда присутствуют в хайве, плюс по возможности использовать живой пиринг.
at0mic
03.11.2015 02:42Так обычно и делают те, кто Р2Р как услугу предлагают. В опен-сорс не выкладывает что-то никто. Оно, на самом деле, несложно выходит с webtorrent и hlsjs, просто это ж сделать надо.
MadCat
29.10.2015 15:19+1А есть ли какая-то изкоробочная возможность лимитировать доступ к видео по сессионным заголовкам, кукам или чему-то подобному? Какой-то аналог docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html
feldgendler
29.10.2015 15:30+2Для каждого заказчика мы настраиваем ограниченный круг доменов, на которых может быть размещён плеер. Благодаря этому никакие проходимцы не смогут просто разместить плеер на своём сайте за чужой счёт. А уже в пределах своих доменов хозяин сайта сам должен ограничивать, кому он показывает какие ролики.
Поскольку видео грузится как cross-domain (CORS), о печенюшках говорить не приходится. Можно разработать какую-то систему с ключами в URL, если этого пожелает заказчик. Но смысла в этом всё равно маловато.
zhengxi
29.10.2015 16:41Проблема этими европейскими хостингами предлагающими сервер + 300мбит за $30-40 в месяц в том, что когда начинаешь действительно раздавать 300мбит, то через какое-то время они отключают сервер, а на тикеты отвечают «we do not like you» (четыре случая за 2 года).
Хотя если их много, то можно и надёжный CDN сделать.feldgendler
29.10.2015 17:00+3У нас их много. Мы научились строить надёжный сервис поверх ненадёжных провайдеров.
hack2root
29.10.2015 18:29То есть это витруальные 300Мбс, теоретически возможные, а не реально доступные потребителю в пике нагрузки?
zhengxi
29.10.2015 18:49+1В пике-то доступные.
Если постоянно столько качать, то внезапно начинают считать деньги и выгонять клиентов от которых мало прибыли, а то и убыток.
Woodroof
31.10.2015 20:55digitalocean как-то заподозрил, что наши виртуалки взломали, и заблокировал их. Мы написали письмо, где объяснили, что большая нагрузка в первую неделю месяца для нас — норма. Больше проблем не было.
Это те самые 300 Мб. Впрочем, они честно попросили снизить обычное использование до 100 Мб с виртуалки. За $10 в месяц за виртуалку просьба вполне адекватная.
Joshua
30.10.2015 01:33Интересный проект! Интересуюсь, есть ли еще кто то из видео-хостеров, кто так же использует одновременно несколько источников в плеере? Глянул на ютуб — очевидно, что они довольно умно динамически управляют подкачкой, но, видимо, все кусочки тянутся с одного сервера, выбранного при первоначальной загрузке страницы. Есть ли какие то технологические подводные камни такого склеивания?
Умеете ли динамически управлять качеством потока, снижать его при низких скоростях?
Кстати, неужели проблемы с битторрентом оказались не решаемые? Вроде бы протокол специально разработан для похожих задач и видел открытые проекты с его реализацией на клиенте.feldgendler
30.10.2015 02:01+1У YouTube софт весьма умный, но их технология никому, кроме них, не доступна. Хотите так — публикуйте видео на YouTube (а это для многих не вариант — например, для порносайтов).
Мы точно измеряем множество показателей и если даже сейчас не умеем автоматически менять качество, то сделать это нетрудно.
Протокол такой, что его не реализовать в рамках веб-страницы. Webtorrents использует модифицированный, не совместимый с BitTorrent вариант протокола.
Randl
30.10.2015 16:02Но вам ведь и не нужен конкретный протокол, нужно просто чтобы пользователь мог качать видео не только с серверов но и с других пользователей.
feldgendler
30.10.2015 16:35Ну вот вопрос был про BitTorrent. Конкретно немодифицированный BitTorrent в браузере без плугинов использовать невозможно. Но webtorrents — технология интересная и может оказаться нам полезной.
MnogoByte
30.10.2015 12:25Точек в России у вас пока нет? Ожидаются?
feldgendler
30.10.2015 14:18В России сравнительно дорого. Как написано в тексте, наша технология позволяет арендовать сервера там, где это дёшево, и показывать при этом качественное кино даже в тех странах, где сервера дорогие.
at0mic
02.11.2015 05:14Я вижу несколько подходов для решения этой проблемы:
1. плейлист m3u8 создается динамиески с адресами .ts чанков на нужных серверах. В таком случае всегда можно подпихнуть быстрый сервер в начало файла и при перемотке тоже
2. Сами адреса чанков в плейлисте — динамические. На каждый запрос к чанку отдается 302 статус на ближайший или дешевый сервер. Таким образом можно балансировать нагрузку между CDN.
Одним словом: в HTTP протоколе уже все есть и давно реализовано, или я что-то упустил? С безопасностью тоже вроде все нормально, например nginx-secure-token-module есть.
Гораздо интереснее задача раскидать по CDN лайв поток, да так, что-бы чанки появились на серверах быстрее, чем истекли. Эта же проблема и к Р2Р лайв стримам относится, которые, к слову, многие используют уже. Если взять для примера acestream, то у них очень приличная задержка, минут 5 для того, чтобы расползлись данные по пирам.
Кстати, насчет webtorrents, их народ долбит на гитхабе, почему они не сделают реализацию Р2Р видео, на что они отвечают, что это out of scope их проекта, но вполне реализуемо т.к. вебторренты — это транспорт, его можно использовать как угодно. По-моему, Р2Р видео в браузере — это самое востребованное направление сейчас в стриминге, думаю через пол-года — год будут уже очень интересные решения.feldgendler
02.11.2015 12:40У них же демо P2P видео прямо на главной странице.
at0mic
02.11.2015 13:20Это не Р2Р видео в привычном понимании
https://github.com/feross/webtorrent/issues/448
Eternalko
03.11.2015 00:52+1> Р2Р видео в браузере — это самое востребованное направление сейчас
Уже есть и отлично работают.at0mic
03.11.2015 02:08+1А скиньте ссылок на опенсорсные плееры, которые поддерживают Р2Р и умеют играть live-стримы?
Eternalko
03.11.2015 14:12polygoncast — работает с любым HTML5 плеером
peer5 — заработает с любым HTML5 плеером
viblast — только свой плеер вроде но хороший
streamroot — вроде только JW Player + на запросat0mic
03.11.2015 15:22А те, которые к своему cdn подрубить можно? Это все пропиетарные аддоны к опенсорсным плеерам, всех видел, но не то все это.
ArjLover
03.11.2015 00:49Плеер, проект, концепция — все очень интересно. Вот только мне осталась очень непонятна цена. Цент за гигабайт — откуда такие дикие цены?
Цены на рынке сейчас 0,4-1$ за мегабит или 1000$ за гигабит — это максимум. Просто публичные цены у провайдеров, например здесь — ahcdn.com/en/prices
1 гигабит в месяц за 1000$ даст нам 0,125*3600*24*30=324000 ГБ в месяц, которые по ценам этой статьи нам пытаются продать за 324000*0.01=3240$, то есть в 3 раза дороже. А при серьезных объемах на рынке можно получить цену 2-3 раза ниже, то есть разрыв цены уже на порядок!at0mic
03.11.2015 02:01+1С этим как раз вопросов нет. Если вам надо только террабайт раздать в месяц, или раздать сразу короткий поток на 3-4Gbps, то все удобно. Когда есть объемы, денежный поток и руки не из одного места, то естественно этот сервис не нужен.
Никто не мешает же зенкодеру драть по 5 баксов за минуту конвертированного видео, видимо есть спрос.
Мне вот другое интересно: video.js в 5 версии вроде как не умеет из коробки играть hls во флеше, у них есть hls-contrib плагин, который они под последнюю версию так и не допилили. Или я не допонял?ArjLover
03.11.2015 02:12Когда нужно раздать террабайт, в 300 раз меньше чем в моих расчетах — это 3 мегабита. Это из дома можно раздавать или с любой VPS за 5$. Woodroof писал выше, например, 100мегабит за 10$.
Дорого как ни крути, а предлагается сервис только как дополнительный при уже имеющемся собственном каком-то дорогом CDN.at0mic
03.11.2015 02:31-1Из дома раздать террабайт на 600-700 зрителей с битрейтом хотя бы 2000Kbps? Сомнительно. Так же как и ВПСку прикроют моментально если она хоть 20 минут будет по пол-гигабита раздавать.
А вы, кстати, можете попасть в целевую аудиторию. Если у вас внезапно набежит толпа народу на раздачу с домашнего канала, то вот так подключить в пару строк пару мощных серверов удобно же.
Строить самому распределенную систему дистрибуции контента дорого и нервно, это как мороженое: по сути замороженные сливки, но проще купить в магазине.ArjLover
03.11.2015 02:49Мы вели рассуждения в разрезе месяца. Честно говоря давно не видел цен за гигабайт, все оперируют полосой в месяц.
at0mic
03.11.2015 03:31Смысл рассуждать помесячно есть конечно, если трафик плавный и растет прогнозируемо. Это достижимо на больших объемах, на маленьких скачки могут прибить, особенно если не знать, что с этим делать.
Полосой в месяц оперируют все на каналах до 100Mbit. Уже от 1Gbps в основном или ограничения по объему или шаред порт. Ну или дорого просто.
norlin
03.11.2015 14:25+1Мне вот другое интересно: video.js в 5 версии вроде как не умеет из коробки играть hls во флеше, у них есть hls-contrib плагин, который они под последнюю версию так и не допилили.
Плагин contrib-hls последней версии (ветка development) вполне себе хорошо играет HLS во флеше. Проблемы там с проигрыванием HLS через HTML5 (MSE), а вот со флешом всё ок: VideoJS v5 + HLS + Flash, без подключения Hola CDN.
romamo
03.11.2015 10:06А где найти дешевый безлимитный хостинг?
На всех дешевых виртуалках очень скромное ограничение по количеству трафика. На океане за 10 баксов 2Tb.
Этого хватит примерно на 4 суток раздачи 100mbit.
datacompboy
А исходники при этом в каком формате?
Или шо бы ни было, лишь бы могло фидить с произвольного места?
Как сшиваются заголовки у того же rtsp при этом?
feldgendler
Приходится перепаковывать контейнеры. У нас на JS написан парсер контейнера mp4, мы нарезаем видеопоток в нужных местах и заворачиваем в такой контейнер, который ожидает MSE. Эти заморочки — именно та причина, по которой не все комбинации сейчас поддерживаются. Скажем, мы не умеем FLV играть как HTML5 video, хотя это теоретически возможно.
RTSP пока не поддерживаем, но, возможно, будем.
Eternalko
Перепаковка это если бы вы из MPEG-TS MPEG-4 делали (a la hls.js). А так это более нарезка. Если не делаете ABR то нарезайте как угодно, MSE должен скушать любые byte-ranges.
feldgendler
HLS тоже делаем.
Eternalko
Заголовки RTSP? Это же бухгалтерия.
feldgendler
Да, это одна из многих вполне осуществимых вещей, которые можно сделать. Чем больше программистов мы найдём, тем больше интересных штук сможем реализовать.
Eternalko
Я о том что там ничего интересного/сложного нет. Ну это понятно.
А RTSP ИМО мертв)