我通常最终遇到以下情况：例如，我有一个来自相机的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的较小完成时间而言似乎有 no 的好处。 （虽然这可能是由于网络拥塞，而我当时的网络速度较慢 - 在我看来，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，使.ogv文件在scp退出时总大小为20 MB（完成前5 MB的传输< / em>的）。
然后我了解到rsync rsync --partial --progress myFile remoteMachine:dirToPutIn/
支持部分完成上传的“简历”，如：
rsync ...，所以我尝试使用scp代替scp - 但就文件大小而言，它似乎与scp完全相同，即：它只会转移到在过程开始时读取的文件大小，然后它将退出。
所以，我对社区的问题是：有没有办法并行化编码和上传过程，以便减少总处理时间？
我猜可能有几种方法，如：
rsync / rsync --partial强制while / rsync --partial连续检查文件大小的命令行选项 - 如果文件打开以供另一个进程写入（那么我只需在另一个终端窗口中运行上传）scp循环中运行rsync，只要.ogv文件被另一个进程打开就可以运行（我实际上并不喜欢这个解决方案，因为我可以听到硬盘扫描恢复点，每次我运行{{1}} - 我想，这可能不是很好;如果我知道同时写入同一个文件）...但也可能是，我忽略了一些东西 - 1小时就好了（换句话说，在逻辑上不可能达到45分钟的总时间 - 即使尝试并行化） :)
嗯，我期待着有希望为我澄清这一点的评论;）
提前致谢，
干杯！
答案 0 :(得分：0)
可能你可以尝试sshfs（http://fuse.sourceforge.net/sshfs.html）。这是一个文件系统应该有一些优化虽然我不是很确定。