關於多媒體檔案處理 pipeline 的一些事情
圖片／影片上傳是大多數服務都會需要的功能，但處理多媒體檔案的架構其實是蠻麻煩的事情。
架構一：收到檔案之後直接拿來用
如果伺服器在收到檔案之後直接拿來使用當然是最快也最輕鬆的。如果經營的是雲端硬碟那好像也沒什麼問題。但如果是要分享給他人的東西⋯⋯：
- 使用者上傳的檔案多半都很大：一般手機拍攝的照片大約在 2~4MB 不等，影片可以到 512MB~1GB。網路流量費用跟儲存費用都會相當可觀。
- 不同系統對格式的支援不同：分享圖片或影片的最大原因還是希望讓其他人看。可惜現在已經不是以前那個只有 jpeg 的時代了，A 拍攝的照片用 B 的手機不一定能看，B 拍攝的影片 A 也不一定能播。
- EXIF：手機拍攝的照片跟影片多半有 GPS 標記跟一些比較私人的裝置資訊。雖然 iPhone 上傳檔案時可以選擇不要包含位置資訊，但⋯⋯
誰會花時間按那個。
架構二：收到檔案之後先轉檔再放行
這個是蠻多服務會選擇的方式。在使用者上傳圖片之後先轉成 jpeg/png，再放到網路上。大部分圖片都可以在幾秒以內轉檔完成，對伺服器來說不是什麼問題。
可惜影片的狀況不一樣。video encoding 的計算單位不是秒，是倍。一個 N 秒的影片需要 N 的幾倍時間才能處理完成。很明顯的，發一篇文章要等數十秒的上傳時間＋數百秒的處理時間不是很理想的做法。
目前 Mosir 的架構：樂觀混合模式
- 上傳前可以轉檔就先轉檔
- 上傳完成後如果可以，稍微處理後使用（格式支援度優先，稍微大一點也沒關係）
- 在有空的時候再把檔案拿出來慢慢壓縮
這樣大約可以讓 80% 的檔案在極短的時間內完成上傳，並且確保所有人的裝置都可以觀看這個圖片／影片。而且，API server 也不用花費珍貴的 CPU 處理轉檔問題。
可是樂觀混合模式的問題也很明顯。使用者能夠上傳的檔案格式越多，能夠直接使用的機率就越低。可以預期這個是接下來一段時間會需要頭痛的問題。