第一個部落格，竟然是這麼一個傷心的故事，哈哈哈。

10月30號，參加百度面試

先記一把流水賬：

開始進入面試的節奏很快，坐著後還沒怎麼熱身，就開始了

首先就是自我介紹，這個千篇一律，我的自我介紹也沒什麼亮點，基本就是畢業哪裡，在學校期間研究的啥（現在回想起來在學校沒有潛下心研究某一個方向，真是浪費太多時間了），現在在哪裡幹，工作內容大概包括哪些（按照時間軸理一理），然後此部分就結束了，面試的帥哥感覺基本沒聽，手裡拿著估計是hr整理的簡歷看了看。

第二部分就是開始專業方向的面試了

面（面試官）： 目前工作都是使用的什麼協議

我： DASH、HLS。

面： 大致介紹一下DASH的工作流程吧

我： DASH可以由標準的web伺服器提供服務，終端請求的時候要依次請求mpd、init分片、媒體分片，其中mpd中描述了各個位元速率的視訊和音訊，記錄init分片和媒體分片的url格式；init中描述了視訊和音訊的元資訊，最重要的包括編碼格式、引數等等；媒體分片中記錄了詳細的幀資訊。對於直播場景的話，客戶端會不斷的請求mpd從而重新整理最新的分片資訊。

面： DASH只支援MP4格式嗎

我： 不是，ts也是同樣支援的

面： 簡單介紹一些mp4的封裝格式吧

我： mp4格式是由一個個box組成，box之間可以巢狀，基本的box包括size、type和資料欄位，full box還會包括version和flags資訊。其中box中比較關鍵的box如mvhd、moov、tkhd、mvhd、minf、stbl、stsd等。其中stsd中會記錄編碼的方式和引數等

面： 那你知道sps、 pps這些資訊是儲存在哪個box裡的嗎

我： 嗯。。。，sps和pps應該是放在stsd中（有點印象，卻又拿不準，回來後查閱了一下資料，一般264編碼的都是放在NALU header中的，這個NALU header是和幀放在一起的，但是MP4是將sps、pps放在stsd->avcc這個box中）。

面： 你知道dash和hls的播放要求是什麼嗎，比如下載多少個分片的時候才可以播放。

我： 額。。。這個不清楚（這個是一般是在協議裡會說明，協議還是要多看看，平常只看了部分的dash協議，hls的基本沒看，這個失誤比較大，hls的市場佔有率最高，但是自己卻基本不知道基本的協議）

面： 影響直播觀看體驗的的指標包括哪些，如何針對做優化呢？

我： 典型的指標包括起播時延、卡頓、花屏等等，以起播時延來說，可以在服務端處理完請求後，以比較快的速率進行發包。（這裡忘記了直播場景最重要的一個指標--端到端時延，囧啊）

面： 能說下hls和dash相比一些不同點嗎？

額。。。一下子蒙了，平常沒咋考慮過這個問題，一下子只說出無關痛癢的相同點，確實很像，面試官還提示了一下，可以從封裝格式等方面考慮。（後來查閱一下資料，大概包括以下幾點：1、dash的端到端時延小，切換位元速率的時候也比較快，hls的協議建議10s分片，但是dash沒有，可以任意長度，因此端到端時延，hls至少會超過10s，甚至幾十s都有可能，但是dash的分片如果切得比較短，可以使得dash的端到端時延降低，同時切換的時候也可以更快的下載到播放所需要的分片；2、dash的不同位元速率的視訊和音訊可以自由組合。dash中的視訊和音訊分都可以有不同的位元速率，因此客戶端可以根據網路情況自行決定使用什麼位元速率的視訊和音訊，但是hls的視訊和音訊是揉在一起的形成分片，因此切換位元速率的時候是視訊和音訊同時切換；3、mp4封裝的視訊格式冗餘資料比較少，ts因為會有很多相同的PAT、PMT等資訊，使得本來188個位元組的ts包會有大量的頭資訊，導致真正的媒體資訊較少，會造成比較大的流量浪費；但換個角度來說，這同樣也是它的優點，因為ts最開始是使用在廣電領域，需要媒體能很快播放，每個ts包裡都攜帶了播放視訊的元資訊，因此僅需要少量的ts包即可播放，但是mp4是以box為單位，moov和moof必須完整收到後才能播放，否則是無法解析的；綜合來說，各有利弊吧，可能需要參考具體的使用場景。4、在切iso時，因為mp4和iso封裝的時候基礎環境比較相似，所以切片的成本比較低，但是ts的成本就比較高；5、ts天生就是為了流式播放而生，因此播放的時候不會有畫面間斷等問題，但是mp4的封裝難以做到無縫銜接，可能會有影響體驗的問題）。

面： dash的音視訊分離的優點？

我： 一方面音視訊的位元速率可以自由組合，另一方面可能存在僅需要音訊或者僅需要視訊的場景，這樣dash就可以節省頻寬

面： 知道客戶端切換位元速率的演算法嗎？

我： 不知道。。。（好尷尬，只知道影響因素包括頻寬、丟包率、響應時間等）

面： hls是不是也可以做音視訊分離？（這個問題記不清面試官問沒問了，反正我在這裡問一下自己吧，全當記錄一下了）

我： v3版本的是音視訊mux的，但是v4版本支援音視訊分離

面： ts封裝格式清楚嗎？

我： 額。。。基本不知道。。。。

面： 沒用過C++是吧，那你就用C實現一個小演算法，將矩陣順時針旋轉一下，儘量將實現寫得詳細一點

剛拿到這個題，腦袋依然有點蒙，一下子沒反應過來，簡單在紙上畫了畫，從外圈到裡圈，一層層去旋轉，旋轉的方法就是數值交換，換了第一行後，發現這個矩陣變亂了，頓時懷疑自己方向錯了，然後又緊張起來，和麵試官交流了下，看看有沒有提示之類的，面試官說按照你剛才那個思路就挺好的，繼續往下走走看。然後我就繼續硬著交換，快把一圈交換完的時候豁然開朗了。但是來來回回已經浪費太多時間，所以理清楚了思路之後就和麵試官說一下大致思路，balabala，然後這道題就這麼算了，面試官也就沒有讓我具體在紙上徒手寫程式碼了。

面：多執行緒寫過吧，實現一個容器，要是執行緒安全的，包括向容器裡新增新值的put方法和取出值的get方法，同時要求如果容器滿的話，呼叫put方法的執行緒要阻塞，直到容器非滿時恢復執行緒。

本來不是多複雜的題，但是一開始想想由於C++不熟，不知道容器怎麼用，因此和麵試官交流了下，涉及到基本容器的部分能不能用簡單的方法表示，並且使用queue表示佇列，得到肯定的答案後就開始考慮put和get方法。主要思路就是先要定義兩個鎖，put鎖和get鎖（實際寫的時候忘記鎖初始化了），put的時候先將put鎖鎖住，然後檢查queue是否為空指標，然後檢查queue是否已滿，如果已滿，則迴圈等待、檢查，要加上usleep，並且設定超時時間；如果非滿，則入隊，解鎖，同時需要注意異常返回的時候需要解鎖；get方法類似，首先將get鎖枷鎖，然後檢查佇列是否為空指標，然後檢查大小是否為0，非0的話則出隊一個元素返回，最後解鎖，同樣需要在異常場景解鎖。但是實際寫在紙上的程式碼由於沒有完全考慮異常場景，導致程式碼比較亂，這一點做的很不好。

剛寫完的時候外面有個兄弟說這個會議室是他們定的，然後我們就要轉戰另一個會議室，然後我就給面試官講我的實現，面試官始終沒說什麼，一直是嗯嗯嗯，我也猜不透。。。

說完實現之後，面試官就告訴我說今天的面試就到此結束了，你先回去吧（憂傷一下下）

和麵試官一起下樓的時候，和麵試官聊了一下，通過面試，覺得哪些地方還需要加強，面試官說深度還不夠，還需要再努把力。

流水賬到此結束。

總結一下吧：

1、視訊行業專業性比較強，需要有一定的知識儲備才行，基本的hls、dash協議、mp4、ts格式，編解碼格式，他們的演進歷史、區別，優缺點等等，還是要好好看看，並總結、對比一下的。雖說自己已經在某廠的視訊cdn部門幹了一年多，但是實際接觸到視訊的時間可能只有3、4個月，很多時間都是在做無用功，對於很多東西都是淺嘗輒止，蜻蜓點水般，這一點對於做技術的人來說，已經很致命了，很容易就導致自己淪為打雜的。

2、對於第一題演算法題，本來是挺簡單的題目，但是因為考慮了過程中問題變複雜了，然後就懷疑自己的思路錯了，沒有堅持走完一遍，差點導致放棄做這一題。

3、最後一題的多執行緒題，一方面自己的實現不完整，另一方面鎖都忘記初始化了。這兩點其實可以從平常的工作中就能找到原因： 在廠裡工作，基本上所有的需求，都可以在已有的程式碼上覆制、貼上、修改修改即可，這就是另外一個致命的問題，比如複製了100行程式碼，可能其中30行是自己寫的，但是另外70行都是別人的，而且可能複製的部分都是最關鍵的，這就導致程式碼複製完了，只知道其中一小部分的實現，整體的實現似懂非懂；在廠裡工作，基本的字串、資料結構、執行緒的操作都是封裝好的，我們只需要呼叫巨集很或者方法即可，這就會導致另外兩個問題：1、 基本的glibc的函式可能都不知道叫啥名字，離開了這些封裝好的方法，我們可能都不會寫程式碼了；2、高手在封裝這些方法的時候可能使用了很多的技巧，但是我們卻對這些技巧不可見。因此，在之後的寫程式碼的過程中，還是儘量少copy程式碼，老程式碼儘管是穩定，好用，但是不利於自己編碼水平的至發展，至少也要是自己先實現一遍了，然後再對比一下才能知道出別人實現的優勢。說到這個問題，還可以再擴充套件一下，就是如何對待開原始碼的問題，開源大法固然好，但是副作用也不小，需要自己把握這裡面的度。

以上總結就是自己面試失敗的一點拙見。

這一課就叫擡頭看路吧