海思源碼
① DevOps工具配置不當，微軟、任天堂、華為等50餘家名企源碼遭泄露
據外媒 BleepingComputer 報道，雹叢由於基礎架構配置有誤，來自技術、金融、電商、製造業等眾多領域的數十家知名公司源碼遭到泄露。
這些公司包括微軟、Adobe、聯想，AMD、高通，摩托羅拉、海思、任天堂、迪士尼、江森自控等，而且這一名單還在不斷增長中。
來自瑞士的開發者 Tillie Kottmann 通過各類第三方源收集到了這些漏洞，他自己也找到了不少 DevOps 工具中的配置錯誤，而這些工具可以用來訪問源代碼。
遭泄露的源碼被發布在 GitLab 上一個公開存儲庫中，並被標記為 「exconfidential」 （絕密），以及 「Confidential & Proprietary」（保密&專有）。
（更新：GitLab 倉庫均已被刪除，Kottmann 現採用 telegram 群組來公布這些信息。）
根據安全研究人員 Bank Security 提供的滲橋信息，該存儲庫中大約包含了超過 50 家公司的源碼。但有一源喊櫻些文件夾是空的，還有一些存在硬編碼憑證——一種創建後門的方式。
Kottmann 提到，一些代碼庫中確實存在硬編碼憑證，他在發布前已盡可能地將其刪除，「以避免造成直接傷害或是助長更大的破壞」。另外，他也坦承自己並未在發布前與每一家受影響的公司進行聯系，但他們確保自己「盡了最大的努力將負面影響最小化」。
目前，Kottmann 已應部分企業的要求刪除了代碼。例如 Daimler AG，梅賽德斯-賓士的母公司；聯想的文件夾也已經空空如也。針對有移除代碼要求的公司，Kottmann 表示願意遵守，並樂意提供信息，「幫助公司增強基礎架構的安全性」。
事實上，從收到的 DMCA 通知數量（估計至多 7 份）和法律代表等的聯系來看，許多公司仍對代碼泄露事件不知情。另有部分公司沒有撤除代碼的意思，甚至有公司覺得「挺有趣」，只想知道 Kottmann 是如何獲得代碼的。
此次泄露的代碼中，有一些項目早已由其原始開發者公開發布過，或是已經有很長時間不再更新和維護。網路安全公司 ImmuniWeb 的創始人兼首席執行官 Ilia Kolochenko 指出，「從技術角度來看，這次的泄露並不算很嚴重……若沒有每天的支持和改進，源代碼也會迅速貶值」。
盡管如此，這樣大規模的泄露事件原因還是值得引起注意。許多公司使用錯誤的 DevOps 工具配置，引發源碼暴露。Kottmann 及其團隊近期正在 探索 運行 SonarQube 的伺服器，他們發現，有成千上萬的公司由於未能正確保護 SonarQube 安裝而暴露了源碼。
對於泄露源碼的行為，安全專家 Jake Moore 對 科技 網站 Tom's Guide 表示，「失去對源代碼的控制就像將銀行藍圖交給搶劫犯一樣……受影響的網站應立即採取保護措施……若用戶在公司之前發現自己的數據遭到泄露，那無疑是在傷口上撒鹽」。
基於法律層面，Kolochenko 認為源碼發布者可能會因侵犯版權或違反計算機法而被起訴，但通常大型公司不會上訴，他們寧願從存儲庫中快速刪除源代碼並修復其內部 DevOps 安全流程。
為此，Kolochenko 建議「企業應修改並持續監控 DevOps 操作，將其轉換為敏捷的 DevSecOps」。
② live555移植到hi3516做rtsp伺服器
live555庫本身實現了做rtsp伺服器，客戶端可以通過rtsp客戶端訪問伺服器上的文件並播放，支持的文件格式如下:
本次任務實現了把live555移植到嵌入式海思晶元hi3516上做rtsp伺服器，除了支持客戶端播放伺服器上上面格式文件外，另添加了實時播放hi3516攝像頭圖像與音頻的功能。
live555源碼目錄如下:
四個基本的庫分別是:BasicUsageEnvironment, groupsock, liveMedia和UsageEnvironment。
編譯後即生成這4個庫文件:
這里我只簡單說下liveMedia庫的功能，其他三個庫是live555運行的基礎庫，太(mei)簡(yan)單(jiu),就不說了。
liveMedia庫包含了音視頻相關的所有功能，包含音視頻文件的解析，RTP傳輸封裝等，我們可以看到這個目錄下有對h264、AAC等文件解析的支持:
交叉編譯過程：略
這里我主要是修改mediaServer文件夾下的示常式序，添加實時預覽攝像頭圖像與mic聲音功能。
hi3516晶元，視頻編碼格式為h264,音頻編碼格式為AAC。
1.添加音頻AAC支持
添加類 ADTSAudioLiveSource ,繼承自FramedSource
在該類的doGetNextFrame函數里實現獲取hi3516音頻數據做為rtsp伺服器音頻源。
注意點：
1.1 adts默認是帶7位元組或者9位元組的頭，傳給rtsp的時候是要去掉頭的，實際上RTSP通過rtp傳輸AAC幀的時候是不帶adts頭的，而是帶4個位元組的mpeg4-generic頭。
1.2 從FramedSource繼承而來的變數
每次doGetNextFrame幀時，從FIFO里取一個完整的AAC幀，把幀拷貝到fTo buf裡面，然後比較幀大小與fMaxSize來賦值幾個關鍵的變數:
注意，不管幀長是否大於fMaxSize，每次都需要把完整的幀拷貝到fTo指針，live555內部會根據fNumTruncatedBytes等變數自行處理分包。
1.3 doGetNextFrame函數最後不管有沒有取到幀，都需要執行FramedSource::afterGetting
1.4 采樣率，通道數，configstr等的計算
這幾個變數在mediaSubbsession建立RTPsink時要用到，它直接影響了SDP里對於AAC音頻描述欄位的產生
添加類 ,繼承自
createNewStreamSource函數創建上面的ADTSAudioLiveSource做為音頻輸入源，參數estBitrate為預估的碼率，海思AAC編碼碼率設置為24kbps,所以estBitrate設置為24.
createNewRTPSink有必要繼承，因為需要根據音頻源的采樣率、通道數等創建RTPSink.
2.添加h264支持
添加 H264FramedLiveSource ,繼承自FramedSource
unsigned maxFrameSize()函數必須繼承，裡面設置幀最大可能的大小，我設置為100000，如果不繼承就是默認的，會出現畫面馬賽克
doGetNextFrame函數裡面和AAC取幀的處理差不多，我加多了一個步驟，就是第一次取幀的時候會調用介面去產生一個關鍵幀，並且等待這個關鍵幀到來才處理，這樣連接後出圖會比較快。
添加類 ,繼承自
這個類就是實現createNewStreamSource時創建H264FramedLiveSource
3.修改DynamicRTSPServer
修改類DynamicRTSPServer，在lookupServerMediaSession函數里動點手腳，默認在這個函數裡面會根據文件名去尋找伺服器下相應的文件做為直播源，我這里比較如果是我特定的live源名字則直接返回，相應的live源創建rtsp伺服器的時候就添加好
4.初始化rtsp server
初始化rtsp伺服器，添加一個ServerMediaSession，該mediaSession添加一個和一個，然後把該mediaSession添加給rtsp伺服器。
客戶端訪問 rtsp://x.x.x.x/ch0.live 時就可以看到實時的攝像頭圖像與聲音啦!