El tee
comando lee de entrada estándar y copia a cualquier número de archivos más salida estándar por defecto, vea man tee
para más detalles. Esto significa que puede pedirle a tee que cree un archivo a partir de la entrada y luego canalice la salida a otra cosa.
La adición de una tubería adicional en teoría agrega un poco de ineficiencia. En cuanto a si esto es significativo o no, tendrá que juzgar por sí mismo utilizando su propio método de transmisión. Mi método actual no es satisfactorio a plena resolución. No es un gran interés en este momento, pero cuando lo sea, intentaré encontrar algo mejor (por ejemplo, supuestamente gstreamer funciona mejor que clvc).
Sin embargo, vale la pena señalar que el archivo guardado localmente en el pi al mismo tiempo es de calidad perfecta, por lo que la actividad no interfiere con raspivid. Aquí hay un ejemplo:
raspivid -o - -t 0 | tee test_video.h264 |
cvlc -v stream:///dev/stdin --sout '#standard{access=http,mux=ts,dest=:8080' :demux=h264
Rompí esto en dos líneas para facilitar la lectura; puede presionar return after |
(pipe) y finalizar el comando tal como puede romper una línea \
. Puedes reemplazarlo cvlc
con lo que quieras. Una vez más, aunque el flujo era de baja calidad, test_video.h264
salió perfecto.
Si bajo la resolución a 640x360, esta disposición está bien, con un segundo o dos de latencia, que es lo que normalmente obtengo. No creo que la tee
segunda tubería haga alguna diferencia en la calidad de la transmisión; Estos son capaces de un rendimiento mucho mayor que el necesario aquí y no requieren mucho en cuanto a recursos del sistema.
La CPU funcionó al 35-45%, que es lo mismo que cuando se transmite video sin tee
.
raspivid
, podríatee
enviar la salida a un archivo y gstreamer o cualquier otra cosa (verman tee
). Siempre y cuando una transmisión sea directa al disco, no agregará mucha sobrecarga, pero si desea procesar la entrada en dos formatos diferentes simultáneamente, creo que será demasiado trabajo para el pi.