Linux：上传未完成的文件 – 文件大小检查(scp / rsync)

我通常最终会遇到以下情况：例如,我有一个来自相机的650 MB MPEG-2 .avi视频文件.然后,我使用ffmpeg2theora将其转换为Theora .ogv视频文件,比如说大小为150 MB.最后,我想将此.ogv文件上传到ssh服务器.

比方说,ffmpeg2theora编码过程在我的电脑上花了大约15分钟.另一方面,上传速度约为60 KB / s,大约需要45分钟(150MB .ogv).所以：如果我先编码,并等待编码过程完成 – 然后上传,则需要大约

15 min + 45 min = 1 hr

完成操作.

所以,我认为如果我能以某种方式开始上传,与编码操作并行,那会更好;那么,原则上 – 因为上传过程比传输的字节数/秒更慢(按照生成的字节数/秒) – 上传过程总是“落后”编码的过程,所以整个操作(enc upl)将在45分钟内完成(即上传过程的时间/ – 几分钟取决于线路上的实际上传速度情况).

我的第一个想法是将ffmpeg2theora的输出传递给tee(以便保留.ogv的本地副本),然后将输出进一步传递给ssh – 如下所示：

./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 -o /dev/stdout MVI.AVI | tee MVI.ogv | ssh user@ssh.server.com "cat > ~/myvids/MVI.ogv"

虽然这个命令确实具有功能 – 人们可以很容易地从ffmpeg2theora中查看终端中的运行日志,在这种情况下,ffmpeg2theora计算预计完成时间为1小时;也就是说,对于两个包含的完成时间来说似乎没有任何好处. (虽然这可能是由于网络拥塞,而且我当时的网络速度越来越低 – 在我看来,ffmpeg2theora必须等待它通过管道发送的每一小块数据的确认,ACK最终必须来自ssh …否则,ffmpeg2theora将无法提供完成时间估计.然后,也许估计是错误的,而操作确实会在45分钟内完成 – dunno,从未有过耐心等待和时间过程;我只是在1小时生气,估计,并按Ctrl-C;)…)

我的第二次尝试是在一个终端窗口中运行编码过程,即：

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

…,以及在另一个终端窗口中使用scp的上传过程(从而’强制”并行化’)：

scp MVI.ogv user@ssh.server.com:~/myvids/

这里的问题是：让我们说,在scp启动时,ffmpeg2theora已经编码了5 MB的输出.ogv文件.此时,scp将此5 MB视为整个文件大小,并开始上传 – 当它遇到5 MB标记时退出;而在此期间,ffmpeg2theora可能产生了额外的15 MB,使得.scv文件在scp退出时总大小为20 MB(完成前5 MB的传输).

然后我了解到(joen.dk ? Tip: scp Resume)rsync支持部分完成上传的“恢复”,如：

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

…,所以我尝试使用rsync而不是scp – 但它在文件大小方面似乎与scp完全相同,即：它只会传输到在进程开始时读取的文件大小,并且然后它会退出.

所以,我对社区的问题是：有没有办法并行化编码和上传过程,以便减少总处理时间？

我猜可能有几种方法,如：

>命令行选项(我还没有看到)强制scp / rsync连续检查文件大小 – 如果文件打开以供另一个进程写入(那么我可以简单地在另一个终端窗口中运行上载)
>一个bash脚本;比如在while循环中运行rsync –partial,只要.ogv文件被另一个进程打开就可以运行(我实际上并不喜欢这个解决方案,因为我可以听到硬盘扫描恢复点,每个时间我运行rsync –partial – 我想,这可能不是很好;如果我知道同时写入同一个文件)
>支持上传“当前生成的”/“未完成”文件的不同工具(scp / rsync除外)(假设它只能处理不断增长的文件;如果遇到本地文件突然减少,它会退出大小比已传输的字节数大)

…但它也可能是,我忽略了一些东西 – 1小时就好了(换句话说,它可能在逻辑上不可能达到45分钟的总时间 – 即使尝试并行化):)

好吧,我期待着有希望为我澄清这一点的评论;)

提前致谢,
干杯!