Pular para conteúdo

live-common: Módulo NGINX Comum do Kaltura Media Framework

Instalação

Você pode instalar este módulo em qualquer distribuição baseada em RHEL, incluindo, mas não se limitando a:

  • RedHat Enterprise Linux 7, 8, 9 e 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 e Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-live-common

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-live-common

Ative o módulo adicionando o seguinte no topo de /etc/nginx/nginx.conf:

load_module modules/ngx_http_api_module.so;

Este documento descreve o nginx-module-live-common v2.0.6 lançado em 13 de novembro de 2025.

Status da Construção

Um framework distribuído para streaming de vídeo ao vivo. O sistema é composto por múltiplos componentes, cada um responsável por uma função específica.

Os componentes podem ser implantados em um único servidor para implantações/testes em pequena escala, mas é recomendado implantá-los separadamente para uma utilização mais otimizada dos recursos. Por exemplo, o transcoder pode utilizar a GPU, então seria mais econômico implantar os transcoders em servidores com suporte a GPU, enquanto os outros componentes funcionariam em servidores sem GPU.

A mídia é transmitida entre os diferentes componentes internamente usando protocolos personalizados - 1. Kaltura Media Protocol (KMP) - um protocolo baseado em TCP para entrega de mídia em streaming, conceitualmente, semelhante a uma única faixa de fMP4/MPEG-TS 2. Kaltura Segmented Media Protocol (KSMP) - um protocolo baseado em HTTP para entrega de mídia em segmentos, conceitualmente, um superconjunto de LLHLS/DASH

A orquestração dos diferentes componentes de mídia é realizada por um "controlador". A principal responsabilidade do controlador é construir a topologia do pipeline de mídia e atualizá-la em caso de falhas. O controlador recebe eventos JSON dos componentes de mídia enviados como HTTP-POSTs. Além disso, todos os componentes de processamento de mídia expõem uma API REST baseada em JSON, que é usada pelo controlador para obter o status mais recente e tomar ações. Uma implementação de controlador de exemplo para um servidor all-in-one é fornecida na pasta conf.

Principais Recursos

  • Protocolos de publicação: RTMP, MPEGTS (sobre SRT/HTTP/TCP)
  • Protocolos de reprodução: HLS/LLHLS, DASH
  • Protocolos de push/retransmissão ao vivo: RTMP
  • Transcodificação de vídeo/áudio - incluindo suporte a GPU, baseado na API do ffmpeg
  • Persistência - em armazenamento de objetos S3 (ou compatível)
  • Entrega de taxa de bits adaptativa
  • Suporte a legendas - incluindo conversão de 608/708 para WebVTT
  • Áudio alternativo
  • Criptografia de mídia e DRM
  • Captura de quadro de vídeo

Começando

A pasta conf contém código e configuração de exemplo para executar um servidor all-in-one.

Glossário

  • Canal - um contêiner que representa uma transmissão ao vivo, pode conter faixas, variantes, cronogramas etc.
  • Faixa - uma única versão de vídeo/áudio/legenda. Por exemplo, um canal pode ter 3 faixas de vídeo: 1080p, 720p, 540p.
  • Variante - um agrupamento de faixas usado para empacotamento. As variantes determinam qual faixa de áudio será emparelhada com cada faixa de vídeo, quando segmentos multiplexados são usados. Uma variante pode apontar para várias faixas, mas não mais de uma faixa por tipo de mídia. As faixas devem ser associadas a variantes para serem entregues via HLS/DASH.
  • Segmento - um grupo de quadros de uma faixa específica. Os segmentos são sempre independentes - os segmentos de vídeo sempre começam com um quadro chave/IDR.
  • Índice de segmento - um número que identifica os segmentos das diferentes faixas que estão associados a um intervalo de tempo específico.
  • Período - um conjunto de índices de segmento que podem ser reproduzidos continuamente.
  • Cronograma - um conjunto de períodos. Vários cronogramas podem ser criados, cada um com seu próprio conjunto de períodos. Os cronogramas podem ser usados, por exemplo, para implementar o "modo de visualização" - o publicador consome um cronograma, enquanto os espectadores consomem outro. O cronograma do publicador está sempre ativo, enquanto o cronograma dos espectadores é ativado a critério do publicador.

Topologias de Exemplo

Os diagramas abaixo demonstram algumas topologias de exemplo que podem ser criadas usando os componentes do Media-Framework.

Simples RTMP Passthrough

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;

Passthrough + Persistência 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;

Entrada SRT + Transcodificação de Vídeo

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 video|trans;
    trans-->|KMP video|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Decodificação de Legendas Ocultas

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 video|cc;
    cc-->|KMP subtitle|live;
    ingest-->|KMP video|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Transcodificação + Push RTMP

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;

Visão Geral dos Componentes

Componentes de Mídia

  • nginx-rtmp-kmp-module - ingestão de mídia ao vivo, entrada: RTMP, saída: KMP x N

  • nginx-mpegts-kmp-module - ingestão de mídia ao vivo, entrada: MPEG-TS sobre TCP/HTTP, saída: KMP x N

  • transcoder - transcodificação de vídeo/áudio, entrada: KMP, saída: KMP x N

  • nginx-live-module - segmentador de mídia ao vivo, entrada: KMP x N, saída: KSMP

    Recursos adicionais: persistência, preenchimento, suporte a cronogramas.

  • nginx-pckg-module - empacotador de mídia ao vivo (sem estado), entrada: KSMP, saída: HLS/LLHLS, DASH

    Recursos adicionais: taxa de bits adaptativa, legendas, áudio alternativo, criptografia de mídia / DRM, captura de quadro de vídeo

  • nginx-kmp-cc-module - decodificador de legendas ocultas, entrada: KMP video (h264/5), saída: KMP subtitle (WebVTT) x N

  • nginx-kmp-rtmp-module - retransmissão de mídia ao vivo, entrada: KMP x N, saída: RTMP

Importante: Todos os componentes baseados em nginx que mantêm estado (=todos exceto nginx-pckg-module) devem ser implantados em um único servidor nginx de processo (worker_processes 1;). O estado do módulo é mantido por processo, e quando múltiplos processos são usados, não é possível controlar qual processo receberá a solicitação. Por exemplo, a solicitação para criar um canal no segmentador pode chegar ao trabalhador 1, enquanto a conexão KMP com a mídia real, atingirá o trabalhador 2. Em implantações que usam contêineres, isso não deve ser um problema - múltiplos contêineres podem ser implantados em um único servidor, em vez de usar múltiplos processos nginx. Outra possibilidade é usar um patch como o per-worker listener do arut, mas provavelmente precisará ser atualizado para se aplicar também a conexões stream.

Opções de Depuração

Alguns dos componentes do Media-Framework suportam macros de pré-processador opcionais para fins de depuração - - NGX_LBA_SKIP (nginx-common) - Ignora o uso do módulo "Large Buffer Array" (LBA). Quando habilitado, as alocações de LBA são direcionadas para ngx_alloc / ngx_free. - NGX_RTMP_VERBOSE (nginx-rtmp-module) - Habilita mensagens de log de depuração adicionais - NGX_LIVE_VALIDATIONS (nginx-live-module) - Habilita verificações de consistência em tempo de execução nas estruturas de dados internas, habilitado por padrão ao usar --with-debug - NGX_BLOCK_POOL_SKIP (nginx-live-module) - Ignora o uso de pools de blocos. Quando habilitado, as alocações de pool de blocos são direcionadas para ngx_palloc / ngx_pfree.

Para testar os módulos com valgrind, é recomendado aplicar o patch no-pool-nginx e configurar o nginx com --with-cc-opt="-O0 -DNGX_BLOCK_POOL_SKIP -DNGX_LBA_SKIP" e --with-debug.

Kaltura Media Protocol (KMP)

O Kaltura Media Protocol é um protocolo simples baseado em pacotes para streaming de mídia sobre TCP. Uma conexão KMP pode entregar a mídia de uma única faixa de vídeo/áudio/legenda - quando várias faixas são necessárias, várias conexões TCP são estabelecidas.

Cada pacote começa com um cabeçalho que contém os seguintes campos (32 bits cada) - - Tipo - o tipo do pacote. Os tipos de pacotes são códigos de quatro caracteres, veja abaixo a lista de tipos atualmente definidos. - Tamanho do cabeçalho - o tamanho do cabeçalho do pacote, deve estar entre sizeof(kmp_packet_header_t) e 64KB. Os analisadores devem usar o tamanho do cabeçalho para acessar os dados do pacote, isso permite a adição de novos campos aos cabeçalhos de pacotes sem quebrar analisadores existentes. - Tamanho dos dados - o tamanho dos dados do pacote, deve estar entre 0 e 16MB. - Reservado - reservado para uso futuro, deve ser definido como 0.

As estruturas e constantes usadas no KMP podem ser encontradas em ngx_live_kmp.h.

IDs de Quadro KMP

Um id de quadro é um inteiro de 64 bits que identifica exclusivamente um quadro de entrada. Os módulos de ingestão (nginx-rtmp-kmp-module / nginx-mpegts-kmp-module) alocam o id de quadro inicial de acordo com o relógio do servidor (em unidades de escala de tempo), quando uma faixa de saída é criada. Para evitar a necessidade de enviar o id do quadro em cada quadro que está sendo enviado, os ids de quadro no KMP são sequenciais - o id do N-ésimo quadro que é enviado em uma conexão KMP é initial_frame_id + N.

Se a conexão de entrada (por exemplo, RTMP) cair e for restabelecida, novos ids de quadro KMP serão alocados. Como a escala de tempo padrão é alta (90kHz), e a taxa de quadros provavelmente não excederá 60fps, mesmo no caso de uma reconexão após um curto período de streaming, o id de quadro inicial será significativamente maior do que o id de quadro que foi enviado por último na conexão anterior. Portanto, é extremamente improvável que haja um conflito com qualquer id de quadro usado anteriormente devido à reconexão.

Os ids de quadro são usados: - Para identificar quais quadros estão sendo confirmados em pacotes de confirmação KMP - Para pular quadros previamente tratados se uma conexão KMP for restabelecida

O transcoder adiciona algumas complexidades à gestão de ids de quadro - - Como o transcoder pode alterar a taxa de quadros de entrada ou descartar quadros, os ids de quadro na entrada do transcoder não são necessariamente os mesmos que os ids de quadro na saída do transcoder. Se o transcoder for reiniciado, ele precisa saber qual valor enviar como o initial_frame_id de seu servidor upstream (geralmente nginx-live-module). O campo upstream_frame_id é usado para esse propósito. - O transcoder pode ser configurado para alterar a taxa de amostragem de uma faixa de áudio e, nesse caso, os quadros transcodificados não se alinham com os quadros de entrada. Para lidar com esse cenário, o transcoder precisa ter a capacidade de reconhecer apenas uma parte de um quadro de entrada. Este é o propósito do campo offset - ele pode armazenar, por exemplo, o número de amostras de áudio que devem ser reconhecidas dentro do quadro. O significado exato do campo offset é determinado pelo receptor KMP - o receptor define o offset nos quadros de confirmação que retorna e o recebe de volta no campo initial_offset do pacote de conexão, em caso de reconexão.

Pacotes KMP do Publicador

As seções abaixo listam os pacotes KMP que podem ser enviados por um publicador KMP.

Conectar (cnct)

Enviado imediatamente após a conexão TCP KMP ser estabelecida.

O cabeçalho contém os seguintes campos: - channel_id - string, o id do canal que está sendo publicado. O comprimento máximo permitido é 32 caracteres. - track_id - string, o id da faixa que está sendo publicada. O comprimento máximo permitido é 32 caracteres. - initial_frame_id - inteiro, o id do primeiro quadro sendo enviado. - initial_upstream_frame_id - inteiro, o id de quadro inicial que deve ser enviado ao servidor upstream (usado pelo transcoder) - initial_offset - inteiro, o deslocamento a partir do qual começar, dentro do quadro inicial. - flags - inteiro, uma máscara de bits de flags, atualmente uma única flag é definida - consistent - esta flag é definida quando o publicador KMP gera uma saída consistente (exata em bits), dada a mesma entrada. nginx-rtmp-kmp-module e nginx-mpegts-kmp-module são exemplos de publicadores que são consistentes. O transcoder, por outro lado, não é. A flag consistent é usada pelo segmentador LL em caso de reconexão. Quando o publicador é consistente, o segmentador LL pode continuar a partir do ponto em que parou. Quando o publicador é inconsistente, o segmentador LL pode continuar apenas a partir do próximo GOP - não deve misturar um GOP parcial de antes da desconexão, com o GOP recebido após a desconexão.

Os dados do pacote de conexão são opcionais, o formato esperado dos dados é definido pelo receptor KMP específico.

Informações de Mídia (minf)

Contém os parâmetros da mídia. Alguns dos campos no cabeçalho são compartilhados por todos os tipos de mídia, enquanto os outros são definidos apenas para um tipo específico (união).

Os campos de cabeçalho compartilhados são: - media_type - inteiro, o tipo de mídia - video / audio / subtitle, usa os constantes KMP_MEDIA_XXX. - codec_id - inteiro, o id do codec, usa os constantes KMP_CODEC_XXX. - timescale - inteiro, as unidades usadas nos campos dts / pts_delay / created dos pacotes de quadro, em Hz. - bitrate - inteiro, a taxa de bits, em bits por segundo.

Os campos de cabeçalho específicos de vídeo são: - width - inteiro, a largura do vídeo, em pixels. - height - inteiro, a altura do vídeo, em pixels. - frame_rate - racional, a taxa de quadros do vídeo, em quadros por segundo. - cea_captions - booleano, definido como 1 quando a faixa de vídeo contém legendas EIA-608 / CTA-708.

Os campos de cabeçalho específicos de áudio são: - channels - inteiro, o número de canais de áudio. - bits_per_sample - inteiro, o tamanho das amostras de áudio, em bits. - sample_rate - inteiro, a taxa de amostragem do áudio, em amostras por segundo. - channel_layout - inteiro, uma máscara de bits das posições dos canais, usa os constantes KMP_CH_XXX.

Os dados do pacote de informações de mídia contêm os dados privados/extras do codec. Por exemplo, ao usar o codec h264, os dados contêm o corpo de uma caixa MP4 avcC.

Os receptores KMP devem lidar com alterações nas informações de mídia, por exemplo, uma mudança na resolução do vídeo. No entanto, o tipo de mídia (vídeo/áudio/legenda) que é enviado em uma conexão KMP não deve mudar.

Os receptores KMP devem ignorar pacotes de informações de mídia, quando eles são idênticos ao pacote de informações de mídia recebido anteriormente.

Quadro (fram)

Representa um único quadro de vídeo / quadro de áudio / pista de legenda.

O cabeçalho do quadro contém os seguintes campos: - created - inteiro, o tempo em que o quadro foi recebido pelo primeiro módulo do Media-Framework no pipeline, em unidades de escala de tempo. - dts - inteiro, o timestamp de decodificação do quadro, em unidades de escala de tempo. Quando o tipo de mídia é subtitle, contém o timestamp de início da pista. - flags - inteiro, atualmente apenas uma flag é definida - key - habilitado em quadros-chave de vídeo. - pts_delay - inteiro, a diferença entre o timestamp de apresentação do quadro e o timestamp de decodificação, em unidades de escala de tempo. Quando o tipo de mídia é subtitle, contém a duração da pista - end_pts - start_pts.

Quando o tipo de mídia é vídeo / áudio, os dados do pacote de quadro contêm a mídia comprimida. Quando o tipo de mídia é legenda e o codec é WebVTT, os dados do quadro seguem o Formato de Amostra WebVTT, conforme especificado em ISO/IEC 14496-30 (geralmente, nesse caso, uma amostra é uma caixa vttc, que contém uma caixa payl).

Nulo (null)

Enviado para sinalizar "vivacidade" e evitar que os temporizadores ociosos expirem. Pacotes nulos não transportam dados além do cabeçalho básico KMP. Os analisadores devem ignorar pacotes nulos.

Fim de Stream (eost)

Usado para sinalizar uma terminação graciosa da sessão de publicação. Pacotes de fim de stream não transportam dados além do cabeçalho básico KMP.

Pacotes KMP do Receptor

As seções abaixo listam os pacotes KMP que podem ser enviados por um receptor KMP.

Quadros de Confirmação (ackf)

Confirmam o recebimento de quadros.

O receptor KMP decide o momento apropriado para enviar um pacote de confirmação. Por exemplo, quando a persistência está habilitada, o segmentador envia uma confirmação apenas após um segmento que contém o quadro ser salvo no armazenamento.

Alguns receptores não enviam confirmações, nesse caso, o produtor KMP deve ser configurado para descartar os quadros após serem enviados (usando a configuração resume_from).

O cabeçalho do pacote contém os seguintes campos: - frame_id - inteiro, o id do primeiro quadro que deve ser reenviado se a conexão cair. Em outras palavras, um pacote de quadros de confirmação reconhece todos os quadros que têm um id menor que frame_id. Se a conexão KMP for restabelecida, esse valor será enviado no campo initial_frame_id. - upstream_frame_id - inteiro, o id do quadro que foi enviado ao servidor upstream. Se a conexão KMP for restabelecida, esse valor será enviado no campo initial_upstream_frame_id. - offset - inteiro, o deslocamento a ser reconhecido dentro do quadro. Se a conexão KMP for restabelecida, esse valor será enviado no campo initial_offset. - padding - inteiro, reservado para uso futuro, deve ser definido como zero.

Os dados dos pacotes de confirmação não são utilizados.

Kaltura Segmented Media Protocol (KSMP)

O Kaltura Segmented Media Protocol é um protocolo baseado em HTTP para entrega de mídia em segmentos, de forma semelhante ao HLS/DASH.

Uma solicitação KSMP é uma solicitação HTTP GET, os seguintes parâmetros de consulta são definidos - - channel_id - string obrigatória, o id do canal - timeline_id - string obrigatória, o id do cronograma - flags - inteiro hexadecimal obrigatório, as flags: - Seleciona o subconjunto de dados que é necessário (como a lista de colunas em uma instrução SQL SELECT) - Controla vários comportamentos ao atender a solicitação. Por exemplo, a flag 'closest key' retorna apenas o quadro-chave que está mais próximo do timestamp da solicitação, em vez de retornar todo o segmento. - variant_ids - string opcional, seleciona um subconjunto das variantes que devem ser retornadas, por padrão, todas as variantes são retornadas. Se várias variantes forem especificadas, elas devem ser delimitadas por um hífen (-). - media_type_mask - inteiro hexadecimal opcional, define os tipos de mídia que devem ser retornados, por padrão, todos os tipos de mídia são retornados. - time - inteiro opcional, o timestamp solicitado. O timestamp é usado, por exemplo, para capturar um quadro de vídeo em um momento específico. - segment_index - inteiro opcional, o índice do segmento - max_segment_index - inteiro opcional, usado para limitar o escopo dos segmentos retornados na resposta. Este parâmetro pode ser usado para reproduzir um stream persistido para depuração. - part_index - inteiro opcional, o índice baseado em zero do segmento parcial dentro do segmento. Uma solicitação que usa part_index deve enviar também segment_index. - skip_boundary_percent - inteiro opcional, define o valor de skip boundary como uma porcentagem da duração alvo (veja a definição do atributo CAN-SKIP-UNTIL na especificação HLS para mais detalhes) - padding - inteiro opcional, adiciona bytes zero adicionais ao final da resposta. Usado para cumprir os requisitos de preenchimento do ffmpeg sem incorrer em operações de cópia adicionais.

Uma resposta KSMP usa o formato KLPF (veja abaixo), com tipo Serve (serv). As definições específicas do KSMP podem ser encontradas em ngx_ksmp.h.

Kaltura Live Persist File (KLPF)

O Kaltura Live Persist File é um esquema de serialização que é usado em respostas KSMP e nos objetos S3 criados pelo nginx-live-module.

Um KLPF é composto por blocos, semelhante a átomos/caixas MP4. Cada bloco possui o seguinte cabeçalho - - id - um código de quatro caracteres identificando o bloco - size - uint32, o tamanho total do bloco (cabeçalho e dados) - flags - 4 bits, as seguintes flags são definidas: - container (0x1) - o bloco contém outros blocos - index (0x2) - o bloco é um índice para outro bloco, o tamanho do cabeçalho não deve ser usado - compressed (0x4) - os dados do bloco estão comprimidos em zlib - header_size - 28 bits, o tamanho do cabeçalho do bloco. Os analisadores devem usar o tamanho do cabeçalho para acessar os dados do bloco, para que campos possam ser adicionados ao cabeçalho sem quebrar a compatibilidade.

Um arquivo KLPF é um bloco cujo id é definido como klpf. Após os campos de cabeçalho do bloco genérico (listados acima), um arquivo KLPF possui os seguintes campos em seu cabeçalho - - uncomp_size - uint32, contém o tamanho não comprimido dos dados, quando os dados KLPF estão comprimidos - version - uint32, a versão do formato do arquivo. A versão usada para novos arquivos é atualizada a cada alteração que quebra a compatibilidade do formato, o código será atualizado para suportar a leitura tanto do novo formato quanto do antigo, ou ignorar arquivos que usam o formato antigo. - type - um código de quatro caracteres que identifica o tipo de dados armazenados no KLPF. O tipo determina quais ids de bloco são suportados e sua estrutura interna. O tipo serv (Serve) é usado para respostas KSMP, na comunicação entre o empacotador e o segmentador. Tipos adicionais são usados internamente pelo segmentador. - created - uint64, o timestamp unix quando o KLPF foi criado.

Para mais detalhes sobre a estrutura interna dos blocos KLPF, veja KLFP-SPEC.md.

Para inspecionar o conteúdo de objetos KLPF/respostas KSMP, use klpf_parse.py. O script pode mostrar a estrutura do bloco sem informações adicionais, no entanto, para analisar os campos dentro dos blocos: - execute generate_persist_spec.py e salve a saída em um arquivo - forneça o nome do arquivo para klpf_parse.py usando a opção -s / --spec-file.

Visão Geral da API

Todos os componentes de processamento de mídia expõem uma API REST baseada em JSON. Esta seção explica as propriedades gerais das APIs do Media-Framework. Para uma referência detalhada dos endpoints da API disponíveis, consulte a documentação dos módulos específicos.

Tipos de Solicitação

Os seguintes verbos HTTP são usados na API: - GET - obtém o status completo do módulo ou um subconjunto dele. O argumento ?pretty=1 pode ser adicionado à solicitação, para retornar a resposta em um formato "bonito" / indentado. - GET com ?list=1 - retorna os nomes das "pastas" sob um determinado caminho na API. Pode ser usado para percorrer a árvore de rotas possíveis da API. - POST - cria um objeto. - PUT - atualiza um objeto, o id do objeto a ser atualizado é passado na URI. - DELETE - exclui um objeto, o id do objeto a ser excluído é passado na URI.

O corpo da solicitação em solicitações POST / PUT deve ser um JSON (geralmente um objeto), e a solicitação deve usar o cabeçalho Content-Type: application/json.

Quando o tamanho do corpo da solicitação excede um determinado limite, o nginx o grava em um arquivo temporário. No entanto, a implementação da API do Media-Framework requer que o corpo da solicitação de POST / PUT esteja disponível na memória. Se necessário, a diretiva client_body_buffer_size do nginx pode ser usada para aumentar o tamanho do buffer alocado para o corpo da solicitação.

Solicitação Múltipla

Configurar um canal no nginx-live-module pode exigir várias chamadas de API - criar o canal, criar um cronograma, criar uma variante, etc. Para evitar a penalidade de múltiplas viagens de ida e volta, a camada da API tem suporte para solicitações "múltiplas". Uma solicitação múltipla agrupa várias solicitações de API em uma única solicitação HTTP.

As solicitações múltiplas devem usar o verbo POST, e sua URI deve ser definida como /multi. O corpo da solicitação deve ser um array JSON de objetos, cada objeto representa uma única solicitação de API.

Os objetos contêm os seguintes campos: - uri - string, obrigatória, o caminho da API relativo. - method - string, obrigatória, o verbo HTTP da solicitação - GET / POST / PUT / DELETE. - body - qualquer (geralmente objeto), opcional, o corpo das solicitações POST / PUT.

A resposta das solicitações múltiplas também é um array JSON de objetos. O número de elementos no array de resposta sempre corresponde ao número de elementos no array de solicitação, e a ordem dos objetos no array de resposta corresponde à ordem no array de solicitação. Em outras palavras, o N-ésimo item do array de resposta é a resposta da N-ésima solicitação no array de solicitação.

Cada objeto de resposta contém os seguintes campos: - code - inteiro, obrigatório, o código de status HTTP - body - qualquer (geralmente objeto / array), opcional, o corpo da resposta

GitHub

Você pode encontrar dicas adicionais de configuração e documentação para este módulo no repositório GitHub do nginx-module-live-common.