Зачем что-то придумывать, если есть YouTube?

    Периодически спрашивают знакомые о том, чем занимаюсь. Сразу хочется рассказать любимый анекдот, но сдерживаюсь. Далее после относительно короткого объяснения про видео, его обработку, доставку и наши продукты всвязи с ними, неизменно задают вопрос — «Так ведь есть Ютюб, зачем самому что-то придумывать у себя на сайте?»

    Чтоб два раза не вставать, решил написать небольшой пост именно в ответ на этот частый вопрос — зачем нужно у себя на сайте делать самостоятельную обработку, хранение и показ видео с доставкой до зрителя, если всё это уже могут делать бесплатные сервисы?

    Пару слов о контексте. Цифровое любительское видео у нас на глазах пошатнуло телевизионную монополию на «движущиеся картинки». На наших глазах происходит глобальная смена медиаформата — видео добавляется к тексту и фото и становится основой онлайн-новостей. Я считаю, что с ним сейчас происходит то же самое, что с фотографией лет 10 назад. Себестоимость фотоснимка упала на несколько порядков буквально за несколько лет. Аналогично с видео — оно стало максимально доступным. Любой смартфон может снять ролик с места событий. Благодаря доступному цифровому фото мы наблюдали зарю гражданской журналистики и её развитие, а что даст нам видео — мы можем оценить прямо сейчас, в реальном времени.

    Создать видео может любой, бюджет — от нуля до многих миллионов. Sky is the limit, как говорится.

    Типовые источники видео сегодня:
    • любительская съёмка на смартфон и фотоаппарат — они есть практически у всех.
    • камеры наблюдения, видеорегистраторы, вебкамеры — отличный беспристратсный источник информации. Челябинский метеорит тому свидетель.
    • профессиональные производители контента — телеканалы и медиастудии. С ними всё понятно — конент для телевизора прекрасно идёт и в Сети.


    Две стороны видео



    Всё видео в интернете можно разделить на две неравные части.

    Живое видео (live video) занимает порядка 10% всех объёмов передачи данных. Каковые основные черты:
    • съемка непосредственно с места событий.
    • передача по каналам связи от источника к зрителю в реальном времени
    • требования к инфраструктуре создания, передачи и отображения видео — выше средних.


    Записанное видео (видео по запросу, video-on-demand, VOD) занимает остальные 90% объёма. Основные черты:
    • видео предварительно записано и где-то хранится.
    • скачивается и просматривается по мере интереса.
    • работает на любых каналах и устройствах, страдает лишь качество восприятия.
    • относительно высокие требования к хранилищам данных, в первую очередь к объёму и надёжности.


    Так что не так с Ютюбом?


    Мы подошли к главному элементу главного вопроса — «ведь есть Ютюб».
    Бесплатные сервисы — YouTube, RuTube, Vimeo — что дают и чего в них нет?

    Преимущества:
    • Нулевые затраты на хранение и доставку видео для владельца контента. Халява!
    • Отличная социальная составляющая — вовлечение зрителей не только контентом, то и через like, share, retweet, embed, comment и т.п.

    Недостатки:
    • Ограниченные возможности заработка. На Ютюбе можно заработать, но Гугл возьмёт себе «долю малую» и владельцу контента надо сильно постараться, чтобы своими рекламными прибылями хотя бы окупить создание контента.
    • Потеря контроля над контентом. Отсюда возможная блокировка хостером по любому поводу, включая жалобы правообладателей или контролирующих органов. Сервис стремится обезопасить себя, а стало быть, вы ходите по краю, если выкладываете что-то кроме котиков и бугагашечек. Любая жалоба — и вы рискуете не увидеть своё видео.
    • Сильное пересечение с конкурентами. Пока вы показываете товар лицом через своё видео, рядом в списках похожих роликов в очереди на проигрывание уже стоят ролики ваших конкурентов по этой же тематике. И это если конкуренты уже не заказали демонстрацию рекламы прямо перед вашим видео.


    Альтернатива — создание своей системы показа видео.

    Преимущества:
    • Возможность заработать денег. Основные способы монетизации — рекламная модель или подписка за время или просмотры (т.н. pay-per-view).
    • Полный контроль над контентом — вы показываете то, что считаете нужным. Вы получаете права на показ контента или же сами его производите, и можете показывать его сколько угодно, пока это не нарушает законы вашей страны. Да и конкуренты уже не могут крутить свою рекламу без вашего ведома.
    • Произвольное совмещение живого эфира и записанного видео. Можно сваять хоть свой телеканал «Коленка-ТВ», где крутить и прямую речь, и заранее записанные ролики. Бесплатные каналы такое делать не умеют.
    • Полный контроль над представлением. Возможно наложение текста и изображения поверх видео так, как вам нравится. Пустить бегущую строку, счёт матча, рекламу — что угодно.

    Недостатки:
    • Затраты на внедрение инфраструктуры видео. Купить или арендовать сервер, настроить всё нужным образом, прикрутить правильный плеер, сделать систему сбора денег
    • Затраты на поддержку инфраструктуры 24/7. Оплата трафика, серверов, зарплаты админам и разработчикам, и т.п.
    • Затраты на расширяемость в случае резкого увеличения аудитории. Бросили ссылку в коммент в статье а Хабре — и вас накрыл хабраэффект. Расширяемость для видео инфраструктуры сделать сложнее, чем для сайта с текстом или фото, требуются дополнительные вложения.


    Золотая середина



    Разумеется, оба варианта вполне работают вместе. Совмещение бесплатных сервисов и собственных разработок идёт на пользу бОльшему охвату аудитории. Лучшие качества обоих подходов дают кумулятивный эффект. Самый яркий пример из недавних — телеканал Russia Today. Они первые из новостных каналов преодолели планку в миллиард просмотров, имея на сайте свой собственный видеостриминг и передавая свои программы по традиционным каналам — спутникам и кабельным сетям.

    Как правильно варьировать бесплатные сервисы и своё собственное решение? Основной критерий — отношение к контенту и его монетизации. Чем больше хочется эксклюзивности и денег, тем меньше стоит отдавать ваш контент на откуп бесплатным сервисам. Можно выделить две крайности.
    1. Видеоконтент вторичен, он лишь дополняет основные продукты. Если речь о компании, для которой видео — это просто способ рассказать о продукте, и нет боязни конкурентов, значит Ютюб будет в самый раз. Ведёте новостной портал с аналитикой, фото с мест, и дополняете его своим видео — отлично, Ютюб бесплатно даст возможность и разместить видео, и создать возможность социального взаимодействия. Цель — привлечение на ваш сайт, и с этим он справится. Свой видео-велосипед здесь скорее всего не нужен.
    2. Контент первичен, он и есть — ваш продукт. Вы продаёте видео по подписке или через ограничение доступа — например, с заработком на рекламе. В этом случае Ютюб будет идеален для раскрутки: тизеров, трейлеров и рекламы этого самого контента. При этом непосредственно заработок будет идти засчёт привлечённых на сайт пользователей. Кинули вирусный ролик на Ютюб, люди растащили его по блогам, ВКонтактам, поставили лайки — и часть из них пришла посмотреть на всё остальное. Всё остальное уже под вашим контролем, на вашем оборудовании, с вашими системами ограничения доступа и заработка.


    Где находитесь вы в этой системе координат — вам виднее.

    Да, делаем своё



    И вот вы поняли, что вам как минимум стоит попробовать собственное вещание.
    Вам нужно озадачиться следующими составляющими:
    • Средства создания видео — для начала это может быть смартфон, камера или хороший фотоаппарат.
    • ПО для обработки видео — опции варьируются от бесплатного до профессионального за много килобаксов.
    • Медиасервер — то, что будет раздавать ваш контент в нужных форматах и по нужным протоколам. Нужно ПО и оборудование. Здесь картинка та же — от бесплатного софта с виртуальным хостингом за 5 долларов в месяц до выделенных серверов с проприетарным ПО за тысячи долларов в год.
    • Веб-сайт с видеоплеером — сделать правильное отображение контента через браузер или через приложения для смартфонов или STB (set top boxes). Тут работает традиционное правило — или тратится своё время и всё делается бесплатно, или нанимается профессиональный разработчик, который делает всё правильно.


    В принципе, не так уж много. Фактически, от «условно бесплатно» до миллионных бюджетов.

    На этом можно пока остановиться. На основной вопрос — «зачем оно вообще надо?» — я ответил. Если нужны статьи с подробностями создания тех или иных видов решений — прошу в комменты.
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 56
    • +1
      Часть затрат на инфраструктуру можно снять, разместившись в облачных сервисах, да и риск хабраэффекта резко снижается. Вот только вопрос, кто из них захочет иметь дело с видеостримингом?
      • 0
        Из последних примеров облачных сервисов, которые точно любят стриминг — Amazon и Rackspace. Мы плотно работаем с медиасервером Wowza, вижу по ним. Вовза очень тесно сотрудничает с обоими и не собираются останавливаться на достигнутом. С Амазоном Вовза «дружит семьями» — есть интеграция с CloudFront, прозрачный биллинг. С Рэкспейсом Вовза проводила на днях совместный семинар, о том, как правильнее сделать живую трансляцию, развернув обрабатывающие мощности в их облаке.
        Что такое стриминг с точки зрения провайдера? Много трафика и, если это VOD, много дискового пространства. То есть это живые деньги для них.
        • +2
          Вы так не снизите затраты, а многократно их повысите, если внезапно видео станет чуть популярнее. Снизит это затраты только если просмотров совсем мало.

          А с видео дружат все облака с платным трафиком, думаю. Это ж их хлеб.
          • 0
            Если вы решили заняться тем, что выкладываете видео у себя, то вы однозначно это видео как-то монетизируете. Иначе смысла нет и надо спокойно использовать Ютюб. Так что затраты вырастут, конечно, но уже вместе с прибылью. Что владельцу контента как раз и нужно.
            А про затраты — речь в комментарии выше о том, что затраты можно снизить по сравнению с решениями на выделенных серверах. До какого-то предела именно так и есть — облака помогут быстро заскейлиться. Но после определённого порога проще выделенные сервера покупать.
            • +2
              Я к тому, что для видео на объемах чуть превышающих минимальные, намного выгоднее оплачивать сервер с безлимитным каналом, чем трафик помегабайтно. Амазон и подобыне решения больше подходят для стартапов, котрые уже получили инвестиции, но еще не набрали в команду людей, что могут качественно настроить сервера, найти правильный хостинг и т.д.
              • 0
                В целом да, согласен. Тут уже зависит от «экономики» конкретного проекта. У нас недавно одному клиенту для счастья хватило лимитов трафика DigitalOcean, например. Ему оказалось проще раскидать запросы на несколько мелких серверов, каждый из которых по итогу месяца не выходил за рамки своего тарифа. В итоге себестоимость была буквально копеечная. Но это скорее исключение — стример был действительно начинающий.
          • 0
            облачные сервисы + видео — это многократный рост расходов.

            • 0
              Многократный — по сравнению с чем?
              • +1
                Предположу, что по сравнению с коло/дедиком.
                • 0
                  Виртуализация, конечно, даёт свои накладные расходы. Но насчёт многократного роста — хотелось бы посмотреть на конкретные бенчмарки и какие-то конечные цифры.
                  Плюсы виртуализации в другом — меньше порог вхождения, больше скорость развертывания, проще наращивать мощность. Накладные расходы перекрываются экономией на других направлениях.
                  Дедики/коло становятся выгоднее чуть позже, когда начинает сказываться разница в ценах на трафик и память. То есть при больших объёмах.
                  • +1
                    При чём тут виртуализация? Мы же рассматриваем готовые сервисы, с оплатой трафика и хранилища, а не создание собственного облака.
                    Стоимость трафика и хранения основные составляющие затрат итоговых, и они в облаках больше, чем на выделенных серверах, как только речь заходит о чём-то большем чем показ друзьям пары видео.
                    • 0
                      При чём тут виртуализация?

                      Максим erlyvideo явно написал про многократный рост всвязи с виртуализацией, про это и был мой уточняющий вопрос и далее ответ.

                      они в облаках больше, чем на выделенных серверах

                      Именно об этом я и написал в комменте выше — да, накладные расходы выше. Преимущество в том, что остальные плюсы подобного подхода до поры-до времени перевешивают эти затраты.
                      После определённого порога, конечно, выгоднее использовать выделенное железо и каналы. Собственно, нам, как поставщикам продуктов для стриминга, нет большой разницы, где работать — выбор за клиентом, в конечном счёте.
                      • 0
                        Нет, он написал именно об облаках. Давай все же не смешивать две разных области: техническую и экономическую. Виртуализация это чисто технический аспект, облака — чисто экономический (в данном контексте).
                        levgem.livejournal.com/397082.html?thread=4427546#t4427546
                        • 0
                          От автора вопроса я не услышал уточнения. Но он явно говорит о росте расходов, то есть об экономике — про неё и написал тебе в ответ.
                          А то, что при энкодинге выжимаются все возможности и нужно хорошее железо — тут не спорю. Вот и screaam об этом же в комментах ниже пишет.
                • 0
                  Вопрос тут экономический.

                  Облако при равномерном использовании всегда дороже, чем bare metal, потому что ты платишь за _возможность_ всплеска.

                  Но для старта DigitalOcean — ок, годится.
                  • 0
                    Вопрос был, в общем-то, про «многократный». Оверхед есть, но он явно не в разы.
                    Платят не столько за возможность всплеска, сколько вообще за удобство развертывания и управления. Поднимая несколько виртуалок за считанные минуты, а потом в любой момент изменяя их параметры — сильно экономишь по времени.
                    • 0
                      тут вопрос в возможности прогнозирования нагрузки и её равномерности.

                      Если она прогнозируемая и равномерная, все эти облака — это именно многократный оверхед.

                      Хостер в Амстердаме дает в разы лучшее качество, чем Амазон и в разы дешевле. Но он инертен, это факт.

                      Просто когда виртуалка, которую так удобно настраивать, стоит дороже чем выделенный сервер на котором она работает, то нафига она нужна с её удобством?

                      Но это уже вопрос не про стриминг, а про облака вообще.
                      • 0
                        Всё верно. Облака vs. Железо — этому спору столько же, сколько самим облакам. Стриминг как юзкейс просто обостряет противоречия между этими опциями.
                        • 0
                          Стриминг обостряет в том числе из-за своей специфики.

                          Например, когда надо вещать 30 гигабит, то предложение поставить балансировщик вызывает только улыбку.

                          Но на текстовых сайтах таких нагрузок практически никогда не бывает, поэтому балансировщик там всегда годится.

                          Иначе говоря: «обычные» задачи создают нагрузку на CPU и память. Видео — на сеть и иногда на диск. Отсюда постоянное стремление отказаться от облака
                          • 0
                            А что не так с идеей разбалансировать 30 гигабит? Десяток небольших эджей ставится на нескольких локациях, поближе к потребителям — и вперёд.
                            • 0
                              раскидывать клиентов между эджами или пропускать 30 гигабит через балансер.
                              • 0
                                HTTP-based протоколы (HLS, HDS, Smooth, DASH) поддерживают редирект по 302 ответу, аналогичный механизм есть и в RTMP. Балансировщику нет необходимости пропускать через себя все 30 гигабит. Соответственно можно раскидывать соединения как по раунд-робину, так и по признаку местонахождения (гео-балансинг) и по более сложным схемам типа нагрузки на конкретные сервера и т.п.

                                Для самых простых случаев, когда вполне подойдёт раунд робин — можно просто настроить DNS failover — балансировщик в этом случае вообще не нужен.
                                • 0
                                  Вы успешно внедряли 302 редирект на HLS и HDS? Или вы только предполагаете?
                                  • 0
                                    Мы его не просто внедряли — на этом построена балансировка в нашем медиа-сервере. Она работает и используется нашими клиентами.
                                    • 0
                                      Проблемы есть с этим 302 у разных клиентов.

                                      Не все пережевывают.
                                      • 0
                                        Какие ещё есть безболезненные варианты, если не брать решения на основе маршрутизации?
                                        • 0
                                          iframe с плеером.

                                          Очень, кстати, неплохой вариант, учитывая, что кастомеры поголовно не в состоянии вставить плеер без ошибок.

                                          Ещё мы экспериментировали с хитрой схемой, когда с балансировщика отдается HLS и HDS плейлисты, а в них уже ссылки на плейлисты на ориджинах.

                                          Ну и DNS маршрутизация. Наш балансировщик отслеживает состояние разных стримов и отдаст список IP-шников, на которых есть нужный стрим. Это даже кому-то пришлось использовать, с совсем бедовыми клиентами типа приставок.
                                          • 0
                                            Это всё вполне работающие варианты. Но чем хорош 302 редирект — не надо ничего придумывать ни на стороне сайта (с iframe ссылку ведь всё равно менять надо на нужный сервер), ни на стороне марштуризаторов. Дал единообразную ссылку — и дальше забота сервера, куда бросать запрос.
                                            Чуть позже сделаем баласировку на основе обратной связи от серверов по текущей нагрузке, опять же на основе 302 ответа, как работающего «из коробки».
                                            Если клиент хочет чего-то более интересного, вроже DNS-маршрутизации — его право.
                                            • 0
                                              Не, iframe отдается с одного адреса, а в нём уже адреса к разным стримерам.

                                              Мы поддерживаем много разных клиентов: не только айпады, но и андроиды, приставки, VLC и т.п. Я могу подетальнее позже попробовать вспомнить, где именно разваливается 302
                                              • 0
                                                Код, который внутри iframe, всё равно надо как-то формировать, т.е. это ещё одно звено.

                                                Если вспомните про 302 — пишите, конечно.
                                                • 0
                                                  балансировщик с 302 — это такое же звено, как и генератор iframe.

                                                  Просто пользователь себе на страницу вставляет:

                                                  <iframe src="pointcdn.net/users/15/streams/ort" width=240 height=160></iframe>

                                                  и от балансировщика получает:
                                                  <html> <body> <video src="http://node-1654.pointcdn.net/ort/index.m3u8"></video>

                                                  Это самый безотказный способ для веб-сайтов. Но не работает с приставками. Но приставки могут и по API сходить.
                                                  • 0
                                                    Нас интересовал более универсальный способ, так что iframe не подошёл. Хотя имеет право быть, конечно.
                                                    • 0
                                                      К сожалению, универсального способа я вообще не знаю. Кроме, разве что, anycast, но это не про облака.
            • +2
              Рассматривали этот же вопрос в рамках своего проекта и пришли к выводу, что создавать свой полноценный велосипед не рационально, разве что ограничиться дублированием ютюбовского плеера на тот случай, если по какой-то причине ютюб заблокирует один из роликов. Пришли к такому выводу неслучайно:
              1) Нужны очень большие мощности для обработки видео — 1080р сейчас чуть ли не в каждом смартфоне
              2) Сложности с софтом — что бы получить хорошее качество картинки при 0,10 бит/пиксель нужно кодирование в два прохода. CPU тут бесполезен (при кодировании 1080р большой продолжительности) и остается только использовать Cuda и видеокарты nVidia.
              3) Обеспечение достаточно широкого канала в случае резкого увеличения количества просмотров — 5,5 Мбит/с на клиента при просмотре 1080р это уже не шутки, 100 человек забьют намертво полугигабитный канал.
              4) Использование хорошего плеера — далеко не каждый плеер обеспечивает предпросмотр кадра при наведении курсора на ползунок, позволяет переключаться между потоками разного качества и при этом одинаково хорошо работает на всех платформах во всех браузерах.
              Получается, что сделать сервис, который по качеству лучше или примерно равен ютюбу очень и очень непросто, а так же очень затратно. Не в каждую бизнес-модель это вписывается…
              • +2
                Поэтому логичен компромисс — использовать специализированные платные сервисы. Конечно, они будут стоить денег, но обойдется это гораздо дешевле, чем с нуля разворачивать свою инфраструктуру (для небольших и средних объемов). Своя инфраструктура выгодна только для крупных проектов.
                Я участвовал в разработке одного такого сервиса (но владельцем не являюсь и зарплату там уже не получаю :) Тут ссылку давать не буду, чтобы не сочли рекламой, да ещё и в чужом топике. Если вдруг интересно, могу через личку.
                • 0
                  Платные сервисы тоже разные бывают и за разные деньги. Там «всё не так однозначно» (с) Уходя на универсальное, казалось бы, решение, вы всё равно теряете в гибкости. Да и риски всё равно остаются, просто перекладываются на плечи другого человека. Да, подобный хостер берёт на себя огромную кучу вопросов, но чем более надёжное решение выбираете, тем дороже оно стоит. И возвращаемся всё к тому же — «Не в каждую бизнес-модель это вписывается».
                  • +1
                    Разумеется, везде есть нюансы.
                    Потому я и написал про компромисс — уход от жестких ограничений бесплатных сервисов (обязательная чужая реклама и блокировки за неосторожное использование фоновой музычки, которые невозможно обжаловать), но относительно малой кровью в сравнении с разработкой своего решения с нуля.
                    • 0
                      Так точно, готовые сервисы — как раз компромисс, стоящий чуть обособленно между обоими подходами.
                  • 0
                    Вот тут с вами не соглашусь. Летом буду делать сервис по облачному кодированию видео, который будет заметно дешевле всех конкурентов, в разы, я бы даже сказал.
                    • 0
                      Не совсем понял — только кодирование? А хостинг и стриминг?
                      • 0
                        Только кодирование, да. Возможно, пока.
                        • 0
                          Ну что ж, удачи вам. Энкодинг/транскодинг — штука крайне непростая, особенно когда хочется чем-то выделиться на фоне конкурентов. Чем думаете отвоевать свой кусок рынка?
                          • 0
                            Дешевизной и гибкостью настроек. Можно будет, например, любые фильтры ffmpeg использовать, любые параметры.
                            • +1
                              Мы, когда Cloud4video.ru делали, тоже думали, что важна гибкость, а потом оказалось, что люди с этой гибкостью не могут разобраться.
                      • 0
                        во-первых, нашли чем хвастаться: «дешевле конкурентов». За счёт чего? Отсутствия поддержки или фигового выходного качества?

                        Это очень серьезное заявление, потому что сервисы по кодированию видео не то что бы прям 1000% маржу имеют.
                        • 0
                          За счет того, что я, во-первых, буду распараллеливать кодирование даже одного файла на несколько серверов, а во-вторых за счет того, что я нашел место, где можно взять в аренду мощные компьютеры за крайне низкую стоимость.
                          Предполагается делать 2 варианта оплаты: либо за машинное время, либо фиксированная стоимость в месяц. В первом случае, используется пул доступных для кодирования машин, и оплачивается машинное время. Предполагается, что стоимость машинного часа будет в районе $1.2. Предположим, вам нужно кодировать видеофайл, который идет 1 час, с пресетом veryfast, и получается, что видео кодируется в 3 раза быстрее, чем воспроизводится. Вы заплатите за 20 минут кодирования, т.е. $0.4. А если кодировать нужно с пресетом veryslow, и видео кодируется в 2 раза медленнее, то вы заплатите $2.4.
                          Фиксированная стоимость подразумевает покупку конкретного количества машин, которые будут заниматься кодированием только вашего видео. 3 машины будут стоить что-то около $50-60 в месяц. На них можно кодировать как хочется и сколько хочется.
                          • 0
                            Выше правильно заметили насчёт денег. Пересчитайте всё несколько раз, с разными сценариями использования и разными типами пользователей. Очень уж специфичная и узкая ниша.
                            • 0
                              > распараллеливать кодирование даже одного файла на несколько серверов

                              Это очень серьезный рост расходов. Ведь любое распараллеливание в сумме увеличивает расходы.

                              Т.е. идея распараллелить обработку на нескольких серверах во-первых, потребует серьезных инвестиций, которые вы потом будете забирать у клиентов, во-вторых никак не сделает дешевле ваше решение. Только дороже.

                              > я нашел место, где можно взять в аренду мощные компьютеры за крайне низкую стоимость.

                              Это место называется магазин. Дешевле чем там взять сложно. Через 2-3 месяца покупка Core i7 окупит любую аренду.

                              Я так и не понял в чем же ваша идея по кодированию и какие ценники вы собираетесь предложить.

                              • 0
                                Т.е. идея распараллелить обработку на нескольких серверах во-первых, потребует серьезных инвестиций, которые вы потом будете забирать у клиентов, во-вторых никак не сделает дешевле ваше решение. Только дороже.
                                Это будет не enterprise-решение. Я его делаю, главным образом, для себя, а там посмотрим, что из этого выйдет. Вполне возможно, что все провалится.
                                Это место называется магазин. Дешевле чем там взять сложно. Через 2-3 месяца покупка Core i7 окупит любую аренду.
                                Скажем, я знаю где арендовать 8-ядерные Xeon с 16ГБ оперативки за $0.01 в час. Месяц аренды получается всего $7.2. Трафик неограничен, но и канал не супер. Они, безусловно, могут падать и отключаться в неподходящий момент, но это не проблема, т.к. планируется нарезать видео кусками секунд по 15-30.

                                Я так и не понял в чем же ваша идея по кодированию и какие ценники вы собираетесь предложить.

                                Просто хочу сделать еще один сервис, первым делом для себя, т.к. мне иногда приходится кодировать большое количество видео, а покупать для этого несколько компьютеров домой нецелесообразно.
                                • 0
                                  Вопрос: каким образом планируется склеивать перекодированные куски по 15-30 секунд? Если просто укладывать в mkv с помощью mkvtools (или похожим инструментом), в части плееров, на соединениях, вылезают артефакты. Когда делал себе акселератор перекодирования, эту проблему так и не решил.
                                  • 0
                                    Склеивать буду через mkvmerge. Тестировал разные типы файлов, вроде все относительно нормально (есть проблемы с синхронизацией, но картинка не разваливается).
                                    Более подробно напишу, наверное, в середине июля.
                      • 0
                        «Не в каждую бизнес-модель это вписывается» — совершенно верно. В конечном счёте всё сводится к деньгам, всё остальное — следствие.

                        Касаемо пунктов 1 и 2 — вы пробовали облачные энкодеры типа Encoding.com, Zencoder, Camfoo?

                        Пункт 3 отчасти покрывается горизонтальным масштабированием. Распараллелить на несколько машин — и боттл-нэк уйдёт.

                        А вот плеер да, там сейчас изрядный зоопарк, однако одного универсального решения нет. Разве что JWPlayer, но и он не идеален.
                      • 0
                        А как же лицензирование?
                        Ведь ютуб не просто так блокирует видео если там есть кадры с чужого видео.
                        Или вы хотите думаете какая нибудь бритниспирс будет судиться с сенейизказани?
                        • +1
                          С кем будет судиться гражданка Спирз — пусть решает она сама :)
                          Я не зря написал «и можете показывать его сколько угодно, пока это не нарушает законы вашей страны».
                          Пусть нарушением закона занимаются контролирующие органы. В топике же речь — только о технологиях и о деньгах в связи с ними.
                        • +1
                          правильная статья, давайте дружить, CDN вашим клиентам в любом случае нужен будет как средство для раздачи пикового трафика
                          • 0
                            Отчего ж не дружить :) Захотят раздать через другие сети — их право. Конечно, что не всегда и не везде есть подходящие решения. Да и CDN тоже строится на основе чего-то. Некоторые на основе наших разработок как раз и создают свои CDN.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.