live555linux編譯
㈠ ios平台下live555靜態庫的編譯及打包成.a文件
因為你執行的是./genMakefiles iphoneos ,所以得到的.a文件只支持真機環境下,同理執行./genMakefiles iphone-simulator,得到的是支持模擬器環境下的.a文件,編譯結束最終得到支持真機和模擬器下的四個.a文件,如下圖:
如何打包成一個靜態庫.a文件,請參考 http://blog.csdn.net/qq_26968709/article/details/51164104
如果需要打包好的庫文件,直接下面留言。
㈡ live555的性能不給力,該怎麼處理
我在開發板上移植了live555MediaServer,可以實現正常的傳輸。但似乎性能很不高,當進行16路D1的數據傳輸時,系統從硬碟上讀取視頻文件,CPU的idle時間幾乎為0,以下是我用top命令看到的系統性能:
Live555MediaServer 進程佔用CPU-- 50%
用戶態時間: 17%
內核態時間: 23%
idle時間: 0%
io時間 : 50%
如此,還沒運行其他應用,CPU就已經被全部占滿了,顯然無法工作。
各位幫幫忙,告訴我有沒有改進的方法(代碼最好),或者其他的替代live555的方案(除了gstreamer)
------解決方案--------------------------------------------------------
提高硬碟IO的效率,你不妨做個測試,只是硬碟讀取38M數據看看佔用多少cpu。
如果確認是IO的問題,不妨嘗試採用dio來提高讀取的效率。
可參考 基於linux的Socket網路編程的性能優化。 我以前就對live555的接收模塊做了優化,CPU佔用小30%。
㈢ 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 時就可以看到實時的攝像頭圖像與聲音啦!
㈣ live555、jrtplib、ortp、gstreamer,用哪一個比較好呢解決方法
接收端想在WindowsPC機上觀看。
本人正在讀研,以前幾乎沒接觸網路傳輸。看了很長時間的資料,看大家用的最多的就是live555和jrtplib了,但是這兩個都是用C++寫的,而我的採集和編碼都是用C語言寫的。至於ortp和gstreamer好像用的人不多。
------解決方案--------------------------------------------------------
伺服器端使用live555、jrtplib,客戶端建議如果是windows建議使用DITRECTSHOW,是LINUX建議使用GSTREAMER,至於解碼使用ffmpeg就可以了
㈤ 開源的視頻傳輸框架 linux下可調 像live555 ffmpeg 之類的 還有那些 具體是什麼 最好有對比的文章資料
gstreamer
不是很懂流媒體,不過以前用過gstreamer 做rtsp伺服器