O navegador Firefox 116 da Mozilla deve ter suporte experimental de captura de câmera PipeWire disponível para usuários do Linux.Como mais um passo para adotar o PipeWire para fluxos de áudio/vídeo no desktop Linux, o Firefox 116 está programado para ter o suporte experimental de câmera PipeWire incluído.Jan Grulich, da Red Hat, que fez um trabalho incrível na integração do PipeWire e do Firefox, twittou as boas notícias hoje:
Este tíquete de bug do Mozilla foi aberto há dois anos usando o portal de câmera XDG e o PipeWire para acesso à câmera da web foi finalmente fechado na quinta-feira com o código relevante sendo mesclado. Esta é uma vitória para sandboxing e Flatpaks, multiplexação da câmera e benefícios semelhantes de gerenciamento de acesso à câmera da web via PipeWire.
Firefox 116 deve ter suporte experimental para câmera PipeWire
Em outras notícias relacionadas ao PipeWire, o Collabora postou uma nova entrada no blog sobre o novo Event Dispatcher que vem com o WirePlumber 0.5.
Event Dispatcher do WirePlumber: uma maneira nova e simplificada de lidar com eventos do PipeWire
O Event Dispatcher é um mecanismo de agendamento de eventos PipeWire personalizado projetado para resolver muitos dos problemas fundamentais do WirePlumber. A ideia foi concebida por meu colega e mentor George Kiagiadakis, principal autor de WirePlumber, com quem me sinto privilegiado por trabalhar. George não apenas concebeu a ideia, mas também fez todas as alterações na biblioteca principal do WirePlumber (libwireplumber) para suportar esse mecanismo. Ele nos apresentou a ideia quando estava perto de terminar as mudanças principais.
Notícias Relacionadas
Tecnologia móvel
Samsung destaca avanço nas mensagens RCS com suporte no iOS
O suporte a RCS chega ao iOS com o iOS 18.1, permitindo que usuários de Android e iPhone aproveitem uma experiência de mensagens aprimorada e sem necessidade de redes sociais.
Mercado elétrico
Xiaomi atinge R$ 7,14 bilhões em receita com veículos elétricos no 3º trimestre de 2024
Xiaomi fecha o 3º trimestre de 2024 com R$ 7,14 bilhões em receita com veículos elétricos, impulsionado pelo sucesso da série SU7, apesar do prejuízo operacional.
O PipeWire mantém uma coleção de objetos, como dispositivos, nós, portas e links, que são consultados e atualizados por meio de um protocolo em um soquete Unix local. Embora o próprio protocolo seja síncrono, há muitos casos em que recuperar ou atualizar informações sobre objetos requer várias chamadas de protocolo consecutivas, o que significa que qualquer operação pode levar um tempo não trivial. Durante esse tempo, é possível que outros clientes PipeWire também consultem e/ou atualizem os mesmos objetos, introduzindo problemas de simultaneidade na perspectiva de um único cliente.
Para resolver esses problemas, o WirePlumber foi projetado para ocultar a complexidade do protocolo por trás de uma API de objeto assíncrono. Essa API é então consumida por módulos e scripts para construir a lógica que interage com os objetos PipeWire.
Infelizmente, esta API tem suas limitações. Em primeiro lugar, para ser notificado sobre eventos nesses objetos, módulos e scripts registram callbacks. Embora o WirePlumber seja de thread único, não há nenhum mecanismo para garantir a ordem de execução desses retornos de chamada. Isso significa que diferentes módulos que precisam reagir ao mesmo evento podem ser acionados em ordem aleatória. Em segundo lugar, fazer alterações em qualquer objeto PipeWire inicia uma operação assíncrona. Geralmente essas alterações precisam ser realizadas como uma reação a algum evento, mas como existem vários callbacks em diferentes módulos que reagem ao mesmo evento, é possível que todos comecem a fazer alterações semelhantes no mesmo objeto PipeWire sem esperar um pelo outro para terminar. Isso pode causar interferência entre as operações, causando problemas e exigindo manuseio adicional para evitá-los.
