我通常最終會遇到以下情況：例如,我有一個來自相機的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的傳輸).

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

…,所以我嘗試使用rsync而不是scp – 但它在文件大小方面似乎與scp完全相同,即：它只會傳輸到在進程開始時讀取的文件大小,并且然后它會退出.

所以,我對社區的問題是：有沒有辦法并行化編碼和上傳過程,以便減少總處理時間？

我猜可能有幾種方法,如：

>命令行選項(我還沒有看到)強制scp / rsync連續檢查文件大小 – 如果文件打開以供另一個進程寫入(那么我可以簡單地在另一個終端窗口中運行上載)

>一個bash腳本;比如在while循環中運行rsync –partial,只要.ogv文件被另一個進程打開就可以運行(我實際上并不喜歡這個解決方案,因為我可以聽到硬盤掃描恢復點,每個時間我運行rsync –partial – 我想,這可能不是很好;如果我知道同時寫入同一個文件)

>支持上傳“當前生成的”/“未完成”文件的不同工具(scp / rsync除外)(假設它只能處理不斷增長的文件;如果遇到本地文件突然減少,它會退出大小比已傳輸的字節數大)

…但它也可能是,我忽略了一些東西 – 1小時就好了(換句話說,它可能在邏輯上不可能達到45分鐘的總時間 – 即使嘗試并行化):)

好吧,我期待著有希望為我澄清這一點的評論;)

提前致謝,

干杯!

總結

以上是生活随笔為你收集整理的linux 上传网页文件大小,Linux：上传未完成的文件 – 文件大小检查(scp / rsync)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。