Linux:上传未完成的文件 - 带文件大小检查(scp/rsync)

Question

我通常最终会遇到以下情况:例如,我有一个来自相机的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小时; 也就是说,对于enc + upl的较小完成时间似乎没有任何好处.(虽然这可能是由于网络拥塞,而且我当时的网络速度降低了 - 在我看来,它ffmpeg2theora必须等待它通过管道发送的每一小块数据的确认,并且ACK最终必须来自ssh...否则,ffmpeg2theora无法提供完成时间估算.然后,也许估计是错误的,而操作确实会在45分钟内完成 - 不知道,从来没有耐心等待和时间过程; 我只是在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,使得.ogv文件总大小在当时scp已经退出20 MB (完成前5 MB的传输).

然后我学会了(joen.dk»提示:scp简历)rsync支持部分完成上传的"恢复",如:

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

...,所以我尝试使用rsync而不是scp- 但它似乎与scp文件大小完全相同,即:它只会转移到在进程开始时读取的文件大小,然后它将出口.

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

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

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

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

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

提前谢谢,
干杯!

Answer 1

也许你可以尝试 sshfs (http://fuse.sourceforge.net/sshfs.html)。这是一个文件系统应该有一些优化，尽管我不太确定。