Transmissão / transmissão de vídeo ao vivo para a rede local (sem VLC)

Question

Estou tentando fazer com que uma webcam móvel perfeita atenda às minhas necessidades com o RPI e o módulo de câmera que já tenho aqui. Eu corro Arch tanto no RPI quanto no Laptop que pretendo como o "cliente". Eu tenho a cam correndo e posso canalizar seus dados de raspivid em algum lugar, e eu sou capaz de ssh e para trás.

Agora estou tentando fazer com que a transmissão via rede local funcione. Idealmente, eu iniciaria o script "servidor" no RPI e seria capaz de conectar tantos clientes quantas vezes eu quisesse até decidir fechar o servidor novamente. E, idealmente, o atraso de ter um dispositivo separado e transmissão sem fio é quase imperceptível para que eu não precise compensar e tentar sincronizar vídeo e áudio. Então, pelo que li, usar o VLC está fora de questão. Também idealmente, o "cliente" disponibilizaria o fluxo como /dev/video1 ou qualquer outra coisa - embora atualmente eu queira colocá-lo na OBS de alguma forma .

Até agora, tentei seguir alguns tutoriais, particularmente envolvendo netcat , mas o processo foi interrompido imediatamente ou assim que uma desconexão aconteceu, pois não consegui reproduzir o fluxo no cliente.

Alguma dica sobre onde procurar ou como planejar isso? Pensei em usar algo como um servidor de mídia para essa coisa de conexão (des) de cliente dinâmico, mas ela precisaria ser super leve.

    

Answer 1

Se você deseja transmitir um vídeo, use um protocolo criado para streaming de vídeo. O que significa UDP e multicast, para que você possa conectar quantos clientes quiser. Como com o TCP e o unicast, ele será interrompido assim que você se desconectar, conforme descobriu.

Esses protocolos existem, e. Existem RTSP , e implementações de servidor, por ex. icecast . Não é "super leve", mas deve funcionar bem em um RaspPi.

E não, você não quer disponibilizar o stream como /dev/video1 . Em vez disso, você deve usar um cliente que se conecte corretamente ao grupo multicast e, em seguida, apenas lerá o fluxo da rede.

Não sei exatamente o que você lê sobre o VLC e por que isso está fora de questão, mas o VLC (e a maioria dos outros videoplayers) como um cliente para um fluxo RTSP deve funcionar bem, e não deve ter problemas para sincronizar vídeo e áudio se o streaming for transmitido em sincronia (o que pode ser um problema dependendo de como o hardware está conectado ao RaspPi, mas você não disse nada sobre sua fonte de áudio em primeiro lugar).

Editar

Se você insiste no minimalismo, também pode usar ffmpeg para o stream de várias maneiras, mas você precisa investir um pouco de tempo para entender os protocolos envolvidos, suas diferenças e as opções de linha de comando necessárias para eles.

Editar

Ok, assisti ao vídeo (pelo menos no começo com VLC e latência, não gosto muito de assistir a vídeos).

É claro que haverá muita latência se você usar qualquer método decente de codificação - ele precisará de alguns quadros para codificar de maneira eficiente (e então ele precisará do mesmo número de quadros para decodificar). Além disso, ele economizará bastante para garantir que nada seja perdido.

Apenas por diversão, eu tentei ffmpeg com RTP em um grupo multicast, e eu também tenho muita latência (na ordem de 1-2 segundos com um H264, com a latência extra ffplay adiciona). Reduzir a latência é uma ciência em si e precisará de muitas opções (e de ler sobre elas). Mas ter latência não é um sinal de que algo está errado, pelo contrário.

Portanto, se você tiver um requisito de baixa latência absoluto, precisará compensar a compactação, o tamanho da imagem, a qualidade da codificação e a largura de banda. Se nada mais ajudar, remova a etapa de codificação.