Resumo

  • A RFC 10034, de Lauri Ilola e Lukasz Kondrad, especifica o transporte RTP das NALs do atlas V3C e um agrupamento SDP que indica quais linhas de mídia compõem a mesma representação.
  • O receptor pode rejeitar linhas e aceitar somente um subconjunto. Fragmentos perdidos, ordem de decodificação, capacidade para o conjunto de parâmetros e alinhamento entre fluxos continuam sendo condições independentes.
  • O formato não determina uma proteção universal. Origem, integridade e confidencialidade precisam abranger cada subfluxo e a sinalização que estabelece o grupo; uma linha SDP não transfere confiança.

Uma cena volumétrica chega à rede depois de ter sido desdobrada. O codificador transforma o volume em componentes bidimensionais. A ocupação informa quais pixels contribuem, a geometria posiciona pontos, os atributos acrescentam cor ou material e o atlas conserva as instruções para projetar regiões de volta ao espaço tridimensional.

É uma arquitetura de cooperação, não um único filme. A RFC 10034, publicada no Standards Track da IETF em agosto de 2026, dá regras RTP ao atlas e uma gramática SDP ao conjunto. Ilola e Kondrad descrevem como transportar as peças sem fingir que o transporte já realizou a reconstrução.

O atlas transportado ainda depende dos demais componentes

O atlas carrega patches que relacionam áreas 2D à representação 3D. Sem os vídeos de ocupação, geometria e atributos correspondentes, ele não é a cena. Sem o atlas e os parâmetros aplicáveis, os vídeos podem não conter informação suficiente para recuperar o volume.

O conjunto de parâmetros V3C descreve recursos necessários para decodificar e reconstruir. Por isso, a RFC considera útil sinalizá-lo fora de banda. Se ele chegar dinamicamente quando o receptor não tem uma capacidade exigida, o comportamento pode ser indefinido. A existência do parâmetro e a decisão de capacidade são dois registros diferentes.

Essa separação também evita uma afirmação comum em demonstrações: “todos os fluxos estavam presentes”. Presença em SDP é intenção. Presença na rede é recepção. Presença no decoder é consumo. Somente a saída validada mostra se as partes formaram algo utilizável.

Agregação e fragmentação mudam o significado da perda

Uma NAL do atlas pode ocupar um pacote único, compartilhar um pacote de agregação com outras NALs ou ser dividida em unidades de fragmentação. A agregação reduz o custo de cabeçalhos para unidades pequenas; a fragmentação permite transportar uma unidade maior que o pacote desejado.

Um AP deve conter pelo menos duas unidades, caber em um pacote IP e não deve ser fragmentado. Uma FU não pode conter outra FU. Os fragmentos de uma mesma NAL seguem consecutivos, em números RTP crescentes. Se um fragmento some, o receptor deve descartar a continuação daquela unidade.

Logo, uma taxa de perda pequena pode eliminar uma NAL inteira. Somar bytes recebidos não revela se os bits inicial e final estavam presentes, se o AP era válido ou se a política de descarte foi aplicada. O comprovante precisa incluir limites AP/FU, lacunas, remontagem e resultado entregue ao decoder.

A ordem lógica também não é sempre a ordem da rede. Quando sprop-max-don-diff é zero, transmissão e decodificação devem coincidir. Quando é maior, DON/DONL permitem reordenar antes do decoder. O número de sequência RTP e o número de ordem de decodificação respondem a perguntas diferentes.

O atlas usa relógio RTP de 90 kHz e o timestamp RTP rege a apresentação. Mesmo assim, ocupação, geometria, atributos e atlas podem chegar com defasagens incompatíveis. A sincronização deve ser medida na junção dos fluxos, não inferida da saúde de cada um isoladamente.

O grupo V3C declara pertencimento

A RFC 5888 criou o arcabouço de agrupamento SDP. A RFC 10034 acrescenta a semântica V3C: os tokens da linha apontam para os mid das linhas que pertencem ao mesmo bitstream. O atlas aparece como m=application e v3c; os componentes de vídeo preservam m=video e o formato RTP do codec.

No modelo unicast de oferta e resposta, o ofertante lista os componentes e indica quais devem ser consumidos em conjunto. O respondente pode aceitar ou rejeitar linhas indesejadas, colocando a porta em zero. O texto permite um subconjunto quando o receptor desconhece total ou parcialmente o esquema V3C.

Assim, uma resposta correta pode representar uma escolha incompleta. Uma aplicação talvez tolere geometria sem cor; outra não consegue operar sem determinado atlas. O status da sessão não contém esse juízo de produto.

No SDP declarativo, quem não suporta os parâmetros deve rejeitar ou não participar. A participação comprova aceitação da declaração, não qualidade, fidelidade nem frame reconstruído.

A segurança precisa acompanhar todas as arestas

A RFC 10034 não impõe um mecanismo específico de segurança. Cabe à aplicação selecionar confidencialidade, integridade e autenticação de origem. Como uma sessão pode envolver várias correntes RTP, mais SDP e RTCP, a cobertura precisa ser demonstrada para todas elas.

Proteger a geometria não autentica um atlas vindo de fonte inesperada. Proteger pacotes mas deixar alterável a linha que associa componentes expõe a própria composição. Em multicast, conjuntos de parâmetros devem permanecer vinculados à origem e servir apenas ao bitstream dessa origem.

As RFCs 7201 e 7202 apresentam as opções e a razão para não haver uma solução única no payload. A consequência prática é exigir no recibo o mecanismo usado, os componentes protegidos, a identidade verificada, as chaves ou âncoras e o resultado. “Grupo detectado” não é um controle de segurança.

Um padrão útil porque não promete o resultado inteiro

O perfil oficial da Nokia descreve Kondrad como Principal Standardization Specialist em padrões de mídia imersiva na ISO/IEC e na IETF. A RFC 10034 faz essa ponte: a ISO/IEC 23090-5 define V3C; RTP, SDP, agrupamento e segurança vêm do ecossistema IETF.

O trabalho é coletivo. Ilola divide a autoria. RFCs anteriores fornecem as bases. A IANA registra application/v3c, v3cfmtp e a semântica V3C. Registro não é taxa de adoção nem prova de produto; o cargo de Kondrad tampouco descreve uma implantação da Nokia.

O limite é a força do documento. Ele dá nomes verificáveis para empacotamento, ordem, tempo, parâmetros, associação, negociação, congestionamento e proteção. Uma falha pode ser encaminhada ao controle que realmente a produz.

A primazia do código em execução de Heng Lu oferece o teste: guardar a oferta e a resposta exatas, todos os mid, linhas aceitas e recusadas, hash dos parâmetros, mapa dos componentes, SSRCs, segurança, perdas, DON/DONL, AP/FU, sincronização, versão e erros do decoder e validação da cena. Depois, repetir.

Pertencer ao grupo é o primeiro recibo. Chegar, permanecer íntegro, ordenar, sincronizar, decodificar e reconstruir são os seguintes. A RFC 10034 cria a corrente; não autoriza usar o primeiro elo como resultado final.

Fontes