我通常最终会遇到以下情况：例如，我有一个来自摄像机的650 MB MPEG-2 .avivideo文件。 然后，我使用ffmpeg2theora将其转换成Theora .ogvvideo文件，比如大小为150 MB。 最后，我想将这个.ogvfile upload到一个ssh服务器。
比方说，我的电脑上ffmpeg2theora编码过程需要15分钟左右。 另一方面，上传速度大约为60 KB / s，大约需要45分钟（对于150MB .ogv）。 所以：如果我第一次编码，并等待编码过程完成 – 然后上传，这将需要大约
15 min + 45 min = 1 hr
完成操作。
所以，我认为如果我能以某种方式开始上传，与编码操作并行 ，会更好; 那么原则上 – 因为上传过程比传输的字节/秒更慢（ 以传输的 字节/秒计 ），所以上传过程总是在编码之后“落后”，所以整个操作（enc + upl）只需45分钟即可完成（也就是上传过程的时间+/-几分钟，取决于实际上传速度情况）。
我的第一个想法是将ffmpeg2theora的输出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"
虽然这个命令的确的function – 在ffmpeg2theora的terminal运行日志中可以很容易地看到，在这种情况下， ffmpeg2theora计算完成的预测时间为1小时; 也就是说，对于两个国家来说，在较短的完成时间方面似乎没有任何好处。 （ 虽然这可能是由于networking拥塞，而我在这个时候获得的networking速度较低 – 在我看来， ffmpeg2theora必须等待通过pipe道发送的每一小块数据的确认，并且ACK最后必须来自ssh …否则， ffmpeg2theora将不能提供完成时间估计。然后，也许估计是错误的，而操作确实会在45分钟内完成 – 不知道，从来没有耐心等待和过程的时间;我只是在估计1小时生气，并按Ctrl-C;）… ）
我的第二个尝试是在一个terminal窗口中运行编码过程，即：
./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 MVI.AVI # MVI.ogv is auto name for output
…，以及在另一个terminal窗口中使用scp进行上传过程（从而“强制”“并行化”）：
scp MVI.ogv user@ssh.server.com:~/myvids/
这里的问题是：假设在scp开始的时候， ffmpeg2theora已经编码了5MB的输出.ogv文件。 这时， scp会把这个5 MB看作是整个文件的大小，然后开始上传 – 当它遇到5 MB的标记时就会退出; 而在此期间， ffmpeg2theora可能产生了额外的15 MB，从而在scp退出时完成了总大小为20 MB的.ogv文件（ 完成前5 MB的传输 ）。
然后，我学到了（ joen.dk»提示：scp恢复 ）， rsync支持部分完成上传的“恢复”，如下所示：
rsync --partial --progress myFile remoteMachine:dirToPutIn/
…，所以我尝试使用rsync而不是scp – 但它似乎在文件大小方面与scp完全相同，即：它只会传输到在进程开始时读取的文件大小，以及那么它将退出。
所以，我对社区的问题是：是否有一种方法来并行化编码和上传过程，以减less总处理时间？
我猜测可能有几种方法，如下所示：
scp / rsync连续检查文件大小 – 如果该文件是打开的由另一个进程写（ 然后我可以简单地在另一个terminal窗口上运行上传 ） while循环中运行rsync --partial ，只要.ogv文件被另一个进程打开就可以运行（ 我实际上并不喜欢这个解决scheme，因为我可以听到硬盘扫描的恢复点，每个我运行rsync --partial – 我想这个不行，如果我知道同一个文件正在同时写入的话 ） scp / rsync除外）（ 假设它只能处理正在增长的文件;如果遇到本地文件突然减less，大小比已经传输的字节大 ） …但是也可能是，我忽略了一些东西 – 而且一个小时就可以达到（换句话说，即使尝试并行化也可能在逻辑上达到45分钟的总时间）:)
那么，我期待这样的评论，希望能为我澄清这一点;）
提前致谢，
干杯!