live-common: Kaltura Media Framework Общий Модуль NGINX

Установка на Debian/Ubuntu

Эти документы применимы к пакету APT nginx-module-live-common, предоставляемому репозиторием GetPageSpeed Extras.

Настройте репозиторий APT, как описано в настройке APT-репозитория.
Установите модуль:

sudo apt-get update
sudo apt-get install nginx-module-live-common

Показать наборы и архитектуры

| Дистрибутив | Набор             | Компонент   | Архитектуры   |
|-------------|-------------------|-------------|-----------------|
| debian      | bookworm          | main        | amd64, arm64    |
| debian      | bookworm-mainline | main        | amd64, arm64    |
| debian      | trixie            | main        | amd64, arm64    |
| debian      | trixie-mainline   | main        | amd64, arm64    |
| ubuntu      | focal             | main        | amd64, arm64    |
| ubuntu      | focal-mainline    | main        | amd64, arm64    |
| ubuntu      | jammy             | main        | amd64, arm64    |
| ubuntu      | jammy-mainline    | main        | amd64, arm64    |
| ubuntu      | noble             | main        | amd64, arm64    |
| ubuntu      | noble-mainline    | main        | amd64, arm64    |

Распределённая система для стриминга живого видео. Система состоит из множества компонентов, каждый из которых отвечает за конкретную функцию.

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

Медиа передается между различными компонентами внутри системы, используя пользовательские протоколы - 1. Kaltura Media Protocol (KMP) - протокол на основе TCP для доставки потокового медиа, концептуально аналогичный одной дорожке fMP4/MPEG-TS 2. Kaltura Segmented Media Protocol (KSMP) - протокол на основе HTTP для доставки медиа в сегментах, концептуально является супersetом LLHLS/DASH

Оркестрация различных медийных компонентов осуществляется "контроллером". Основная задача контроллера - построение топологии медиа-потока и обновление её в случае сбоев. Контроллер получает события JSON от медиакомпонентов, отправленные в виде HTTP-POST. В дополнение ко всему, все компоненты обработки медиа предоставляют REST API на основе JSON, который используется контроллером для получения последнего статуса и совершения действий. Пример реализации контроллера для единого сервера предоставлен в папке conf.

Основные функции

Протоколы публикации: RTMP, MPEGTS (через SRT/HTTP/TCP)
Протоколы воспроизведения: HLS/LLHLS, DASH
Протоколы живой передачи/ретрансляции: RTMP
Транскодирование видео/аудио - включая поддержку GPU, основанное на API ffmpeg
Сохранение - в объектном хранилище S3 (или совместимом)
Доставка с адаптивным битрейтом
Поддержка субтитров - включая преобразование 608/708 в WebVTT
Альтернативный аудио-трек
Шифрование медиа и DRM
Захват видеофреймов

Начало работы

Папка conf содержит пример кода и конфигурации для работы с единым сервером.

Глоссарий

Канал - контейнер, представляющий поток в реальном времени, может содержать дорожки, варианты, временные шкалы и т.д.
Дорожка - единичный рендеринг видео/аудио/субтитров. Например, у канала может быть 3 видео-дорожки: 1080p, 720p, 540p.
Вариант - группа дорожек, используемая для упаковки. Варианты определяют, какой аудиотрек будет сопоставлен с каждой видеодорожкой, когда используются мультиплексированные сегменты. Вариант может ссылаться на несколько дорожек, но не более одной дорожки на каждый тип медиа. Дорожки должны быть связаны с вариантами, чтобы их можно было доставить через HLS/DASH.
Сегмент - группа кадров определенной дорожки. Сегменты всегда независимы - видео-сегменты всегда начинаются с ключевого/IDR кадра.
Индекс сегмента - номер, который идентифицирует сегменты различных дорожек, ассоциированные с определенным временным интервалом.
Период - набор индексов сегментов, которые могут воспроизводиться непрерывно.
Временная шкала - набор периодов. Можно создать несколько временных шкал, каждая со своим набором периодов. Временные шкалы могут использоваться, например, для реализации "режима предварительного просмотра" - издатель использует одну временную шкалу, а зрители - другую. Временная шкала издателя всегда активна, в то время как временная шкала зрителей активируется по усмотрению издателя.

Примерные топологии

Ниже приведены диаграммы, демонстрирующие несколько примерных топологий, которые могут быть созданы с помощью компонентов Media-Framework.

Простой RTMP-прокси

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Прокси + S3 Сохранение

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    s3(Amazon S3);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|HTTP|s3;
    s3-->|HTTP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Входной SRT + Транскодирование видео

flowchart LR;
    enc(Encoder);
    ingest(nginx-mpegts-kmp-module);
    srt(nginx-srt-module);
    trans(transcoder);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|SRT|srt;
    srt-->|MPEG-TS|ingest;
    ingest-->|KMP видео|trans;
    trans-->|KMP видео|live;
    ingest-->|KMP аудио|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Декодирование закрытых субтитров

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    cc(nginx-cc-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP видео|cc;
    cc-->|KMP субтитры|live;
    ingest-->|KMP видео|live;
    ingest-->|KMP аудио|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Транскодирование + RTMP Push

flowchart LR;
    enc(Encoder);
    ingest(nginx-mpegts-kmp-module);
    trans(transcoder);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    push(nginx-kmp-rtmp-module);
    yt(YouTube);
    play(Player);
    enc-->|MPEG-TS/HTTP|ingest;
    ingest-->|KMP|trans;
    trans-->|KMP|live;
    trans-->|KMP|push;
    push-->|RTMP|yt;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Обзор компонентов

Медиа-компоненты

nginx-rtmp-kmp-module - потоковая передача живого медиа, вход: RTMP, выход: KMP x N
nginx-mpegts-kmp-module - потоковая передача живого медиа, вход: MPEG-TS через TCP/HTTP, выход: KMP x N
transcoder - транскодирование видео/аудио, вход: KMP, выход: KMP x N
nginx-live-module - сегментатор живого медиа, вход: KMP x N, выход: KSMP

Дополнительные функции: сохранение, заполнитель, поддержка временной шкалы.
nginx-pckg-module - упаковщик живого медиа (без состояния), вход: KSMP, выход: HLS/LLHLS, DASH

Дополнительные функции: адаптивный битрейт, субтитры, альтернативное аудио, шифрование медиа / DRM, захват видеофреймов
nginx-kmp-cc-module - декодер закрытых субтитров, вход: KMP видео (h264/5), выход: KMP субтитры (WebVTT) x N
nginx-kmp-rtmp-module - ретрансляция живого медиа, вход: KMP x N, выход: RTMP

Важно: Все компоненты на основе nginx с состоянием (= все, кроме nginx-pckg-module) должны быть развернуты на одном сервере nginx с одним процессом (worker_processes 1;). Состояние модуля хранится на каждый процесс, и при использовании нескольких процессов невозможно контролировать, какой процесс получит запрос. Например, запрос на создание канала на сегментаторе может поступить на рабочий процесс 1, тогда как соединение KMP с фактическими медиаданными попадет на рабочий процесс 2. В развертываниях, использующих контейнеры, это не должно быть проблемой - несколько контейнеров могут быть развернуты на одном сервере, вместо использования нескольких процессов nginx. Еще одной возможностью является использование патча, подобного патчу arut per-worker listener, но, вероятно, его придется обновить, чтобы он применим также к stream соединениям.

Опции отладки

Некоторые компоненты Media-Framework поддерживают дополнительные макросы препроцессора для целей отладки - - NGX_LBA_SKIP (nginx-common) - Пропускает использование модуля "Large Buffer Array" (LBA). Когда включено, выделения LBA перенаправляются на ngx_alloc / ngx_free. - NGX_RTMP_VERBOSE (nginx-rtmp-module) - Включает дополнительные сообщения отладочного журнала - NGX_LIVE_VALIDATIONS (nginx-live-module) - Включает проверки согласованности во время выполнения на внутренних структурах данных, включено по умолчанию при использовании --with-debug - NGX_BLOCK_POOL_SKIP (nginx-live-module) - Пропускает использование пулов блоков. Когда включено, выделения блока перенаправляются на ngx_palloc / ngx_pfree.

Для тестирования модулей с помощью valgrind рекомендуется применить патч no-pool-nginx, и настроить nginx с параметрами --with-cc-opt="-O0 -DNGX_BLOCK_POOL_SKIP -DNGX_LBA_SKIP" и --with-debug.

Протокол Kaltura Media (KMP)

Протокол Kaltura Media является простым пакетным протоколом для потоковой передачи медиа через TCP. Соединение KMP может передавать медиа одной дорожки видео/аудио/субтитров - когда требуется несколько дорожек, устанавливаются несколько TCP соединений.

Каждый пакет начинается с заголовка, который содержит следующие поля (по 32 бита каждое) - - Тип - тип пакета. Типы пакетов представляют собой коды из четырех символов, см. ниже список в настоящее время определенных типов. - Размер заголовка - размер заголовка пакета, должен быть между sizeof(kmp_packet_header_t) и 64KB. Парсеры должны использовать размер заголовка, чтобы получить доступ к данным пакета, это позволяет добавлять новые поля в заголовки пакетов без нарушения работы существующих парсеров. - Размер данных - размер данных пакета, должен быть между 0 и 16MB. - Резервный - зарезервировано для будущего использования, должно быть равно 0.

Структуры и константы, используемые в KMP, можно найти в ngx_live_kmp.h.

Идентификаторы кадров KMP

Идентификатор кадра - это 64-битное целое число, которое уникально идентифицирует входной кадр. Модули инжекции (nginx-rtmp-kmp-module / nginx-mpegts-kmp-module) выделяют начальный идентификатор кадра в соответствии с часами сервера (в единицах временной шкалы), когда создается выходная дорожка. Чтобы избежать необходимости отправлять идентификатор кадра с каждым кадром, который отправляется, идентификаторы кадров в KMP являются последовательными - идентификатор N-го кадра, отправленного по соединению KMP, равен initial_frame_id + N.

Если входное соединение (например, RTMP) обрывается и восстанавливается, будут выделены новые идентификаторы кадров KMP. Поскольку значение временной шкалы высоко (90 кГц), а частота кадров, вероятно, не превышает 60fps, даже в случае повторного подключения после короткого периода потоковой передачи, начальный идентификатор кадра будет значительно выше, чем последний отправленный идентификатор кадра в предыдущем соединении. Таким образом, крайне маловероятно, что возникнет конфликт с любыми ранее использованными идентификаторами кадров из-за повторного подключения.

Идентификаторы кадров используются: - Для идентификации кадров, которые подтверждаются в KMP ack пакетах - Для пропуска ранее обработанных кадров, если соединение KMP восстанавливается

Транскодер добавляет некоторые сложности к управлению идентификаторами кадров - - Поскольку транскодер может изменять входную частоту кадров или пропускать кадры, идентификаторы кадров во входе транскодера не обязательно совпадают с идентификаторами кадров в выходе транскодера. Если транскодер перезапускается, он должен знать, какое значение отправить в качестве initial_frame_id своего вышестоящего сервера (обычно nginx-live-module). Для этой цели используется поле upstream_frame_id. - Транскодер может быть настроен на изменение частоты дискретизации аудиотрека, и в этом случае транскодированные кадры не совпадают с входными кадрами. Чтобы справиться с этой ситуацией, транскодер должен иметь возможность подтверждать только часть входного кадра. Для этого предназначено поле offset - оно может хранить, например, количество аудиосемплов, которые должны быть подтверждены в кадре. Точное значение поля offset определяется приемником KMP - приемник устанавливает offset в кадрах ack, которые он возвращает, и получает его обратно в поле initial_offset пакета подключения в случае повторного подключения.

Пакеты KMP отправителя

Ниже перечислены пакеты KMP, которые могут быть отправлены отправителем KMP.

Подключение (`cnct`)

Отправляется сразу после установления TCP-соединения KMP.

Заголовок содержит следующие поля: - channel_id - строка, идентификатор канала, который публикуется. Максимально допустимая длина - 32 символа. - track_id - строка, идентификатор дорожки, который публикуется. Максимально допустимая длина - 32 символа. - initial_frame_id - целое число, идентификатор первого отправляемого кадра. - initial_upstream_frame_id - целое число, начальный идентификатор кадра, который должен быть отправлен вышестоящему серверу (используется транскодером) - initial_offset - целое число, смещение для начала, в пределах начального кадра. - flags - целое число, битовая маска флагов, в данный момент определен только один флаг - consistent - этот флаг устанавливается, когда отправитель KMP генерирует согласованный (битовый) выход, при идентичном входе. nginx-rtmp-kmp-module и nginx-mpegts-kmp-module являются примерами отправителей, которые согласованы. В то время как транскодер не является таковым. Флаг consistent используется LL-сегментатором в случае повторного подключения. Когда отправитель согласован, LL-сегментатор может продолжить с того места, где остановился. Когда отправитель несогласован, LL-сегментатор может продолжить только с следующего GOP - он не должен смешивать частичный GOP до отключения с GOP, полученным после отключения.

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

Информация о медиа (`minf`)

Содержит параметры медиа. Некоторые поля в заголовке являются общими для всех типов медиа, тогда как остальные определены только для конкретного типа (объединение).

Общие поля заголовка: - media_type - целое число, тип медиа - video / audio / subtitle, использует константы KMP_MEDIA_XXX. - codec_id - целое число, идентификатор кодека, использует константы KMP_CODEC_XXX. - timescale - целое число, единицы, используемые в полях dts / pts_delay / created кадра, в Герцах. - bitrate - целое число, битрейт, в битах в секунду.

Специфические для видео поля заголовка: - width - целое число, ширина видео, в пикселях. - height - целое число, высота видео, в пикселях. - frame_rate - рациональное, частота кадров видео, в кадрах в секунду. - cea_captions - булевое значение, устанавливается в 1, когда видеодорожка содержит субтитры EIA-608 / CTA-708.

Специфические для аудио поля заголовка: - channels - целое число, количество аудиоканалов. - bits_per_sample - целое число, размер аудиосемплов, в битах. - sample_rate - целое число, частота дискретизации аудио, в выборках в секунду. - channel_layout - целое число, битовая маска позиций каналов, использует константы KMP_CH_XXX.

Данные пакета информации о медиа содержат приватные/дополнительные данные кодека. Например, когда используется кодек h264, данные содержат тело MP4 блока avcC.

Приемники KMP должны обрабатывать изменения информации о медиа, например, изменение разрешения видео. Тем не менее, тип медиа (видео/аудио/субтитры), который отправляется в соединении KMP, не должен изменяться.

Приемники KMP должны игнорировать пакеты информации о медиа, когда они идентичны ранее полученному пакету информации о медиа.

Кадр (`fram`)

Представляет собой единичный видео кадр / аудио кадр / подсказку субтитров.

Заголовок кадра содержит следующие поля: - created - целое число, время, в которое кадр был получен первым модулем Media-Framework в канале, в единицах временной шкалы. - dts - целое число, временная метка декодирования кадра, в единицах временной шкалы. Когда тип медиа является subtitle, содержит начальную временную метку подсказки. - flags - целое число, в данный момент определен только один флаг - key - включен для ключевых кадров видео. - pts_delay - целое число, разница между временной меткой презентации кадра и временной меткой декодирования, в единицах временной шкалы. Когда тип медиа - это subtitle, содержит продолжительность подсказки - end_pts - start_pts.

Когда тип медиа - видео / аудио, данные пакета кадра содержат сжатую медиа. Когда тип медиа - это субтитры, а кодек - WebVTT, данные кадра следуют формату образца WebVTT, как указано в ISO/IEC 14496-30 (обычно в этом случае образец - это блок vttc, который содержит блок payl).

Нулевой (`null`)

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

Конец потока (`eost`)

Используется для сигнализации о корректном завершении сессии публикации. Пакеты конца потока не несут никаких данных, кроме основного заголовка KMP.

Пакеты KMP приемника

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

Подтверждающие кадры (`ackf`)

Подтверждают получение кадров.

Приемник KMP решает подходящее время для отправки пакета подтверждения. Например, когда включено сохранение, сегментатор отправляет подтверждение только после того, как сегмент, содержащий кадр, сохранен в хранилище.

Некоторые приемники вообще не отправляют подтверждения, в этом случае производитель KMP должен быть настроен на отбрасывание кадров после их отправки (используя настройку resume_from)

Заголовок пакета содержит следующие поля: - frame_id - целое число, идентификатор первого кадра, который должен быть повторно отправлен, если соединение обрывается. Другими словами, пакет подтверждающих кадров подтверждает все кадры, у которых идентификатор меньше, чем frame_id. Если соединение KMP восстанавливается, это значение будет отправлено в поле initial_frame_id. - upstream_frame_id - целое число, идентификатор кадра, который был отправлен вышестоящему серверу. Если соединение KMP восстанавливается, это значение будет отправлено в поле initial_upstream_frame_id. - offset - целое число, смещение для подтверждения в пределах кадра. Если соединение KMP восстанавливается, это значение будет отправлено в поле initial_offset. - padding - целое число, зарезервировано для будущего использования, должно быть установлено в ноль.

Данные подтверждающих пакетов не используются.

Протокол Kaltura Segmented Media (KSMP)

Протокол Kaltura Segmented Media - это HTTP-протокол для доставки медиа в сегментах, аналогично HLS/DASH.

Запрос KSMP - это HTTP запрос GET, определены следующие параметры запроса - - channel_id - обязательная строка, идентификатор канала - timeline_id - обязательная строка, идентификатор временной шкалы - flags - обязательное шестнадцатеричное целое число, флаги: - Выбор подмножества данных, которое требуется (как список столбцов в SQL SELECT операторе) - Управление различными поведениями при обработке запроса. Например, флаг 'closest key' возвращает только ключевой кадр, который ближе всего к временной метке запроса, вместо того чтобы возвращать весь сегмент. - variant_ids - необязательная строка, выбирает подмножество вариантов, которые должны быть возвращены, по умолчанию возвращаются все варианты. Если указано несколько вариантов, они должны быть разделены дефисом (-). - media_type_mask - необязательное шестнадцатеричное целое число, устанавливает типы медиа, которые должны быть возвращены, по умолчанию возвращаются все типы медиа. - time - необязательное целое число, запрашиваемая временная метка. Временная метка используется, например, для захвата видеокадра в определенное время. - segment_index - необязательное целое число, индекс сегмента - max_segment_index - необязательное целое число, используется для ограничения области сегментов, возвращаемых в ответе. Этот параметр может использоваться для воспроизведения сохраненного потока для отладки. - part_index - необязательное целое число, индекс частичного сегмента с нуля в пределах сегмента. Запрос, использующий part_index, также должен отправить segment_index. - skip_boundary_percent - необязательное целое число, устанавливает значение skip boundary как процент от целевой продолжительности (см. определение атрибута CAN-SKIP-UNTIL в спецификации HLS для получения дополнительных сведений) - padding - необязательное целое число, добавляет дополнительные нулевые байты в конце ответа. Используется для соблюдения требований о заполнении ffmpeg без дополнительных операций копирования.

Ответ KSMP использует формат KLPF (см. ниже), с типом Serve (serv). Специфические определения KSMP можно найти в ngx_ksmp.h

Kaltura Live Persist File (KLPF)

Kaltura Live Persist File - это схема сериализации, используемая в ответах KSMP и в объектах S3, созданных модулем nginx-live-module.

KLPF состоит из блоков, аналогично атомам/боксам MP4. Каждый блок имеет следующий заголовок - - id - четырехсимвольный код, идентифицирующий блок - size - uint32, полный размер блока (заголовок и данные) - flags - 4 бита, определены следующие флаги: - container (0x1) - блок содержит другие блоки - index (0x2) - блок является индексом к другому блоку, размер заголовка не следует использовать - compressed (0x4) - данные блока сжаты zlib - header_size - 28 бит, размер заголовка блока. Парсеры должны использовать размер заголовка для доступа к данным блока, чтобы можно было добавлять поля в заголовок без нарушения совместимости.

Файл KLPF - это блок, идентификатор которого установлен в klpf. После общих полей заголовка блока (перечисленных выше), файл KLPF имеет следующие поля в своем заголовке - - uncomp_size - uint32, содержит несжатый размер данных, когда данные KLPF сжаты - version - uint32, версия формата файла. Версия, используемая для новых файлов, обновляется при каждом нарушении формата, код будет обновлён - чтобы поддерживать чтение как новго формата, так и старого формата, или - игнорировать файлы, которые используют старый формат - type - четырехсимвольный код, который идентифицирует тип данных, хранящихся в KLPF. Тип определяет, какие идентификаторы блоков поддерживаются и их внутреннюю структуру. Тип serv (Serve) используется для ответов KSMP, в общении между упаковщиком и сегментатором. Дополнительные типы используются внутренне сегментатором. - created - uint64, временная метка unix, когда KLPF был создан

Для получения дополнительных сведений о внутренней структуре блоков KLPF см. KLFP-SPEC.md.

Для проверки содержимого объектов KLPF/ответов KSMP используйте klpf_parse.py. Скрипт может показать структуру блока без какой-либо дополнительной информации, однако, для того, чтобы разобрать поля внутри блоков: - запустите generate_persist_spec.py и сохраните вывод в файл - предоставьте имя файла klpf_parse.py, используя параметр -s / --spec-file

Обзор API

Все компоненты обработки медиа предоставляют REST API на основе JSON. Этот раздел объясняет общие свойства API Media-Framework. Для детальной справки о доступных конечных точках API см. документацию по конкретным модулям.

Типы запросов

В API используются следующие HTTP-методы: - GET - получить полный статус модуля или его подмножество. К запросу можно добавить аргумент ?pretty=1, чтобы вернуть ответ в "красивом" / отформатированном виде. - GET с ?list=1 - вернуть имена "папок" под определенным путем в API. Может использоваться для обхода дерева возможных маршрутов API. - POST - создать объект. - PUT - обновить объект, идентификатор объекта для обновления передается в URI. - DELETE - удалить объект, идентификатор объекта для удаления передается в URI.

Тело запроса в запросах POST / PUT должно быть в формате JSON (обычно объект), и запрос должен использовать заголовок Content-Type: application/json.

Когда размер тела запроса превышает определенный порог, nginx записывает его во временный файл. Тем не менее, реализация API Media-Framework требует, чтобы тело запроса POST / PUT было доступно в памяти. При необходимости можно использовать директиву nginx client_body_buffer_size, чтобы увеличить размер буфера, выделяемого для тела запроса.

Коды статуса

HTTP коды статуса используются для возврата статуса выполнения API запросов.

Используются следующие коды успешного завершения: - 200 - успешный запрос GET, тело ответа - JSON, обычно JSON объект или массив (ответ включает заголовок Content-Type: application/json). - 201 - успешный запрос POST, который привел к созданию нового объекта. - 204 - успешный запрос POST / PUT / DELETE. Запрос POST может вернуть 204, когда объект уже существует, и upsert включен для конечной точки API в конфигурации nginx.

Используются следующие коды ошибок: - 400 - недействительный запрос, например, длина какого-то входного поля превышает лимит. - 403 - возвращается модулем nginx-live-module, когда получен запрос на обновление канала, который в данный момент читается из хранилища. - 404 - некоторый объект, на который ссылается URI или тело запроса, не найден. - 409 - попытка создать объект, который уже существует, когда upsert не включен для конечной точки API в конфигурации nginx. - 415 - тело запроса не является допустимым JSON, тип JSON не ожидается (обычно ожидается JSON объект) или отсутствует какое-то обязательное поле. - 500 - непредвиденная ошибка, например, сбой выделения памяти.

Мульти-запрос

Настройка канала в nginx-live-module может требовать нескольких вызовов API - создание канала, создание временной шкалы, создание варианта и т.д. Чтобы избежать затраты времени на несколько обратных вызовов, уровень API поддерживает "мульти" запросы. Мульти-запрос объединяет несколько запросов API в одном HTTP запросе.

Мульти-запросы должны использовать метод POST, и их URI должен быть установлен в /multi. Тело запроса должно быть JSON массивом объектов, каждый объект представляет собой отдельный запрос API.

Объекты содержат следующие поля: - uri - строка, обязательное, относительный путь API. - method - строка, обязательное, HTTP-метод запроса - GET / POST / PUT / DELETE. - body - любой тип (обычно объект), необязательное, тело запросов POST / PUT.

Ответ мульти-запросов также является JSON массивом объектов. Количество элементов в массиве ответа всегда совпадает с количеством элементов в массиве запроса, и порядок объектов в массиве ответа совпадает с порядком в массиве запроса. Другими словами, N-й элемент массива ответа - это ответ на N-й запрос в массиве запроса.

Каждый объект ответа содержит следующие поля: - code - целое число, обязательное, HTTP код состояния - body - любой тип (обычно объект / массив), необязательное, тело ответа