[lucastaonline]

O que muda

Na versão web, a tela compartilhada passa a sair por padrão em H.264 Constrained Baseline (42e01f, packetization-mode=1), o formato que Firefox, Safari, Chrome, Edge e o app desktop decodificam. Quem publica pode escolher o H.264 Main (imagem melhor) num novo grupo "Formato do vídeo" no diálogo de compartilhar, com o aviso de que o Firefox e o Safari não assistem. A escolha fica salva.

Causas raiz

1. O Firefox assistindo a tela do Edge via "não recebe H.264". O publicador da web só oferecia H.264 Main (4d…), e o Edge ainda usava o encoder de hardware. O Firefox só decodifica Constrained Baseline (OpenH264).
   → Agora o codec é fixado nas duas pontas: setCodecPreferences em P2P (browserScreenPeer.ts) e o codec do produce no SFU (webScreenSfuRendition.ts), escolhidos por isScreenCodec(codec, format). Com o 42e01f negociado, o próprio Edge passa para o OpenH264. Isso foi conferido nos testes E2E abaixo.
2. O Firefox não conseguia publicar. isScreenH264 só aceitava Main, então screenSenderCodecs voltava vazio e webScreenCapabilities().capture ficava false.
   → A capacidade agora lista os formatos que o navegador codifica (browserFormats). O Firefox tem ['compatible'] e publica; o Chromium tem ['compatible','main'].
3. Erro genérico ao não decodificar. O receptor da web exigia Main e, quando o navegador não tinha o perfil ou o codec, a falha aparecia como "Não foi possível estabelecer ou manter esta transmissão".
   → browserReceivesScreenCodec('h264') aceita CB, e o teste do decodificador usa o CB no nível que a tela pede. Uma resposta P2P com o vídeo recusado (porta 0) e um consume do SFU recusado num navegador sem Main viram BrowserScreenCodecError (unsupported). A mensagem sai de browserScreenRefusal:
   • H.264 Main no Firefox: a mensagem diz que a transmissão usa H.264 Main (do desktop ou da opção de melhor qualidade) e indica onde assistir.
   • AV1 no Firefox: a mensagem nomeia o AV1.

A fonte continua anunciada como h264, então não há mudança de protocolo.

Por que só "Compatível" e "H.264 Main" (sem AV1, VP9 ou High)

O app desktop não decodifica o AV1 que o navegador gera. O ReadAv1Sequence exige cor BT.709 explícita e um único operating point, e o Chrome não manda assim (conferi: web AV1 → web passou, web AV1 → desktop falhou). O desktop também não decodifica VP9 nem H.264 High. Oferecer esses formatos quebraria quem assiste pelo desktop. Liberar o AV1 da web exige relaxar av1_sequence.h no nativo, então fica como follow-up.

Testes de regressão

Todos falham sem a correção. Conferi revertendo a correção.

• webScreenPublisher.test.ts:
  • screenSenderCodecs/isScreenCodec por formato: CB escolhido mesmo com Main listado antes; 42001f e High recusados;
  • Firefox publica (capture: true, ['compatible'], botão liberado);
  • Chromium oferece os dois formatos;
  • navegador sem H.264 continua travado;
  • recepção de CB versus Main;
  • browserScreenRefusal (Main/AV1 no Firefox, troca de codec no Chromium).
• browserScreenSubscription.test.cjs:
  • o Firefox assiste H.264 testando 42e033;
  • resposta P2P com vídeo na porta 0 → unsupported;
  • consume recusado no SFU → unsupported no Firefox, enquanto no Chromium continua connection-failed.
• nativeScreenController.test.cjs: o formato chega a todo source-add só na web.
• settingsPersistence.test.ts: o formato salvo é lido, e um valor desconhecido volta para "compatible".

Validação manual (Edge, servidor SFU remoto de QA)

• Web compatível 1080p60 → app desktop via SFU: passou. O Edge codificou 42e01f, e o desktop decodificou cerca de 55 fps.
• Web → web, compatível, em P2P e SFU: passou.
• O diálogo mostra os dois cards, funciona com teclado e mouse, e a escolha fica salva.

Limitações e o que falta validar

• Firefox: não deu para automatizar aqui, porque nem o Playwright nem o Firefox 159 coletam candidatos ICE nesta máquina. Depois da release, validar Firefox → Edge/desktop e Edge → Firefox.
• Web → desktop por P2P falha neste ambiente com os dois formatos, sem pacotes (provavelmente candidatos mDNS, sem STUN). Isso já acontecia antes e não vem desta mudança.
• Safari: segue na Versão web: Safari não consegue entrar no servidor #883.