Error drm not supported error ivi xiaomi

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

Для нашего контента используется DRM-защита. DRM — это технические средства защиты авторских прав. Не все устройства поддерживают этот формат. Как проверить есть ли поддержка DRM?

1. Для проверки необходимо запустить мультфильм «Утиные истории» 1987 года. Это бесплатный мультфильм с использованием DRM-защиты. Если мультфильм запустился, значит на устройстве есть поддержка DRM-формата.
2. Мультфильм «Утиные истории» не запустился, появилась эта ошибка, либо другая. Вам необходимо запустить мультфильм «Домовенок Кузя» . Это так же бесплатный мультфильм, но уже без DRM-защиты. Если мультфильм запустился, на устройстве ограниченная поддержка приложения. 

В приложении для Android встроена проверка возможности воспроизвести DRM, и если устройство не поддерживает проигрывание DRM, то на карточке контента вместо кнопки смотрения/покупки будет надпись «Просмотр недоступен».

На Android TV в разделе «Техническая информация» указана поддержка DRM-шифрования. 

Важно понимать, что есть сертифицированные устройства ANDROID-TV, которые поддерживают DRM, а есть не сертифицированные устройства, у которых, возможно, отсутствует поддержка DRM-шифрования. Сертифицированные устройства:

• Xiaomi Mi Box
• Xiaomi Mi TV
• Sony Android TV
• Philips Android TV
• Nvidia Shield
• TCL Android TV
• Panasonic Android TV

В последнее время в среде пользователей Android ТВ приставок всё чаще встречается вопрос о наличии и пользе в ТВ приставках различных сертификатов. Что в свою очередь делит рынок устройств на два лагеря: сертифицированные и несертифицированные. В чём же разница между двумя типами этих устройств, и с какими трудностями может столкнуться пользователь несертифицированной ТВ приставки?

Виды сертификатов

Чтобы разобраться в этом вопросе стоит начать с того, что сертификаты в современных ТВ приставках можно условно поделить на три основные категории:

— Сертификаты сервисов

— Аудио и видео сертификаты

— Сертификаты защиты авторского права

На самом деле подобных сертификатов намного больше, все они по-разному реализованы и отвечают за огромное количество функций на Вашем устройстве, но мы остановимся лишь на некоторых из них, которые наиболее интересны с точки зрения рядового пользователя.

Сертификаты сервисов

Тут речь идёт, в первую очередь, о сервисах Google. Спрашивается, а может ли вообще существовать Android без сертификата от Google? Оказывается может. В целом, процесс сертификации новых устройств в Google не самая простая процедура и требует от производителя не только довольно больших усилий, но также времени и денег. Устройство должно пройти ряд тестирований на совместимость и полностью соответствовать требованиям, изложенным в документе под названием Compatibility Definition Document (CCD). После чего его финальная версия с окончательным вариантом прошивки отправляется на сертификацию в одну из лабораторий Google. Стоимость подобной процедуры для одного устройства порядка 10000$, что для большинства производителей довольно-таки смешная сумма. Чего не скажешь о потерянном времени и затратах на доработки в процессе сертификации, что может аукнуться производителю убытками в десятки, а иногда и в сотни тысяч долларов. Немудрено, что некоторые из них, в частности производители из Китая, закрыли глаза на этот неудобный этап и начали поставлять на рынок несертифицированные Android устройства. Справедливости ради, стоит отметить, что пошли на этот шаг не только производители бюджетных устройств из Китая, но и ряд иных довольно крупных мировых компаний, например, в ряде случаев Amazon.

Отличить сертифицированное Android устройство от несертифицированного не так уж и просто. В обоих случаях пользователь может иметь доступ к каталогу приложений, различным лаунчерам, поисковикам и всевозможным доработкам «народного разработчика». Дабы исходный код «чистого Android» доступен любому пользователю и при желании может дорабатываться, как на уровне приложений, так и всей ОС. Однако, служб Google, вроде геолокации, шифрования передаваемых данных и облачных технологий на таком устройстве не будет. А ответственность за обновление ОС до актуальной версии скорее всего полностью ляжет на плечи производителя, либо самого пользователя.

Но далеко не все сервисы принадлежат исключительно Google. А следовательно, ограничения сертификатом могут быть наложены и другими компаниями, например, популярным стриминговым сервисом Netflix. Конечно же это ограничение можно обойти, при помощи того же «народного разработчика» и сторонних клиентов. Но, вероятнее всего, желаемого и стабильного результата получить Вы всё же не сможете. И Вам останется довольствоваться урезанным разрешением, либо и вовсе регулярно вылетающим и перестающим корректно работать приложением. Проверить поддерживает ли ТВ приставка сертификацию Netflix можно в списке сертифицированных приставок(в шапке темы) по этой ссылке.

Аудио и видео сертификаты

Да, поддержка того или иного аудио и видео контента также требует наличие соответствующего сертификатов на ТВ приставке. Чаще всего речь идёт о поддержке Dolby Vision HDR и Dolby Audio (Dolby Digital, Dolby Digital Plus, Dolby Atmos). Однако, тут стоит отметить, что данное ограничение распространяется в основном на воспроизведение контента через стриминговые сервисы, такие как: Netflix, IVI, OKKO, и др. Этот факт делает отсутствие подобных сертификатов практически незаметным для подавляющего числа пользователей ТВ приставок, не использующих вышеуказанные сервисы.

Сертификаты защищающие авторское право

Для защиты правообладателей от копирования контента, защищенного авторским правом, существует ряд программных и программно-аппаратных средств защиты данных — DRM (Digital Rights Management).

DRM (пер с англ. Управление Цифровыми Правами) – набор технологий используемый правообладателями для защиты контента от копирования и неправомерного доступа.

Наличие DRM сертификатов напрямую влияет на то, сможете ли Вы пользоваться на своей ТВ приставке стриминговыми сервисами. Даже если у Вас есть оплаченная подписка, при отсутствии необходимых сертификатов защиты, воспользоваться официальными стриминговыми клиентами не получится.

К популярным на наших просторах DRM, на данный момент, можно отнести:

— Microsoft Playready

— Widevine DRM

— CENC ClearKey

— Google Widevine Modular DRM

— Adobe Primetime DRM

— Marlin

— Verimatrix

Если в Вас проснулся дух исследователя, то для проверки наличия на Вашем устройстве того или иного DRM модуля можно, например, воспользоваться приложением DRM Info.

Что в итоге?

Несмотря на то, что использование полностью сертифицированных ТВ приставок, на наш взгляд, выглядит наиболее безопасным и надежным вариантом. Выбор и приобретение того или иного устройства полностью зависит от Ваших потребностей и бюджета. Если Вы не используете платные стриминговые сервисы для просмотра фильмов и сериалов и готовы смириться с некоторыми общими недоработками несертифицированных устройств, то вполне можете позволить себе сэкономить несколько тысяч рублей. Удачные варианты недорогих ТВ приставок и обзоры на них можно найти в нашей подборке по этой ссылке. Ну а ценителям стриминговых сервисов можно присмотреться, например, к таким вариантам, как Nvidia Shield TV и Nvidia Shield TV Pro, которые долгое время остаются лидерами среди фанатов сертифицированных Android приставок.

Иногда пользователи Smart TV сталкиваются со следующей проблемой: некоторые сервисы не загружаются, виснут или вовсе предательски вылетают. Это касается самых популярных приложений в арсенале умных телевизоров – онлайн-кинотеатров, в частности IVI.

IVI – это передовой отечественный стриминговый сервис, который предлагает домашнему зрителю более 60000 тысяч российского и зарубежного видео-контента: фильмы любых жанров, сериалы, новинки кинопроката, телевизионные программы и анимацию; как бесплатный так и платный доступ к пользованию; понятный и очень удобный интерфейс! Досадно, когда приятный просмотр прерывается или становится невыносимым, если видео то и дело «спотыкается» на значке загрузки. Бывает и так, когда точно злой рок элементарно не впускает Вас в приложение и держит у Вас перед носом черный экран. Но всему есть решение! В этой статье мы обсудим почему не работает ivi на телевизоре и как эту проблему можно решить в домашних условиях!

Причины почему тормозит IVI и рекомендации по решению проблемы

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

1. Перезагрузите ваш телевизор. Все на свете иногда глючит и тупит из-за усталости, и люди, и техника. Вероятно, вашему телевизору просто нужна духовная перезагрузка. Для этого отключите его из розетки на пару минут.
2. Проверьте подключение к интернету. Иногда решение может быть очень примитивным. Попробуйте отключить роутер из розетки на одну минуту, а после заново войдите в приложение. Если же IVI продолжает тормозить, то поменяйте IP-адрес, с которого запускаете приложение. В качестве альтернативы попробуйте ваш планшет или другое мобильное устройство.
3. Поменяйте адрес своего DNS-сервера. Звучит страшно, но порой работает.
4. Сбросьте все настройки своего телевизора до изначальных. Процедура не тронет прошивку телевизора, но есть нюанс: все каналы, которые вы настроили ранее, автоматически удаляться, поэтому этот метод  рекомендуется лишь в качестве крайней меры. У разных брендов эта процедура выполняется по-разному. Для Samsung необходимо предварительно убедиться, что Ваш телевизор имеет сертификат на осбслуживание на территории России. В противном случае Smart Hub заблокируется. Чтобы проверить это, достаточно взглянуть на стикер, который наклеили на телевизор на заводе: правильный код устройства заканчивается на XRU, а также имеет специальный значок EAC.
5. Переустановите само приложение. Удалите и скачайте заново IVI. Для этого войдите в галерею приложений, введите в поисковике IVI и скачайте сервис. У каждой марки ТВ-приемника свой магазин приложений:

• Google Play на Android TV
• SMART и Samsung Apps на Samsung
• Premium на LG
• Toshiba Places на Toshiba
• SMART TV  и App Galery на Philips
• Opera TV Store на Sony

1. Обновите прошивку телевизора. Вполне возможно, что Вы не можете насладиться просмотром фильмов, наблюдая перед глазами вечно виснущую картинку из-за технических особенностей модели Вашего телевизора. К сожалению, с этим редко что можно сделать. Однако, одно решение все же найдется. Вероятно, прошивка вашего устройства давно устарела и просто не тянет приложение. В этом случае, проверьте ТВ на наличие актуальных обновлений.
2. Наконец, одно из самых эффективных средств, чтобы заставить капризный сервис работать: сброс настроек Smart Hub. При данной операции удаляются все скаченные приложения, их данные и переустанавливаются заводские, зато устраняются возможные ошибки.

Инструкция для телевизоров Samsung

Смена адреса DNS-сервера

1. Войдите в «Настройки» на Вашем устройстве
2. Выберите пункт «Общие»
3. Пункт «Сеть»
4. Далее «Состояние сети»
5. Если выход к интернету доступен, то выберите «Настройки IP»
6. Нажмите на пункт «Настройки DNS» и выберите «Ввести вручную»
7. Выберите «Сервер DNS» и впишите 8.8.8.8 или 208.67.222.222. Нажмите «Готово», затем кнопку «Назад»
8. «ОК» для сохранения данных
9. Перезагрузите телевизор. Если с подключением к сети-интернет все в порядке, то попробуйте снова войти в приложение

Сброс настроек телевизора до заводских:

1. Нажмите на кнопку «Menu» на пульте
2. Затем выберите «Поддержка»
3. Выберите «Самодиагностика»
4. Нажмите «Сброс»
5. Далее введите PIN-код телевизора (если вы не задавали его самостоятельно, то по умолчанию пин-код 0000).

Переустановка приложения IVI:

  Переустановить приложение на Samsung можно только на сериях J, K, M, N, Q, LS (то есть 2015-2018 года выпуска) на OS Tizen.

1. Перейдите в панель приложений «APPS»
2. Выберите IVI
3. Нажмите и удерживайте центральную кнопку пульта или же нажмите кнопку «Tools»
4. В появившемся окне меню выберите пункт «Повторная установка»
5. Дождитесь установки. Время ее окончания зависит от скорости Вашего интернета.

Обновление прошивки телевизора

1. Нажмите кнопку «Menu» на пульте
2. Выберите «Поддержка»
3. Затем «Обновление ПО»
4. Выберите пункту «Обновить сейчас» или «По сети»
5. Если новая версия прошивки имеется и готова к установке, то появится оповещение об этом. Нажмите «Да»
6. Ожидайте завершение обновления. Не выключайте при этом телевизор

Сброс настроек Smart Hub

1. Выберите «Menu»
2. Выберите «Поддержка»
3. Далее «Самодиагностика»
4. «Сброс Smart Hub»
5. Введите PIN-код (по умолчанию 0000)
6. Ожидайте завершения операции

ИЛИ

1. «Menu»
2. Выберите «Функции Smart»
3. Далее «Сброс Smart Hub»
4. Введите PIN-код (по умолчанию 0000).
5. После того, как все настройки сбросятся необходимо установить корректное время, часовой пояс и дату. Переходим в Menu > Система > Время > Часы > Установка часов. Теперь, когда все данные заданы, войдите в Smart TV, в приложение IVI и проверьте его работу.

Опять же, во избежание блокировки Smart Hub перед сбросом убедитесь, что модель Вашего устройства сертифицирована для России, посмотрите на заводскую наклейку. Также, эту информацию можно узнать и в самом телевизоре.

Для этого проследуйте: Menu > Поддержка > Обращение к Samsung > в поле «Код модели» будет указан номер. Пример: UE32F6800. Латинская буква перед последними четырьмя цифрами и есть серия Вашего телевизора и указание на год выпуска.

Небольшой лайфхак для Вас:

A — 2008; 
B — 2009; 
C— 2010; 
D — 2011; 
ES/EH — 2012; 
F/FH — 2013; 
H/HU — 2014; 
J/JU/JS — 2015; 
K/KU/KS — 2016; 
M/MU/Q/LS — 2017; 
N/NU — 2018; 
S — премиум модели разных лет

Заключение

В этой статье мы основательно разобрали проблему и постарались ответить на вопрос, почему онлайн-кинотеатр IVI не работает на Вашем SMART TV. Если же все вышеперечисленные решения не помогают, то, вероятно, заминка произошла внутри самого приложения, у разработчиков сервиса. Вы можете обратиться с вопросом в техподдержку. Все контакты можно найти на официальном сайте IVI.RU

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

В любом случае, не расстраивайтесь и не нервничайте. Действуйте спокойно и рассудительно, и выход обязательно найдется. Приятного просмотра!

Для того чтобы подготовить видео к стримингу на большое количество типов устройств, нужно сделать несколько шагов — от подготовки метаданных до упаковки в разные контейнеры (MP4, DASH, HLS) с разным битрейтом. В Ivi.ru построили гибкую систему с приоритетами, которая учитывает потребности бизнеса в скорости подготовки видео и умеет работать с пятью DRM-системами. Архитектурное решение основывается на жонглировании Docker-контейнерами и включает в себя как аппаратные средства для кодирования видео, так и софтверные.  Подробно весь процесс и все тонкости работы с видео объяснил эксперт и технический директор ivi Евгений Россинский. Под катом — расшифровка его доклада с Backend Conf 2017.

О спикере
Евгений Россинский  — с 2012 года по сей день работает CTO ivi. Руководил компанией по разработке высоконагруженных проектов Netstream, плодами которой были проекты, связанные с online-вещанием и видео (smotri.com, ivi). С 2012 года Netstream вместе со всей командой был поглощен ivi.

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

Сначала я коротко познакомлю вас с нашим сервисом, чтобы вы понимали контекст, а потом уже перейдем к животно-сортирному юмору и различным подробностям.

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

1. Правообладатель отправляет нам либо ссылку, либо (в 10 % случаев эта система автоматизирована) по специальному протоколу мы забираем с их FTP ссылки на файлы оригиналов.

2. Специальный отдел Ingest (термин взят из телевидения) занимается подготовкой видео к передаче в Систему кодирования.

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

Отдел Ingest был реорганизован два года назад, когда мы всю это затеяли и выделили два типа специалистов:

• люди, которые действительно разбираются в кодировании видео, — и для них слова GOP и keyframe не являются пустым набором символов.
• операторы системы массового обслуживания под названием Система кодирования. У них есть баран, они кидают его в систему массового обслуживания, с другой стороны получают две палки колбасы. Нюхают колбасу – нормальная? – лей на prod.

Нашей задачей было сделать так, чтобы с ростом компании количество профессионалов, которые разбираются в видео, росло не сильно. Нужно было увеличивать число тех, кто «закидывает барана и получает две палки колбасы».

3. Из волшебного отдела Ingest видео попадает в Систему кодирования. Это уже наша вотчина, о которой я и расскажу.

4. После кодирования видео уходит на сервера Оriginals.

5. Дальше стандартная схема – видео раскладывается (с помощью магии или самостоятельно) на CDN и отправляется конечному пользователю.

Это простая классическая схема дистрибуции контента, начиная с серверов оригиналов и заканчивая CDN.

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

Какие у нас были проблемы

Или почему два года назад мы пришли к выводу, что надо что-то менять и сделать мир лучше, а не хуже.

• У нас были просто многокилометровые инструкции о том, как создать продакшн-среду для кодирования.

Мы любим ffmpeg, mp4box и прочее. Разработчик: «О, вышла новая версия, класс! Сейчас я быстренько ее соберу у себя! Блин, битрейт упал на 5%! Вообще огонь! Надо задеплоить!».
И тут начинается самое веселое – классическая проблема DevOps: у разработчика одна инфраструктура, на продакшн-серверах – другая. Начинается боль, содомия, кидание какашками, ненависть между отделами разработки и эксплуатации.

Можно много говорить – да, нужен DevOps и пр. Но на самом деле нет – люди всегда есть люди, они ненавидят друг друга. Поэтому надо дать сначала технологическую платформу, которая уберет противостояние.

• Вторая большая проблема – нам нужно было действительно сильно снизить требования к уровню вхождения операторов системы кодирования.

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

Например, год назад мы взяли на пробу индийский сериал – надо было вывалить быстро 10 000 тайпов. Все они в разном битрейте, какие-то самим правообладателем скачаны с торрента – полная содомия. И это все нужно было как-то обработать.

Когда у вас система, которая требует очень умного и понимающего человека, 10 тысяч тайпов не обработать так, чтобы качество было нормальным. Поэтому мы предприняли ряд шагов.

• Следующая проблема – для того, чтобы подготовить видео к стримингу, нужно пройти большое количество этапов, а значит, на каждом этапе вы можете облажаться – совершить ошибку.

Систему массового обслуживания нужно привести в чувство и эту самую задачу либо перезапустить, либо исправить и перезапустить, либо сказать: «ОК, это в принципе кодировать не можем».

• Следующая история – R&D.

Это вообще веселые ребята, которые просыпаются в районе ночи и начинают креативить.
На TechCrunch вышла какая-нибудь статейка типа «Израильский стартап выпустил новый кодек, который позволяет снизить битрейт видоса на 10%» Конечно же, надо попробовать! И внезапно получается: «Так, ОК, контактуем сейчас с израильским стартапом, из г*вна и палок лепим концепт, а теперь надо это все запустить в продакшн!».

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

• Дальше – зоопарк контейнеров, кодеков и DRM.

На самом деле, кодеков не очень большой зоопарк, а вот с контейнерами и DRM действительно огромный. Поскольку мы – легальный сервис, нам нельзя просто так взять и отдать прекрасный Dash или HLS, потому что нам просто этого не разрешают. Правообладатель говорит, например: «Ребята, фильм «Звездные войны» вы можете отдавать только на такой-то платформе и только в таком DRM».

DRM – это Digital rights management – штука, которая вроде бы защищает от скачивания и от возможности украсть аудио- и видеоконтент. Этих систем на самом деле несколько. Мы практически все популярные внедрили. Это, правда, боль и страдания.

Почему? Потому что по-хорошему ты не должен знать, как работает DRM – ведь это система защиты. Ты не имеешь права заниматься реверс-инжинирингом, но если этого не делать, эта ерунда не работает. Поэтому как тестировать и отлаживать работу DRM – это вообще отдельная песня.

Как результат, у нас появилось 52 различных конфигурации кодирования и пакетирования видеопотоков.

Например, есть старый телевизор LG, у которого представление об HLS очень специфическое. Если ты дашь ему честный, хороший, классный HLS, который проходит по всем стандартам, он играть его не сможет, хотя в доке у него написано, что может. Вообще у него ничего, кроме MP4, играть не получается – с соответствующими минусами для пользователя: время старта, буферизация и пр.

Поэтому для того чтобы играть на максимально большом количестве устройств, нам пришлось научиться либо генерировать эти форматы заранее, либо делать это на лету. Тут решают деньги – где нам это выгодно, а где нет. Об этом я чуть позже расскажу.

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

Например, нужно найти все видосы с keyframe в две сек. Зачем это может быть нужно, могу рассказать.

Например, нужно провести тест, насколько изменение длины чанка влияет на нагрузку на CDN и как это связано с алгоритмами кэширования. Эта информация нужна. Это – не жизненно важная история, без которой нельзя существовать, но очень полезная, если ты хочешь сделать эксплуатацию своего сервиса несколько более экономически эффективной.

Чтобы вы понимали: наша стоимость в шесть-семь раз дешевле, чем коммерческие предложения любого CDN. Там такие конские ценники закладывают. Но это бизнес, и он должен закладывать нормальную маржу. Поэтому система кодирования для нас – не пустой звук.

• Как и в случае с DevOps, есть большие проблемы с тестированием систем.

Первый, кто смотрит любые фичи перед тем, как мы катим это на prod, это QA-инженер. Он должен сначала прочитать многокилометровую инструкцию и затем у себя в кластере это поднять.
Вообще таски (фичи) по кодированию – самые сложные, потому что требуют большого времени. Тестировщик – тоже человек: он запустил что-то кодироваться и пошел бодренько пить чай. На этом у него контекст потерялся. Он вернулся – все упало – надо разбираться, что. Таких итераций много.

Два года назад время тестирования одной новой фичи в среднем занимало у нас две недели. Это было прям очень больно.

При том что на том же самом Web или на бэкенде мы гоним по 15-20 релизов в день. Это нормально.

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

• Стандартные проблемы с системой массового обслуживания большого количества потребителей.

У нас несколько департаментов пользуются системой кодирования. Это отдел контента, который забирает от правообладателя, и есть еще веселые ребята под названием «Реклама».
Поскольку мы – гордые и независимые – чтобы не садиться на чужие пилюли и иголки, запустили свою рекламную крутилку. Рекламщикам нужно уметь быстро выкатить тот или иной рекламный материал нашему пользователю.

Кто такой оператор кодирования

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

Что хотел бизнес? Бизнес хотел дешевых специалистов, которые все умеют и в восторге от рутинной, однотипной работы – просто прутся от нее!

Чего ждал технический департамент от специалиста по кодированию? Умения: «Ну, пожалуйста, сделай так, как на картинке!».

К чему мы шли?

• Хотели создать систему с низким уровнем вхождения для операторов.
• Для того, чтобы была возможность использования дешевых низкоквалифицированных сотрудников, которых по требованию можно подключать и отключать.
• Чтобы не увеличивать число дорогостоящих профессионалов – не настолько оправдано использование такого количества людей высокой квалификации.

Этапы подготовки видео

Этап #1

При поступлении видео к нам в систему в первую очередь проверяется сам оригинал — поскольку даже классные ребята, которые разбираются в том, как правильно закодировать видео, могут ошибаться.

• Битрейт.

По статистике предыдущей версии системы очень часты были случаи, когда, например, оригинал пришел в битрейте 1 Мбит, а оператор кодирования бодренько просит от системы: «Сделай мне, пожалуйста, из этого Full HD».

Это возможно – upscale никто не отменял. Система берет и делает эту штуку. На выходе получается: 1 большой квадрат бежит за другим большим квадратом, и на все это смотрит третий большой квадрат. Инженеры контроля качества видео смотрят на это и говорят: «Ребята, это г*вно!».

После n-го количества обращений специалистов контроля качества видеоотоков мы добавили проверку битрейта.

• Пропорции.

В нашей практике было два смешных случая, когда правообладатель прислал видео размером 2 х 480, и эти две полоски случайно выложились на prod. Собственно, после этих двух полосок у нас и появился человеческий отдел контроля качества, и мы еще на первом этапе смотрим пропорции, чтобы видеопоток хоть как-то мог поместиться в 9:16 или хотя бы 3:4. В крайнем случае, 1:20 — но не 1:480.

• FPS.

Проверку FPS (Frame per second – количество кадров в секунду в видеопотоке) мы ввели около полугода назад, когда стали экспериментировать с генерацией HLS на лету.

Контроль FPS нужен для того, чтобы в начале каждого чанка всегда находился опорный кадр. Если чанк четыре или две секунды, а FPS дробный, так или иначе опорный кадр от начала чанка куда-нибудь уедет.

Конечно, можно подгонять, делать неравнозначные чанки и прочее. Но когда вы делаете адаптивный стриминг, нужно это как-то синхронизировать. Поэтому более простые правила порождают более простую эксплуатацию и понимание, как это все работает.

7-10% нашего контента живут с дробным FPS, и это видео нельзя стримить в произвольные контейнеры. Сейчас у нас есть система, которая позволяет на лету нарезать MP4 в HLS, в Dash, еще и кодировать все это.

С дробным FPS получается плохо. Почему? Потому что в момент переключения на другой стрим начинает работать адаптивный стриминг. У пользователя затупил канал, надо быстренько переключиться на другой чанк. Он переключается на другой чанк, а там нет опорного кадра. Тогда на какое-то время у пользователя может развалиться картинка и появиться черный экран. Все зависит от того, как реализован кодек на клиентской стороне.

• Звуковые дорожки.

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

• Прочее.

Стандартный набор проверок, в том числе проверка размера файликов.

Этап #2

После того, как мы решили, что оригинал годен для последующей обработки, происходит его кодирование в нужный битрейт из одного файла в другой. Результирующий файл – MP4.

Этап #3

Дальше производится упаковка и, возможно, шифрование — если мы по каким-либо причинам хотим заранее упаковать видеопоток в тот или иной контейнер, чтобы потом отдавать с серверов original-статику. Статику всегда дешевле отдавать по нагрузке, но дороже хранить дополнительную копию битрейта.

Этапы #4-5

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

• Тривиальная проверка, нормально ли мы вообще донесли файлик с контентом до сервера оригиналов.

На самом деле тупо проверяем MD5 от потока, что нормально все скопировалось. Примерно раз в год вижу в логах историю о том, что донесли хреново – то есть это не придуманный случай.

• Дальше специально обученный человек смотрит во встроенном плеере (сначала в админке), как это все смотрится, соответствует ли текущему качеству то, что мы накодировали.

Этап #6

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

Этап #7

Наконец, специально обученный человек дергает рубильник и контент уходит к конечному потребителю: сервера Backend начинают раздавать ссылки именно на этот видеопоток.

Чем мы кодируем?

Самый большой кластер у нас – это ffmpeg плюс разный софт. Можно выделить два типа: Hardware и Software.

Мы берем ffmpeg и MP4, HLS и прочие боксы, и это закрывает 95% всех задач кодирования, которые мы выполняем. Однако для экономии времени и проведения экспериментов год-полтора назад мы купили пару сервачков от компании Elemental.

Это не реклама, они и вправду неплохие ребята. Эти серверы дороже, чем все наши железки, вместе взятые, но у них есть один плюс. Если тебе сложно что-то сварить с помощью ffmpeg или опенсорсного софта, ты можешь всегда обратиться в саппорт и сказать: «Ребята, у меня Smooth Streaming не работает, сделайте, чтобы работало!».

Они тебе это отправляют, а потом, если ты хочешь это масштабировать, просто тупо копируешь то, что они выслали и, либо вставляешь в софтверное решение, либо говоришь: «ОК, пусть это крутится на Elemental».

Сейчас у нас в продакшн Elemental используется только для одной штуки. Мы делаем контент с DRM PlayReady, который отдаем в HSS. HSS – это как раз Smooth Streaming – Майкрософтовская хрень, которая сейчас поддерживается не таким большим количеством устройств. Но, например, телевизоры Филипс, как и старые Самсунги и LG, очень любят его.

Все остальные платформы несколько быстрее догоняют. На Smart TV вообще проблема с обновлением прошивок. Они очень часто забрасывают старые телики и по железу, и по всему. Там с саппортом беда.

Но есть люди, которые хотят смотреть кино на старых моделях, и наша задача – как-то подружить ужа с ежом.

В итоге примерно 95% у нас уходит на софтверное кодирование и 5% – на кодирование и упаковку с помощью Elemental. И очень большой кусок связан с R&D, который тоже проводим на Elemental. Там все-таки скорости несколько выше, потому что напиханы GPU.

Например, истории с 4К и с HDR мы сначала запилили на хардварном решении.

Как это все работает внутри и как мы к этому пришли

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

Мы сделали:

• API;
• админку для разработчика, с помощью которой они могут разбираться со сложными случаями;
• админку для операторов кодирования;
• управление контейнерами;
• очень примитивную оркестрацию.

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

Как это работает (на пальцах)

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

• Мы загружаем туда через Puppet всю конфигурацию;
• Устанавливаем Cron, который раз в минуту проверяет, есть ли свободное место для того, чтобы запустить еще один контейнер;
• Дальше этот контейнер поднимается, смотрит, есть ли для него задания на кодирование, и выполняет их. На сервере есть расшаренная папочка, куда он кладет свои результаты, и, благополучно выполнив задачу, умирает, при этом поделившись логами с историей кодирования. Все очень просто.
• Потом по Cron’у просыпается новая штука, смотрит, есть ли что делать. Если есть, то бежит туда.

Работает бронебойно.

Что внутри контейнера?

Каждый контейнер последовательно запрашивает задачи нескольких типов:

• Сначала он говорит: «Друзья, есть ли что сделать именно по самому видео? Нужно ли мне в какой-то другой битрейт его перегнать?» И делает MP4.
• Откодировав MP4, он говорит: «Друзья, я сделал MP4, все хорошо. А может быть нужно упаковать в HLS?» На самом деле, это не обязательно тот самый MP4 — это может быть абсолютно любой другой MP4 с другим битрейтом.

• Дальше происходит аналогичная история с DASH и затем – с HDS.

Попробовав выполнить по одной задаче каждого типа, контейнер, благополучно сложив результаты своей работы, отмирает.

Внутри контейнера:

• Ubuntu,
• ffmpeg,
• ffprobe,
• mp4box.

Запуск этих волшебных вещей обернут Django, потому что так было проще на тот момент – можно было написать Shell-скрипты или  обернуть это все в Джанговские команды.

Интеграция с внешними сервисами

Дальше встал вопрос – а как к этому всему добру подключить внешние сервисы?
Тоже довольно просто. На самом деле контейнер имеет еще один отдельный тип – отправить задачку куда-то еще. Он по SSH тупо лезет на Elemental и смотрит, есть ли у него там ресурс, чтобы:

1. выкачать файл;
2. запустить задачку.

Если есть – прекрасно, он выкачивает файлик, ставит задачку на кодирование и асинхронно уходит ждать.

Дальше он в цикле периодически спрашивает у Elemental: «Есть что там, готово?». Если готово, опять wget’ом выкачивает уже обратно и кладет в общую папочку результаты кодирования.
Таким образом мы подключали несколько разных, очень простых RPC-сервисов (или не очень простых), чтобы интегрировать это в систему кодирования.

Приоритеты

Что дальше? А дальше это все выкатили в эксплуатацию и начали получать первые веселые отзывы.

Таким образом появилась такая интересная система приоритетов. Это все взято с реальных запросов, которые отправляли нам различные департаменты. Самым высшим назван приоритет «Внезапно».

Автор этой классификации – Володя Прохода – методично это все выписал и сейчас у нас действительно такая система приоритезации. И они в этом прекрасно разбираются! Они знают, что «Мне надо вчера» – это намного более важно, чем «Суперсрочно», «Суперсрочно» почему-то важнее, чем «Мегасрочно».

Собственно, какие пользователи, такие и запросы.

С приоритетами более-менее понятно, но их оказалось недостаточно. Почему? Потому что все, естественно, начали мочить «Внезапно» – ведь моя задача самая важная! А если еще бизнес пытается навесить KPI типа «Ты должен откодировать 20 видосов в час!», и ты думаешь: «Да, конечно, мне же надо! Внезапно! Давай! Горшочек, вари!».

У всех однозначно появилось «Внезапно»!

К чему это привело? К тому, что действительно важные задачи стали тупо ждать ресурсов. На самом деле можно было совершенно спокойно видео, которое нужно только через 4 месяца на продакшн, поставить с обычным приоритетом. Оно бы все равно за ночь откодировалось. Но пока люди сидят в офисе, им же нужно шампуры переворачивать и говорить, что у тебя подгорело.
Поэтому у нас появились маршруты.

Маршруты

Что это такое? По сути мы отгородили в своих вычислительных мощностях пространства, куда может ходить только определенный департамент.

Действительно срочных задач немного:

• трейлеры,
• реклама,
• горячие премьеры.

В этом году мы довольно часто выкладываем сериалы до эфира (catch-forward). Народ дрючит наш саппорт – когда же следующая серия «Отеля Эллион!? Я уже не могу ждать!» Там действительно время идет! Вы будете смеяться, но это правда. Я уже не говорю про популярность сериала «Сваты-6».

Поэтому горячие премьеры, особенно catch-forward или catch-up (сразу после телеэфира), надо выгружать быстро.

С рекламщиками еще хуже, потому что можно посчитать, сколько стоит получасовая или часовая задержка при таком большом количестве пользователей. Эти деньги – упущенная выгода компании.

Как только в спор между разными подразделениями встает бабло, люди перестают быть людьми и достают топор войны – кровь, слезы и сопли.

Поэтому мы сделали резервации, куда можно ходить, а куда ходить нельзя, и назвали их маршрутами.

На самом деле срочных задач действительно не очень много. Если в день приходит несколько супергорячих премьер и 20 рекламных роликов, то одна железка справляется с этим. Они, в принципе, друг с дпугом не конфликтуют. А все основные вещи совершенно спокойно могут решаться приоритетами.

Выделив отделу контента для премьер и трейлеров отдельный загончик, а рекламщикам – отдельную историю, мы достигли того, что они смогли более-менее неплохо договариваться и вести диалог. Мне так кажется, но они, может быть, считают по-другому.

Служба эксплуатации, когда к ней приходят с чем-то новым, всегда встречает это в штыки, потому что ее девиз «Не тронь технику, и она тебя не подведет!».

Как только приходит что-то новое, это значит, что тебе нужно меняться. Изменения всегда происходят через боль – человечество другого пока не придумало.

Поэтому мы хотели истории с виртуализацией, с докерами запустить несколько шире, чем только систему кодирования. Пошли двумя путями:

1. Мы попытались внедрить Kubernetes для того, чтобы тестовые кластеры для наших QA-инженеров работали на нем.
2. Нам нужна была оркестрация.

Это было два года назад. Полгода мы люто бились головой о стену, пытаясь решить те проблемы, которые «…вот-вот, через три месяца, сейчас мы зарелизим и все будет хорошо!». Это я про инженеров Kubernetes.

Готовясь к докладу, я посмотрел, какие изменения произошли там за два года. Да, действительно порядка 70% наших проблем закрыты. Сейчас можно этим всем уже, наверное, пользоваться, но мы уже убили полгода, и следующий виток, я думаю, будет через полгода-год.

Но при этом нам очень понравилась история как раз с Docker-контейнерами – простота, с которой можно завернуть нужную тебе конфигурацию, причем абсолютно без конфликта между отделом эксплуатации и отделом разработки.

У нас есть специальные DevOps-инженеры, которые помогают людям скрещивать ужа с ежом. Хотя в принципе заюзать Docker-контейнер получается довольно просто.

Но Kubernetes нас доканал. Человек, который его внедрял, приуныл, и через полгода уволился потому, что делаешь, делаешь, вроде бы, по документации все хорошо, и мысли у тебя правильные, и направление тоже, но горшочек не варит!

А через месяц после того, как мы решили, что не будем делать Kubernetes, один из наших разработчиков написал очень простую систему оркестрации, как раз для решения локальной проблемы поднятия тестового кластера для тестировщиков.

Kubernetes решает все-таки более глобальные проблемы – как на продакшене все это делать, а не только на тестовом кластере. Да, у меня была мечта ломануться с этим на продакшн, но сначала была идея первого шага – сделать тестовую инфраструктуру.

Оказалось, что тестовую инфраструктуру намного проще сделать без помощи сложной системы оркестрации, хотя я ни в коем разе не критикую путь Kubernetes. Он правильный, просто на тот момент, когда мы начали, было еще очень сыро.

Чего нам удалось добиться?

• Во-первых, действительно простоты в эксплуатации.

Docker-контейнеры собираются довольно быстро – за несколько секунд.

• Мы получили очень хорошие возможности масштабирования.

Есть вычислительные мощности – поднимаешь туда все, что тебе нужно, с помощью Puppet, и все работает быстро.

• Очень важно для нас подробное логирование всех этапов обработки видео.

Снизилось количество обращений от отдела Ingest в отдел разработки. Мне важно, чтобы разработчики занимались разработкой, а не саппортом. Сейчас, наверное, максимум раза два в месяц кто-то из программистов смотрит, что произошло с той или иной задачкой, что идет не так. При этом, как правило, они не лезут в код, а используют специальную админку.

Мне, как техническому директору, стало несколько спокойнее жить, потому что люди не перекладывают бумажки из одного ящика в другой, а делают доброе, светлое, вечное… или нет.

• Возможности подключать внешние сервисы

Попробовали на примере Elemental и, например, яблочного упаковщика в HLS подключать внешние сервисы.

• За 2016 год несколько раз (4, 5, 6 – точно не помню) перекодировали полностью каталог.

Это нужно как раз для оптимизации работы CDN, чтобы адаптивный стриминг лучше шурупил. До создания этой системы вопрос перекодирования всего каталога мог занимать от полугода до года. У нас действительно много видео!

Сейчас, я думаю, на тех мощностях, которые есть, можно справиться за полтора-два месяца. Вопрос только: зачем?

При этом совершенно спокойно можно арендовать облачко, главное, чтобы это облачко было где-то недалеко от тебя, потому что как-то к нам пришел Амазон и сказал:

— Смотрите, классическая задача – давайте, поднимете у нас…
— А у вас в России что-то есть?
— Так, чтобы к вам близко, нет.
— Смотрите, у нас два Pb оригиналов. Нам нужно, условно говоря, перегнать их туда, а потом забрать. Сколько мы вам за трафон заплатим?
— Ну, да… В России поднимемся, придем.

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

• QA теперь в принципе умеет тестировать

Действительно, две недели на тестирование и проверку качества любой новой фичи в системе кодирования, которые я описывал раньше, – это адо-содомия. Просто на корню зарубает все желание получать какие-то фичи от этой системы.

А сейчас день-два, если совсем геморрой – три-четыре. Плюс – понятно, как это делать. Тестировщик не занимается инфраструктурными проблемами. Он не ходит вокруг девопсера, не говорит: «Блин, у меня вот то же самое не работает, почему?». Сейчас (по крайней мере, я на это надеюсь) тестировщики перестали бояться брать на себя задачки по контролю качества системы кодирования.

В ответах на вопросы после доклада зачастую содержатся самые интересные фишки и любопытные детали, поэтому мы собрали их тут

Также мы открыли доступ ко всем видеозаписям выступлений с Backend Conf 2017 и HighLoad++ Junior.

Экспертов и профессионалов мы приглашаем стать спикерами на майском фестивале конференций РИТ++. Если у вас есть интересный опыт разработки и вы готовы им поделиться, оставьте заявку для нашего программного комитета.