雖然是個小主題，我想這個應該也不多人紀錄過，寫一下好了。

雖然是個小主題，我想這個應該也不多人紀錄過，寫一下好了。

 

 

這次 JSDC 議程影片紀錄的巧思回顧：

 

  這次的影片是由中研院協助的，裡面有看到講者子母的部份幾乎都是中研院弄的，

  他們有機器在錄時就當場作切換，考驗的是中研院的工作人員控影片的能力。

 

  當初中研院有告知大概需要 2-3 天處理時間，所以我禮拜一請強哥跟中研院聯絡，

  禮拜二去拿檔案。

 

 1.拿檔案

 

  然後他們存的是 720 * 480  xvid ,30 frames 的格式。基本上還算中規中矩....

 

  檔案大小總共 13g ，本來我是真的有跑一趟去中研院，不過我忘了當場驗檔，

  結果我回到家才發現我硬碟有狀況撈不出來，白白浪費我一個早上時間，

  後來本來是想再跑一趟的，不過跟強哥討論過後，

  決定還是他去 copy 檔案上傳到我的 ftp。 XD

 

  大概有一天的時間就在忙這件事情中消失。

 

 2.轉檔

  我對處理影片檔還算是有經驗的，以前自己有 dv 也常負責活動中影像後製的部份，

  對常見的 codec 之類的問題還蠻熟得，所以就有稍微作一點事。

 

 

  不過不知道為什麼我慣用的影片剪輯軟體

  （ Corel Visual Studio Pro X4 ，也就是我們熟知的繪聲繪影），

  對這個 xvid 格式檔案支援得很糟，只要一把影像切段，

  後面的片段就沒有聲音，後面編輯時播放的操作速度也相當慢。

 

  當然沒有 H264 慢（我有試著轉成 H264，根本打不開就直接當掉了），

  後來是先用 Any Video Converter 轉成  mpeg ，再用 mpeg 進行真正的影片剪輯。

 

  轉 mpeg 沒有想像中慢，大概一分鐘影片，

  只需要 30秒或者更短就可以處理好，所以全部檔案轉檔完大概只用四小時。

 

  而且繪聲繪影弄 mpeg 的東西超快，包含 output 都超快，

  30min 剪好轉出大概只需要 5min 不到，當然這跟硬體也有關系。

 

  然後一邊轉檔就一邊就轉好的部份進行剪接，剪好就輸出上傳，

  那兩天基本上就是在同時至少都在作兩件事情（剪檔跟上傳）上度過。

 

  3.上傳

 

   上傳時我 youtube 忘了先作手機認證，

   結果上傳1.9G 的影片就被 youtube 砍掉了。

                                          （砍掉了。砍掉了。。砍掉了。。。回音）

 

    這大概是唯一的插曲，

    對了 Hinet 50m 網路還算蠻快的，下載 13G 、 上傳1xG 都還算順暢的完成，

 

 

  4.剪輯

  基本上我發現幾個問題

  A.從影片瀏覽者角度而言，一開始應該要有個大鋼之類的東西，

     讓使用者瞭解他在那個 session 會比較理想

 

     這部份我是直接拉講者的講題截圖來前面頂著，沒有的就想辦法生。

 

  B.因為中研院是看狀況純手控，所以有時候畫面會只有人但手指著投影機說話，

     這時候我會幫他把畫面截上去自己人工作子母畫面。

 

     其中最經典的一場是 lightning talk 的閃光洽，因為大概因為畫面一直亂跳得關係，

     它從頭到尾那場的錄影都在拍人，那一場的錄影投影片畫面是我純手工上的，

     所以有一些不搭的地方就見諒這樣。

 

  C.我想要保留介紹講者上台的掌聲歡樂效果，

     但是有時主持人介紹詞太長，那邊我有作點剪接。

 

  D.講者上台時有時會有接投影機接太久的狀況，那部份我也是後製處理掉了，

     對瀏覽線上影片的閱讀者而言，那不是重要得部份，

      除了某場 talk 那個投影機真的接太久接到有梗了，我有特別保留以外。

 

  E.Lightning talk 的個別 session 太短，感覺看起來不太夠味，

     我們考慮到整體效益，決定把所有 lightning talk 整合成一個影片。

 

     覺得這樣會有機會誘使使用者看更多的 lightning talk 片段，也算是個新嘗試，

     當然，議程連結我們都還是放到各 lightning talk 起始時間的秒數。

 

 5.字幕

      就觀眾而言，有沒有字幕其實差蠻多的，

      特別是這次議程時間緊湊，大部分的講者都講很快，

 

      有字幕明顯可以幫助閱讀，這也是沒作之前我不知道的，

      再讓我重來一次的話，我會把字幕列成 must have 。

 

 

      打字幕基本上有幾個方式：

 

     ＃邊聽邊打邊上時間：這是我一開始的方案

 

      因為我不想要義工另外下載影片上字幕，

      我試了幾個針對 youtube 影片上字幕的 solution ，

 

      一開始我決定要用 http://captiontube.appspot.com/ ，

      Jack 用他完成五十分鐘的字幕，但我後來自己打沒五分鐘我就放棄了。

 

      他有幾個嚴重 bug 

      1.某些情境下時間軸會錯  （這蠻誇張的）

      2.字幕容易重疊（這跟他時間軸 duration 設定的介面有關系）

      3.某些狀況下容易同一個時間上到多次同樣的字

      4.特殊字元(& < > ) 會被 escape ，還要手工轉回來

 

      解法： 1 只能靠手動解 ,

                2 可以用程式直接調時間間隔

                    (看這個 http://jsfiddle.net/Bnwdt/3/  for sub 檔)

                3 自己用眼睛掃出來的字幕看有大量重複的就砍砍砍

                4 搜 "&" 找字一一 replace  沒別的招了

 

    ＃先打逐字稿再上時間l：這是我後來的作法

       這樣有好處： 1. 打字快得可以專心打字  2. 上時間的不需要打字快的 

 

    i.打逐字稿

       但是講者還是講很快啊，我自己打字速度 100字/ min ，

       雖然不是專家但也算中上了，根本不可能作到不 pause 聽打。

 

       我後來是作以下的動作 （請用 chrome 操作，firefox 不知為啥沒得調速度）

           A.將 youtube 改用 html5 呈現

              http://www.youtube.com/html5

           B.並切換成 0.5 倍速聽打(Chrome only)

              http://screencast.com/t/ACOccoz8qHYN

 

       然後我差不多就可以維持打個三四分鐘才 pause 一次的速度，

       30 min 的 session 大概可以在 80 min 裡面打完。

 

       這裡的重點是，你要把逐字稿打成逐行，

       然後要稍微控制每行字數，因為使用者會按照你給的看，

       如果斷在奇怪的地方使用者也會一頭霧水。

 

       如果有聽不懂、聽不清楚的東西不要花太多時間，

        打個 (?) 帶過比較好，之後再回頭找人幫忙補。

 

       還有如果有中英文混雜的地方，英文前後建議有個半形空白隔開比較方便閱讀。

 

    ii.上時間

       http://accessify.com/tools-and-wizards/accessibility-tools/easy-youtube-caption-creator/

 

       我只能說這真是他媽的快.....（對不起我粗俗了，但這樣才能表達我心中的感動）

 

       打好逐字稿之後再一路聽一次一邊聽一邊 a 真的是飛快，

       通常都可以一次內直接完成。

 

    iii.不過 easy youtube caption 因為他是採取只給「結尾時間」的作法，

       所以太長的字幕（超過兩秒的）很有可能在還沒講完就消失了，

       所以還是需要用程式再處理過，把開始時間也補上去。

       （範例： http://jsfiddle.net/Bnwdt/1/ ）

 

    iv.打字幕可以非常非常深入的瞭解這個議程裡面的所有細節，

       學習效果 ＋＋ ，打字速度練習 ＋＋ ，非常鼓勵大家有興趣時試試打字幕。

 

       我自己的經驗是以我 100 字/min 的打字速度並且很瞭解講題的前提下，

       30min 的議程，大概需要 2.5 hr 去完成，這次我實際上負責約 80min 的議程字幕。

 

 

   6.影片清單 (playlist)

       對我來說，活動的每個 session 都很重要，怎麼讓使用者點一個 session 之後，

       快速找到其他他有興趣的 session 或者是有機會讓他們看到更多 session 。

 

       我是有想到可以再建立影片清單，作影片清單其實只要一下子，

       至於效果怎麼樣，要看使用者的意見才會知道了。

 

   7.議程問卷

       因為問卷剛好歸我管，我就想到說可能使用者當天沒聽到這場議程，事後才上網聽上網看，

       如果使用者有意見可以讓我們 feedback 給講者的話，也會是很棒的一件事情。

 

       這點就要看使用者真正的回饋是怎麼樣囉～很難說好或不好。

 

==========

總歸就是組合手上已知的幾個元素，試著讓整體效益盡量極大化。:)

 

這是臨時起意打得小文章，有一些細節如果沒講清楚或者有疑問，可以再問我。