servidores - Linux: cargando archivos sin terminar-con verificación de tamaño de archivo(scp/rsync)

scp linux (1)

Por lo general, termino en la siguiente situación: Tengo, digamos, un archivo de video MPEG-2 de 650 MB de una cámara. Luego, uso ffmpeg2theora para convertirlo en el archivo de video Theora .ogv, digamos unos 150 MB de tamaño. Finalmente, quiero subir este archivo .ogv a un servidor ssh .

Digamos que el proceso de codificación ffmpeg2theora toma unos 15 minutos en mi PC. Por otro lado, la carga continúa con una velocidad de alrededor de 60 KB / s, lo que lleva unos 45 minutos (para los 150MB .ogv). Entonces, si primero codifico y espero a que termine el proceso de codificación, y luego lo cargue, tomaría aproximadamente

15 min + 45 min = 1 hr

para completar la operación

Entonces, pensé que sería mejor si de alguna manera pudiera comenzar la carga, en paralelo con la operación de codificación; luego, en principio, dado que el proceso de carga es más lento ( en términos de bytes transferidos / seg ) que el de codificación ( en términos de bytes generados / seg ), el proceso de carga siempre "iría detrás" de la codificación, y entonces la operación completa (enc + upl) se completará en solo 45 minutos (es decir, justo el tiempo del proceso de carga +/- algunos minutos dependiendo de la situación de velocidad de carga real en el cable).

Mi primera idea fue ffmpeg2theora la salida de ffmpeg2theora a tee (para mantener una copia local de .ogv) y luego, conectar la salida a ssh , como en:

./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 -o /dev/stdout MVI.AVI | tee MVI.ogv | ssh [email protected] "cat > ~/myvids/MVI.ogv"

Si bien este comando sí funciona, se puede ver fácilmente en el registro en ejecución en el terminal de ffmpeg2theora , que en este caso, ffmpeg2theora calcula que el tiempo de finalización previsto es de 1 hora; es decir, parece que no hay beneficio en términos de menor tiempo de finalización para enc + upl. ( Si bien es posible que esto se deba a la congestión de la red, y que yo obtenga una velocidad de red menor en ese momento, me parece a mí, que ffmpeg2theora tiene que esperar un reconocimiento por cada pequeño fragmento de datos que envía a través de la tubería, y que ACK finalmente tiene que provenir de ssh ... De lo contrario, ffmpeg2theora no habría podido proporcionar una estimación de tiempo de finalización. Por otra parte, tal vez la estimación es incorrecta, mientras que la operación se completaría en 45 minutos - no sé, nunca tuvo paciencia para esperar y cronometrar el proceso; me cabreo a 1 hora como estimación y presiono Ctrl-C;) ... )

Mi segundo intento fue ejecutar el proceso de codificación en una ventana de terminal, es decir:

./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 MVI.AVI # MVI.ogv is auto name for output

..., y el proceso de carga, usando scp , en otra ventana de terminal (por lo tanto ''forzando'' ''paralelización''):

scp MVI.ogv [email protected]:~/myvids/

El problema aquí es: digamos, en el momento en que se inicia scp , ffmpeg2theora ya ha codificado 5 MB del archivo .ogv de salida. En este momento, scp ve estos 5 MB como el tamaño completo del archivo, y comienza a cargar, y sale cuando encuentra la marca de 5 MB; mientras tanto, ffmpeg2theora puede haber producido 15 MB adicionales, por lo que el archivo .ogv tiene 20 MB de tamaño total en el momento en que scp ha salido ( terminando la transferencia de los primeros 5 MB ).

Luego aprendí ( joen.dk »Sugerencia: scp Resume ) que rsync admite ''reanudar'' las cargas completadas parcialmente, como en:

rsync --partial --progress myFile remoteMachine:dirToPutIn/

..., intenté usar rsync lugar de scp , pero parece comportarse exactamente igual que scp en términos de tamaño de archivo, es decir: solo se transferirá al tamaño de archivo leído al comienzo del proceso, y entonces saldrá

Entonces, mi pregunta a la comunidad es: ¿hay alguna forma de paralelizar el proceso de codificación y carga, para obtener la disminución en el tiempo de procesamiento total?

Supongo que podría haber varias formas, como en:

Una opción de línea de comando (que no he visto) obliga a scp / rsync a verificar continuamente el tamaño del archivo, si el archivo está abierto para escritura en otro proceso ( entonces simplemente podría ejecutar la carga en otra ventana de terminal )
Un script bash; digamos corriendo rsync --partial en un ciclo while, que se ejecuta mientras el archivo .ogv esté abierto para escritura por otro proceso (en realidad no me gusta esta solución, ya que puedo escuchar el disco duro escaneando el punto de reanudación, cada vez que ejecuto rsync --partial - que, supongo, no puede ser bueno, si sé que se está escribiendo el mismo archivo al mismo tiempo )
Una herramienta diferente (que no sea scp / rsync ) que admite la carga de un archivo "generado actualmente" / "inacabado" ( suponiendo que solo puede manejar archivos crecientes; se cerraría si detecta que el archivo local está repentinamente menos en tamaño que los bytes ya transferidos )

... pero también podría ser, que estoy pasando por alto algo, y 1hr es lo mejor posible (en otras palabras, es lógicamente imposible lograr un tiempo total de 45 minutos, incluso si se trata de paralelizar) :)

Bueno, espero con interés los comentarios que, con suerte, aclarar esto para mí;)

Gracias por adelantado,
¡Aclamaciones!

Puede ser que puedas probar sshfs (http://fuse.sourceforge.net/sshfs.html). Este es un sistema de archivos que debería tener cierta optimización, aunque no estoy muy seguro.