Boa notícia para quem usa câmeras proprietárias no Linux, a Libcamera poderá aliviar as dores de cabeça com câmeras no Linux.
- Como instalar o editor de vídeo Cinelerra no Linux
- Como converter vídeo em imagens usando o FFmpeg
- Como instalar o cortador de mídia Plumber no Linux via Snap
A API do V4L2 (Video for Linux 2) há muito oferece uma alternativa de código aberto às interfaces de câmera/computador proprietárias, mas está começando a mostrar sua idade.
Na ELC Europe, o desenvolvedor de kernel do Linux, Laurent Pinchart, apresentou uma continuação da pilha V4L2 para câmeras incorporadas: a Libcamera.
A libcamera de código aberto facilita o trabalho dos desenvolvedores do espaço do usuário, oferece controles melhorados por quadro e 3A e codifica a câmera proprietária em sandboxes.
Libcamera poderá aliviar as dores de cabeça com câmeras no Linux
Sim, foi na Embedded Linux Conference Europe, em outubro, que o projeto V4L2 revelou um sucessor chamado libcamera.
O co-criador do V4L2 e prolífico colaborador do kernel do Linux, Laurent Pinchart, delineou o projeto libcamera em estágio inicial em uma apresentação chamada “Por que câmeras embutidas são difíceis e como fazê-las fáceis”.
V4l e V4L2 foram desenvolvidos quando os sistemas embarcados habilitados para câmera eram muito mais simples.
Pinchart, que dirige uma empresa de Linux embarcada chamada Ideas on Board e atualmente trabalha para a Renesas.
Eles disse o seguinte:
“Talvez você tivesse um sensor de câmera conectado a um SoC, talvez com um scaler, e tudo foi exposto via API. Mas quando o hardware se tornou mais complexo, descartamos o modelo tradicional. Em vez de expor uma câmera como um único dispositivo com uma única API, permitimos que o usuário mergulhe no dispositivo e exponha a tecnologia para oferecer um controle mais refinado.”
Essas melhorias foram amplamente documentadas, permitindo que desenvolvedores experientes implementem mais casos de uso do que antes.
No entanto, a especificação colocou grande parte do fardo de controlar a API complexa em desenvolvedores, com poucos recursos disponíveis para facilitar a curva de aprendizado.
Em outras palavras, “o V4L2 se tornou mais complexo para o userspace”, explicou Pinchart.
O projeto planejou adicionar uma camada chamada libv4l para resolver isso. A biblioteca libv4l userspace foi projetada para imitar a API do kernel V4L2 e expô-la a aplicativos “para que ela possa ser completamente transparente no rastreamento do código para libc”, disse Pinchart.
“O plano era ter plugins específicos do dispositivo fornecidos pelo fornecedor e todos seriam parte do arquivo libv4l, mas isso nunca aconteceu. Mesmo se tivesse, não teria sido suficiente.”
O Libcamera, que Pinchart descreve como “não apenas uma biblioteca de câmeras, mas uma pilha completa de câmeras no espaço do usuário”, visa facilitar o desenvolvimento de aplicativos de câmeras embarcadas, melhorando tanto o V4L2 quanto o libv4l.
A parte principal é um framework libcamera, escrito em C++, que expõe as APIs do driver do kernel ao userspace. Na parte superior da estrutura, há ligações de idioma opcionais para idiomas como C.
A próxima camada é uma camada de aplicativo libcamera que se traduz em APIs de câmeras existentes, incluindo V4L2, Gstreamer e o Android Camera Framework, que, segundo Pinchart, não conteria o código Android HAL específico de um fornecedor.
Quanto ao V4L2, “tentaremos manter a compatibilidade como um melhor esforço, mas não implementaremos todos os recursos”, disse Pinchart. Haverá também um formato nativo de aplicativo libcamera, bem como planos para suportar o Chrome OS.
A Libcamera mantém o nível do kernel escondido das camadas superiores. A estrutura é construída em torno do conceito de um dispositivo de câmera, “que é o que você esperaria de uma câmera como usuário final”, disse Pinchart.
“Vamos querer implementar os recursos de cada câmera, e também teremos um conceito de perfis, que é uma visão mais alta dos recursos. Por exemplo, você pode escolher um vídeo ou um perfil de apontar e disparar.”
O Libcamera suportará múltiplos fluxos de vídeo de uma única câmera. “Na videoconferência, por exemplo, você pode querer uma resolução e streams diferentes do que codifica na rede”, disse Pinchart.
“Você pode querer exibir a transmissão ao vivo na tela e, ao mesmo tempo, capturar fotos ou gravar vídeos, talvez em diferentes resoluções.”
Controles por quadro e uma API 3A
Um novo recurso importante é o controle por quadro. “As câmeras fornecem controles para coisas como estabilização de vídeo, flash ou tempo de exposição, que podem mudar sob diferentes condições de iluminação”, disse Pinchart.
“O V4L2 suporta a maioria desses controles, mas com uma grande limitação. Como você está capturando um fluxo de vídeo com um quadro após o outro, se quiser aumentar o tempo de exposição, nunca saberá com precisão em qual quadro será aplicado. Se você deseja capturar uma imagem estática com flash, não deseja ativar um flash e receber uma imagem antes ou depois do flash.”
Com os controles por frame da libcamera, você pode ser mais preciso. “Se você quer garantir que você sempre tenha o brilho e o tempo de exposição corretos, você precisa controlar esses recursos de uma maneira que esteja ligada ao fluxo de vídeo”, explicou Pinchart.
“Com controles por quadro, você pode modificar todos os quadros que estão sendo capturados de forma sincronizada com o fluxo.”
A Libcamera também oferece uma nova abordagem para os controles 3A de uma determinada câmera, como exposição automática, foco automático e balanço de branco automático. Para fornecer um loop de controle de 3A.
Pinchart disse que “você pode ter uma implementação simples com 100 linhas de código que fornecerão resultados pouco utilizáveis ou uma implementação baseada em dois ou três anos de desenvolvimento por fornecedores de dispositivos onde eles realmente tentarem otimizar a qualidade da imagem.
Como a maioria dos fornecedores de SoC se recusam a liberar os algoritmos 3A executados em seus ISPs com uma licença de código aberto, “queremos criar uma estrutura e um ecossistema em que as reimplementações de código aberto de algoritmos proprietários de 3A sejam possíveis”, disse Pinchart.
A Libcamera fornecerá uma API 3A que irá traduzir entre o código da câmera padrão e um componente específico do fornecedor. “A câmera precisa se comunicar com os drivers do kernel, o que é um risco de segurança se o código de processamento da imagem for de código fechado”, disse Pinchart.
“Você está executando um código de fornecedor não confiável de 3A e, mesmo que não esteja fazendo algo pelas suas costas, ele pode ser invadido. Portanto, queremos poder isolar o componente de código fechado e fazê-lo funcionar em uma caixa de proteção.”
“A API pode ser empacotada e desempacotada sobre o IPC. Podemos limitar as chamadas do sistema que estão disponíveis e impedir que o componente em área restrita acesse diretamente o driver do kernel. O Sandboxing garantirá que todos os controles tenham que passar pela nossa API.”
A API 3A, combinada com a abordagem de sandboxing da libcamera, pode encorajar mais fornecedores de SoC a expor ainda mais seus ISPs, assim como alguns começaram a abrir suas GPUs.
“Queremos que os fornecedores publiquem drivers de câmera de código aberto que exponham e documentem todos os controles do dispositivo”, disse ele.
“Quando você está interagindo com uma câmera, uma grande parte desse código é independente do dispositivo.”
“Os fornecedores implementam uma HAL de câmera de origem completamente fechada e fornecem seu próprio gerenciamento de buffer e localização de memória e outras tarefas que não adicionam nenhum valor.”
“É um desperdício de recursos. Queremos o máximo possível de código que possa ser reutilizado e compartilhado com os fornecedores.”
Pinchart descreveu o gerenciador de dispositivos de câmera da libcamera, que suportará hot plug e desconexão de câmeras.
Ele também explicou o manipulador de pipeline da libcamera, que controla o buffer de memória e as comunicações entre o MIPI-CSI ou outras interfaces do receptor da câmera e o ISP da câmera.
“Nosso manipulador de pipeline cuida dos detalhes para que o aplicativo não precise”, disse Pinchart.
“Ele lida com agendamento, configuração, roteamento de sinais, número de fluxos e localização e passagem de buffers.”
O manipulador de pipeline é flexível o suficiente para suportar um ISP com um receptor CSI integrado (e sem um buffer pool) ou outros ISPs complicados que podem tem um pipeline direto para a memória.
Resumindo: Libcamera poderá aliviar as dores de cabeça com câmeras no Linux.
Veja toda a palestra do ELC de Pinchart no vídeo abaixo:
A propósito, o cara faz slides usando asci… Percebeu? 🙂
O que está sendo falado no blog
- Guix System Distribution 0.16 lançado – Confira as novidades e baixe
- Google Chrome 71 lançado com o bloqueio de publicidade enganosa e mais
- Libcamera poderá aliviar as dores de cabeça com câmeras no Linux
- FreeNAS 11.2 lançado – Confira as novidades e baixe
- Adobe corrigiu uma falha do Flash Player multiplataforma
