[lucastaonline]

O que muda

Quatro pedidos do desenvolvedor, a partir do teste no Firefox na v41.5.4-beta.

1. O Firefox não conseguia iniciar o compartilhamento ("erro inesperado")

Causa raiz: o id de cada tela vem do MediaStream local (stream.id). O Firefox dá a todo MediaStream um id no formato {uuid}, com chaves, e a regra screenShareIdSchema (^[A-Za-z0-9_.-]{1,64}$) recusa as chaves. O source-add caía num ZodError.
Correção: core/screenShareStream.ts dá ao stream um UUID próprio quando o id do navegador não serve. No Chromium e no Electron, nada muda. Não há mudança de protocolo. Reproduzido no Firefox: antes vinha o ZodError; agora a tela entra no ar.

2. AV1 do desktop no Firefox mostrava "Não foi possível estabelecer ou manter"

• Com a conexão do SFU ativa (par ICE succeeded), mas sem nenhum pacote de vídeo num navegador que não reproduz o formato, o fim do prazo de início agora vira unsupported, e não falha de rede.
• RemoteScreenPresentations.browserFailed gravava connection-failed fixo para qualquer erro. Agora a razão sai de browserScreenFailureReason, a mesma regra que a assinatura usa.
• O consume do SFU só deixa de classificar como codec um AbortError (aposentadoria), e não qualquer DOMException.

3. Textos em linguagem simples

• Quem não consegue assistir vê: "Este navegador não consegue assistir a esta transmissão. Peça a quem está transmitindo para usar o formato Compatível, ou assista pelo Chrome, pelo Edge ou pelo app desktop."
• Os cards se chamam "Compatível" e "Melhor qualidade" e explicam quem não consegue assistir. Não aparece nome de perfil.

4. Formato Compatível no app desktop

Fica em Configurações → Qualidade e compartilhamento, num novo grupo "Formato do vídeo". Ele usa os mesmos cards e a mesma configuração (screenFormat) do diálogo da web, ou seja, uma regra só.

• Padrões: no desktop, Melhor qualidade (H.264 Main ou AV1, como hoje); na web, Compatível. A escolha que a v41.5.4 salvou como browserScreenFormat continua valendo.
• Main process: no Compatível, a descoberta testa só encoders H.264 (h264Only, com AV1 nunca entre os candidatos). O perfil chega à sonda da fonte e ao publicador.
• Host do Windows (libobs): recebe --h264-profile=constrained-baseline. x264, NVENC e AMF usam o perfil baseline da lista do OBS, que é o único "baseline" oferecido. NormalizeConstrainedBaseline marca o constraint_set1 de um SPS Baseline sem a marca. Isso é Constrained Baseline, pela H.264 A.2.1. O SPS é validado como perfil 66, e a configuração informada pelo host (profile) é conferida.
• Motor C++: recebe videoInput: 'encoded-h264-cb', pela export nova monky_rtc_engine_create_encoded_compatible.
  • Anuncia e negocia só Constrained Baseline. Atende receptores em qualquer nível anunciado, já que os navegadores anunciam o 3.1 padrão.
  • No SFU, escolhe o 42e01f do roteador, sem mudança no servidor.
  • O H264Bitstream aceita CB e recusa PPS com grupos de slices, predição ponderada ou imagens redundantes.
• macOS (VideoToolbox): usa H264_ConstrainedBaseline_AutoLevel (macOS 12+; nos anteriores, "perfil não suportado"). O probe exige perfil 66 com o constraint_set1.
• Nível 3.1 do Firefox: o teste do decodificador do Firefox real (159) aceita Constrained Baseline até o nível 5.2 (4K60, 1440p60, 1080p120) e recusa o 6.0. Por isso, no Compatível a tela mantém o tamanho e só reduz o FPS que exigiria nível 6, que no 4K fica limitado a 64 FPS (compatibleScreenProfile, regra única para web e desktop). Não foi preciso limitar a 720p30.
• QSV: não existe hoje no Monky; os encoders do Windows são AMF, NVENC e x264.

⚠️ Sem validação no CI

Os encoders de hardware no formato Compatível (NVENC e AMF; o QSV não é usado pelo Monky) não têm validação no CI, que não tem GPU. O CI compila e testa:

• o x264 por software no contrato do host;
• o parser e o motor nos probes;
• o VideoToolbox só pelos testes de JS.

Se um driver recusar o perfil baseline, o compartilhamento no Compatível falha com erro de encoder, e o app tenta outro candidato ou o software, como hoje.

Testes de regressão

Todos falham sem a correção; conferi revertendo cada uma.

• Web e assinatura:
  • stream {uuid};
  • SFU com conexão ativa e zero vídeo AV1 (Firefox unsupported, Chromium connection-failed);
  • recusa de codec que chega à chamada;
  • browserScreenRefusal.
• Main:
  • política h264Only, nas duas estratégias;
  • formato chegando à descoberta, à sonda e ao publicador, com 4K120 → 64 FPS no Compatível.
• Runtime nativo (JS):
  • protocolo do host (perfil, argumento, host que não pode relabelar);
  • endpoint encoded-h264-cb;
  • bridge do macOS.
• C++ (CI):
  • argumentos, JSON e normalização do SPS no host;
  • fábrica CB do motor, seleção no SFU e normalização no H264Bitstream.
• Interface e configurações:
  • smoke de Qualidade (cards, codec travado em H.264 no Compatível, volta ao AV1);
  • persistência com a chave antiga;
  • comando de fonte com o formato.

O que falta validar fora do CI

• Firefox de ponta a ponta. Automação aqui desliga o ICE do Firefox. O início do compartilhamento foi reproduzido com o Firefox real.
• Os encoders de hardware no Compatível.
• O Safari segue na Versão web: Safari não consegue entrar no servidor #883.