Linux:上传未完成的文件 – 文件大小检查(scprsync)

Linux:上传未完成的文件 – 文件大小检查(scprsync),第1张

概述我通常最终会遇到以下情况:例如,我有一个来自相机的650 MB MPEG-2 .avi视频文件.然后,我使用ffmpeg2theora将其转换为Theora .ogv视频文件,比如说大小为150 MB.最后,我想将此.ogv文件上传到ssh服务器.比方说,ffmpeg2theora编码过程在我的电脑上花了大约15分钟.另一方面,上传速度约为60 KB / s

我通常最终会遇到以下情况:例如,我有一个来自相机的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 [email protected] "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 [email protected]:~/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分钟的总时间 – 即使尝试并行化):)

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

提前致谢,
干杯!最佳答案也许你可以尝试sshfs(http://fuse.sourceforge.net/sshfs.HTML).这是一个文件系统应该有一些优化虽然我不是很确定. 总结

以上是内存溢出为你收集整理的Linux:上传未完成的文件 – 文件大小检查(scp / rsync)全部内容,希望文章能够帮你解决Linux:上传未完成的文件 – 文件大小检查(scp / rsync)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/1048516.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-25
下一篇 2022-05-25

发表评论

登录后才能评论

评论列表(0条)

保存