IPTV и OTT

Как развивались IPTV и OTT

По мере развития телевидения через сети передачи данных потребовались общие правила совместимости оборудования и услуг. После консультаций ITU, состоявшихся в апреле 2006 года, была создана рабочая группа по IPTV. Она координировала разработку международных стандартов и завершила работу в январе 2008 года; стандартизацию продолжили другие структуры ITU. ^[7] В марте 2009 года была утверждена первая редакция H.721 о базовой модели IPTV-терминала; последующие редакции датированы 2015 и 2022 годами. ^[3]

Другую сторону развития показывает HTTP Live Streaming, сокращённо HLS: способ потоковой передачи через HTTP, протокол обмена данными в вебе. Первый проект его описания опубликован в 2009 году, а в августе 2017 года появился RFC 8216 с описанием седьмой версии протокола. ^[4] Это вехи конкретного способа доставки, а не даты рождения OTT.

К 2019 году отношения между интернет-приложениями и операторами сетей получили отдельное описание в ITU-T D.262. Документ связывает развитие OTT с распространением широкополосного доступа и подключённых устройств. Его определение охватывает не только видео, а примечание допускает различия национальных определений. ^[2]

Как видео доходит до зрителя

В модели IPTV сеть организована так, чтобы поддерживать требуемые характеристики услуги. Управление доставкой входит в само определение, но слово IPTV не обещает отсутствия любых сбоев. ^[1] В H.721 отдельно описаны роли поставщика сети и поставщика услуги: они могут принадлежать одной организации, а могут быть разделены. ^[3] Поэтому вопрос «кто отвечает за качество?» полезнее предположения, что всё обязательно делает одна компания.

В OTT приложение и подключение к интернету рассматриваются как разные составляющие, хотя они зависят друг от друга. Поставщик видеосервиса предоставляет содержание и возможности просмотра, а получить их пользователь может только при работающем подключении. Такое разделение и взаимозависимость отражены в D.262. ^[2]

На уровне передачи данных можно использовать HLS. Сначала проигрыватель получает плейлист — текстовое описание того, какие части видео надо загрузить. Медиаплейлист перечисляет сегменты, то есть последовательные фрагменты записи или передачи. Проигрыватель скачивает их и воспроизводит по порядку; при продолжающейся трансляции обновляет плейлист, чтобы узнать о новых фрагментах. ^[4]

Главный плейлист может перечислять несколько вариантов одного содержания. Они различаются, например, битрейтом — количеством передаваемых битов в секунду — и разрешением изображения. Проигрыватель выбирает вариант с учётом условий сети. ^[4] Это и есть адаптация: меняется представление видео, чтобы продолжить просмотр. Она не превращает медленное соединение в быстрое и не определяет сама по себе, относится услуга к IPTV или OTT.

Доставка, режим просмотра и устройство

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

При линейном телевидении зритель следует текущей последовательности программы. В режиме видео по запросу, или VoD (video-on-demand), он выбирает материал и управляет его просмотром. H.721 предусматривает оба режима для IPTV-устройств. ^[3] Следовательно, выбор фильма из каталога не доказывает, что перед нами OTT, а наличие приставки не доказывает IPTV.

Учебный пример. Семья смотрит вечерние новости через управляемую телевизионную услугу, а затем открывает интернет-приложение на том же телевизоре. Экран и канал могут совпасть, но описание доставки будет другим. Если в первом сервисе есть архив передач, это ещё не повод переклассифицировать всю услугу: архив относится к способу выбора содержания.

Как это используют на практике

Российский пример коммерческого употребления термина — «Смотрёшка»: компания «ЛайфСтрим» называет её OTT-сервисом. ^[5] Это самоописание поставщика; по нему нельзя сравнивать фактическое качество разных сервисов. Международные технические документы H.721 и RFC 8216, в свою очередь, дают проверяемое описание устройств и передачи, но не заменяют условия конкретного договора. ^{[3, 4]}

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

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

Как проверить качество и расход данных

Для приёмки можно вести простой журнал наблюдений. Время запуска — интервал от команды воспроизведения до первого устойчивого показа. Отдельно записывают остановки во время просмотра, смену качества, работу звука и субтитров. Это предлагаемая процедура проекта; допустимые значения следует согласовать заранее, а не выдавать за единые нормы всех IPTV- и OTT-сервисов.

Учебный расчёт расхода. Пусть общий медиапоток имеет постоянный битрейт 4 Мбит/с и просмотр длится один час. В часе 3600 секунд, в байте восемь битов. Объём равен скорости, умноженной на время и делённой на восемь: 4 × 3600 / 8 = 1800 МБ, или 1,8 ГБ при десятичном счёте единиц. Здесь учитываются только данные заданного медиапотока: служебный обмен и повторные загрузки исключены.

Если проигрыватель переключает варианты, постоянного битрейта уже нет: нужно учитывать время на каждом из них. Возможность таких переключений описана в HLS. ^[4] Нулевое время просмотра даёт нулевой объём в учебной модели, но ничего не говорит о служебном обмене приложения.

Другой учебный пример: девять из десяти попыток запуска дали устойчивое изображение не позднее согласованного порога. Доля успешных запусков равна 9 / 10 × 100% = 90%. При нуле попыток доля не определена. Эти десять наблюдений описывают тест; они не доказывают, что услуга доступна 90% времени за месяц. Запуски и длительность доступности — разные величины.

Ограничения и типичные ошибки

Сравнивать услуги только по скорости домашнего тарифа недостаточно: в тесте нужно проверить фактический просмотр. Адаптация HLS позволяет менять вариант потока, но её наличие не подтверждает качество на конкретном устройстве. ^[4] Паузы, изображение и звук следует оценивать в тех условиях, для которых проект предназначен.

Другая ошибка — связывать технологию с оплатой. Определение OTT в D.262 описывает приложение и доставку, а не обязательную подписку. ^[2] Способ продажи, режим просмотра и устройство рассматривают отдельно. Для спорного коммерческого названия лучше запросить описание услуги, чем выводить технические свойства из рекламного ярлыка.

Правовой аспект в России

Статья 1270 ГК РФ различает способы использования произведения: в частности, воспроизведение, сообщение в эфир или по кабелю, ретрансляцию и доведение до всеобщего сведения. Использована часть IV в редакции от 23.07.2025 с изменениями, действующими с 04.01.2026, пункт 1 и подпункты 1, 7, 8, 8.1, 11 пункта 2. ^[6]

Из этого следует практическое различие: работающая ссылка или плейлист показывают техническую возможность получения видео, но не объём предоставленных прав. Для проекта нужно отдельно определить предполагаемое использование и проверить договорные основания. Квалификацию конкретной услуги и применимые специальные требования разбирают с юристом; технические названия IPTV и OTT такого разбора не заменяют.

Частые вопросы

Связанные термины

• kabelnoe-televidenie
• onlayn-kinoteatr
• litsenziya-na-veshchanie
• cdn
• teleprogramma
• tsifrovoy-multipleks