Запись телепередач¶

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

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

Запись идет всех видеокачеств и вместе с ними так же и скриншоты.

По API можно запросить список телепередач на нужный канал и если middleware отвечает на нужный запрос в протоколе config-external, то Catena SE вернет ответ с передачами в которых будет заполнено поле статуса записи.

Архитектура записи архива¶

Архив пишется после транскодера¶

Архив в Catena SE пишется после транскодера: на диск сохраняется уже подготовленное для доставки видео (все качества/дорожки, которые вы настроили в темплейте).

Это важно по двум причинам:

архив сразу пригоден к проигрыванию на клиентских устройствах (Smart TV / STB / mobile) без повторной обработки;
нагрузка и требования к хранилищу считаются по фактическому выходному набору профилей (MBR), а не по “сырым” входным потокам.

Хранилище: только локальные диски + репликация между серверами¶

Catena SE пишет архив строго на локальные диски серверов.

Мы не используем NFS, дисковые полки/SAN и другие общие сетевые хранилища: они добавляют сложность и часто ухудшают предсказуемость задержек и надёжность.

Рекомендуемая модель хранения:

много недорогих отдельных дисков (обычно HDD) под большой объём архива;
репликация архива между серверами кластера, чтобы переживать отказ отдельного диска/сервера;
конфигурация дисков и точек монтирования задаётся при добавлении сервера (см. Добавление нового сервера).

SSD cache для массового проигрывания архива¶

Чтобы обслуживать большое количество одновременных зрителей, Catena SE использует подход “много архива на HDD, самое горячее — на SSD”.

Типовой сценарий:

основной объём архива хранится на локальных HDD;
наиболее часто запрашиваемые фрагменты (например, “последние часы” или “прайм-тайм”) попадают в SSD cache;
это позволяет резко увеличить количество параллельных проигрываний без раздувания стоимости хранения всего архива на SSD.

Как это обычно используется в IPTV (catchup TV)¶

Задачи, которые чаще всего хотят реализовать поверх архива:

поставить прямой эфир на паузу и продолжить с того же места
посмотреть текущую передачу с начала (startover)
посмотреть вчерашнюю передачу по EPG
сохранить “прогресс” и продолжить просмотр позже

Технически эти сценарии проще всего решаются в RTSP, но в IPTV/OTT в основном используются сегментные HTTP-протоколы (HLS, DASH, и иногда MSS), поэтому для паузы/перемотки и “startover” используются специальные URL и плейлисты.

Время и идентификаторы передач¶

В этой документации время передачи рассматривается только как Unix timestamp в секундах UTC (Epoch).

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

Рекомендуется при просмотре передачи сохранять текущее положение (UTC timestamp или offset) в базе middleware, чтобы при повторном открытии предлагать “продолжить” или “начать сначала”.

Проигрывание передачи из архива по EPG (VOD-плейлист)¶

Если middleware хранит расписание EPG, то у каждой передачи есть:

from — время начала в UTC (epoch)
to — время конца в UTC (epoch)

Длительность передачи вычисляется как (duration = to - from).

Для проигрывания передачи из архива сформируйте URL по правилам из статьи Проиграть ТВ канал.

Пример для HLS:

https://<hostname>/lb/-/<channel>/archive-<from>-<duration>.m3u8

Пример для DASH:

https://<hostname>/lb/-/<channel>/Manifest-<from>-<duration>.mpd

В плеере при таком доступе обычно работают:

перемотка внутри передачи
пауза
ускоренный просмотр

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

Просмотр текущей передачи: event-плейлисты и “пауза лайва”¶

Для “startover” и паузы текущей передачи удобно использовать тот же URL, что и для архива, но так, чтобы конец окна попадал в “настоящее” или в будущее.

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

Если ваша клиентская платформа позволяет, используйте тот же URL, что и для архива, добавив параметр event=true:

https://<hostname>/lb/-/<channel>/archive-<from>-<duration>.m3u8?event=true

Где from и duration соответствуют текущей передаче по EPG.

Важное замечание про кнопку “live”¶

Кнопку “live” почти всегда нужно программировать отдельно.

Пока пользователь стоит на паузе, ситуация может измениться:

плейлист EVENT может со временем превратиться в VOD (окно “закроется”);
плеер может перестать обновлять плейлист;
при переходе передачи плейлист для “текущей” передачи закончится.

В этом случае нужно:

по EPG определить текущую передачу,
пересобрать URL на актуальный период,
либо перепрыгнуть на следующий элемент EPG.

Ограничения платформ¶

Event-плейлисты и перемотка “внутри текущей передачи” могут иметь ограничения на отдельных платформах (например, в нативном Safari).

Если для вас критичны такие платформы, закладывайте отдельную реализацию таймлайна/перемотки в приложении (обычно на JavaScript/в нативном SDK) поверх тех же EPG данных и URL.