O tee
comando lê da entrada padrão e copia para qualquer número de arquivos, além da saída padrão por padrão; consulte man tee
para obter mais detalhes. Isso significa que você pode pedir ao tee para criar um arquivo a partir da entrada e depois direcionar a saída para outra coisa.
A adição de um tubo extra em teoria adiciona um pouco de ineficiência. Se isso é significativo ou não, você terá que julgar por si mesmo usando seu próprio método de streaming. Meu método atual não é satisfatório em resolução total. Não é um grande interesse no momento, mas quando for, tentarei encontrar algo melhor (por exemplo, supostamente o gstreamer funciona melhor que o clvc).
No entanto, vale ressaltar que o arquivo salvo localmente no pi ao mesmo tempo é de qualidade perfeita, para que a atividade não interfira no raspivid. Aqui está um exemplo:
raspivid -o - -t 0 | tee test_video.h264 |
cvlc -v stream:///dev/stdin --sout '#standard{access=http,mux=ts,dest=:8080' :demux=h264
Eu quebrei isso em duas linhas para facilitar a leitura; você pode pressionar return after |
(pipe) e finalizar o comando da mesma maneira que pode quebrar uma linha \
. Você pode substituir o cvlc
com o que quiser. Novamente, embora o fluxo tenha sido de baixa qualidade, test_video.h264
saiu perfeito.
Se eu abaixar a resolução para 640x360, esse arranjo é bom, com um ou dois segundos de latência que é normalmente o que recebo. Não acho que o tee
ou o segundo tubo faça alguma diferença na qualidade do fluxo; eles são capazes de uma taxa de transferência muito maior do que o necessário aqui e não exigem muito em termos de recursos do sistema.
A CPU funcionou entre 35 e 45%, o mesmo que ocorre ao transmitir vídeo sem tee
.
raspivid
poderátee
enviar para um arquivo e gstreamer ou qualquer outra coisa (consulteman tee
). Contanto que um fluxo seja direto para o disco, isso não sobrecarregará muito, mas se você quiser processar a entrada em dois formatos diferentes simultaneamente, acho que haverá muito trabalho para o pi manipular.