Resumo

  • A RFC 10034 define o transporte RTP do atlas V3C e a semântica SDP V3C que relaciona as linhas de mídia de atlas, ocupação, geometria e atributos. Essa relação descreve uma representação; não acusa o recebimento nem a reconstrução de todas as partes necessárias.
  • A autoridade para declarar conclusão precisa reconciliar a negociação, a versão dos parâmetros, a origem autorizada, a perda e a remontagem de pacotes, a ordem de decodificação, o alinhamento entre fluxos e um teste observável na aplicação.

Quatro equipes podem entregar quatro relatórios impecáveis e, ainda assim, o produto final estar quebrado. A equipe do atlas vê seus pacotes. A de ocupação não excedeu a meta de perda. O fluxo de atributos mantém a taxa esperada. A geometria acaba de receber um pacote RTP com o bit de marcador. O painel soma os resultados e escreve: representação concluída.

No visor, uma peça industrial aparece com parte da superfície aberta.

Um NAL de geometria foi fragmentado em três pacotes e perdeu o segmento central. A recepção continuou depois da lacuna. O atlas fechou legitimamente sua própria unidade de acesso. O marcador de um fluxo nunca fabricou os bytes ausentes de outro. Cada equipe mediu um fato local verdadeiro; o painel inventou uma conclusão global que nenhuma delas observou.

A RFC 10034, publicada no Standards Track da IETF em agosto de 2026, torna explícita essa fronteira. Ela especifica o formato RTP para o subfluxo de atlas V3C, remete os componentes de vídeo aos formatos de carga de seus codecs e cria uma forma de declarar em SDP que várias linhas de mídia pertencem à mesma representação.

É uma solução de interoperabilidade, não um árbitro de resultado.

Uma cena vira dependências antes de virar pacotes

V3C projeta conteúdo tridimensional em representações bidimensionais e transmite os elementos necessários para reverter essa projeção. A ocupação pode indicar que pixels participam da cena. A geometria localiza os pontos reconstruídos. Os atributos carregam cor, refletância, normais ou outras propriedades. O atlas descreve patches e o mapeamento inverso que devolve significado espacial a esses planos.

O catálogo público da ISO/IEC 23090-5:2026 identifica a especificação V3C e V-PCC usada como base. A arquitetura resumida pela RFC já revela a consequência operacional: um receptor não espera uma fotografia autossuficiente. Ele reúne insumos cujo valor depende de identidade, versão e tempo compatíveis.

Essa decomposição permanece no transporte. O atlas usa application/v3c sobre RTP com relógio de 90 kHz. Ocupação, geometria e atributos usam os formatos RTP dos codecs de vídeo escolhidos. Uma mesma oferta pode combinar codecs distintos entre componentes sem transformar o atlas em vídeo convencional.

Por isso, “quatro fluxos ativos” é uma métrica de inventário, não de experiência. Um atributo dispensável para visualização recreativa pode ser decisivo numa inspeção médica. Uma queda de cor pode ser degradação tolerável; uma geometria incompleta pode invalidar toda a representação. A política de serviço precisa estar acima do contador de sessões.

a=group:V3C diz quem deve ser reconciliado

A RFC introduz no SDP uma expressão como:

a=group:V3C 1 2 3 4

Os tokens remetem aos valores mid das linhas de mídia. A estrutura geral vem da RFC 5888. A semântica V3C declara que as descrições compõem um bitstream. Ela não carrega mídia, não autentica fontes e não consulta o decodificador.

As mesmas linhas podem estar em uma negociação BUNDLE. Compartilhar transporte reduz recursos, mas não funde identidades. Cada pacote ainda deve ser associado ao componente, ao tipo de unidade V3C, ao conjunto de parâmetros, ao atlas e ao contexto de segurança corretos.

O atributo a=v3cfmtp pode existir nos níveis de sessão e de mídia. Em conflito, a RFC 10034 dá precedência ao valor de sessão. A regra resolve uma escolha sintática comum; não prova que uma oferta em cache, uma substituição dentro do fluxo e os dados que chegaram ao decodificador pertencem à mesma revisão.

O registro da IANA para application/v3c exige sprop-v3c-parameter-set e limita o tipo ao enquadramento RTP. Os registros SDP da IANA mantêm os espaços de nomes comuns. Um registro torna o rótulo reconhecível. Não atesta que um emissor o ofereceu, que o receptor possui a capacidade ou que uma sessão real produziu a cena.

Parâmetros descrevem o bitstream, não o receptor

O sprop-v3c-parameter-set obrigatório transporta bytes codificados em Base64. Eles descrevem perfil e recursos necessários à reconstrução. A RFC observa a vantagem de apresentar isso fora de banda: descobrir requisitos só depois de iniciar a mídia pode deixar o receptor sem capacidade e levar a comportamento indefinido.

Outros campos identificam tipo de componente, conjunto de parâmetros ativo, atlas, partição de atributo, mapa e função de vídeo auxiliar. Um cabeçalho combinado de quatro bytes pode carregar a mesma família de dados; ele não pode coexistir com os parâmetros separados, pois duas versões da mesma verdade poderiam divergir.

NALs de atlas, atlas comum e SEI enviados fora de banda podem persistir até uma unidade do mesmo tipo, dentro do fluxo, substituí-los. A substituição é uma mudança de estado. Um receptor que mantém o valor antigo enquanto aceita a nova mídia pode autenticar todos os pacotes e ainda montar a versão errada.

No modelo offer/answer da RFC 3264, o respondente aceita formatos suportados e pode rejeitar uma linha com porta zero. A RFC 10034 permite que um receptor com compreensão parcial de V3C selecione um subconjunto. A flexibilidade é intencional; logo, uma resposta aceita não pode significar universalmente “cena completa”. O produto deve dizer quais subconjuntos são úteis e quais exigem falha fechada.

O marcador fecha uma unidade local, não a representação

O RTP fornece números de sequência, timestamps, identificadores de fonte e um marcador interpretado pelo formato de carga. Na RFC 10034, o bit marca o último pacote da unidade de acesso no fluxo RTP corrente. Ele auxilia o buffer de reprodução; não é uma transação atômica sobre o grupo V3C.

O atlas admite pacote de uma única unidade NAL, pacote de agregação com pelo menos duas unidades pequenas e unidade de fragmentação. A agregação deve respeitar o MTU local. A fragmentação divide um NAL entre pacotes RTP consecutivos, sem aninhamento e sem intercalar outro pacote do mesmo fluxo entre o primeiro e o último fragmentos.

Se um fragmento some, o receptor deve descartar os posteriores daquele NAL, exceto quando o decodificador for conhecido por lidar com unidades incompletas. O retorno do tráfego depois da perda não repara a unidade. Painéis que só contam bytes escondem exatamente a falha que altera a cena.

A ordenação também depende da sessão. Com sprop-max-don-diff ausente ou zero, ordem de transmissão e de decodificação coincidem. Um valor positivo habilita números de ordem de decodificação e exige reordenação. O despacketizador pode ainda aguardar fluxos dos quais o atual depende. A RFC 7798 oferece um precedente NAL no transporte de HEVC; a familiaridade do método não elimina a sincronização multicomponente de V3C.

Segurança por fluxo não basta sem autorização comum

A RFC 10034 deixa a aplicação escolher a solução de segurança. Isso acompanha a arquitetura exposta pela RFC 7202: um formato RTP não conhece o modelo de chaves, identidade, unicast, multicast ou confiança de cada implantação. A RFC 7201 examina as alternativas, e o SRTP oferece mecanismos de confidencialidade, autenticação e proteção contra replay quando apropriado.

Ainda assim, a obrigação V3C é concreta. A RFC recomenda autenticar a origem de todos os subfluxos constituintes e manter RTP, SDP e RTCP autênticos à intenção do remetente. Proteger apenas o atlas, aceitando geometria sem vínculo de fonte, permite montar uma composição que ninguém autorizou.

Nem quatro autenticações bem-sucedidas encerram a prova. Os fluxos podem pertencer a revisões diferentes; um atributo protegido pode chegar tarde; um emissor legítimo pode configurar o atlas incorretamente. Criptografia comprova propriedades dos bytes sob uma chave. Coerência e utilidade exigem observações posteriores.

Congestionamento pode rebaixar o significado

Usuários unicast devem monitorar perdas e aplicar controle de congestionamento. O emissor pode reduzir a taxa, o receptor pode sair e ambos podem recorrer ao circuit breaker RTP. A RFC também admite remover ou reduzir subfluxos menos importantes, desde que se considere a experiência completa.

“Menos importante” não é um campo no pacote. Retirar cor pode manter uma telepresença geométrica e destruir uma inspeção de materiais. Remover um auxiliar pode baixar a fidelidade ou invalidar uma medição. A ação de rede precisa abrir um estado semântico novo, como “somente geometria”, e executar novamente o teste da aplicação.

Uma cadeia de conclusão deve atravessar as camadas

Para cada revisão, registre as impressões digitais de offer e answer, os mid dos grupos V3C e BUNDLE, parâmetros e cabeçalhos, codec, papel do componente, atlas, fonte autorizada, SSRC e transporte. Por fluxo, preserve chegada inicial e final, perda, jitter, profundidade de reordenação, fragmentos completos, ordem de decodificação e limites de unidades de acesso.

Depois do RTP, registre NALs entregues ao decodificador, erros, identidade do quadro reconstruído, canário de renderização ou análise, decisão de degradação, acionamento do circuit breaker e estado terminal. “Negociado”, “recebendo”, “despacketizado”, “decodificado” e “útil” não são sinônimos.

A defesa de Heng Lu da primazia do código em execução situa a prova no caminho executado, não no nome de um padrão. Seu modelo de especificação inicial mínima e decisões localizadas preserva uma sintaxe comum estreita sem retirar escolhas de capacidade e adoção. A distinção entre controle formal e controle prático dos dados explica por que quem declara a sessão não controla automaticamente cópias de rede, buffers, estados do receptor e saída final.

A RFC 10034 diz como as partes se relacionam. A responsabilidade operacional começa onde essa declaração termina.