live555 源碼架構分析

原創 mtour 2020-02-21 00:05

live555源代碼分析   ， 寫的不錯 轉載備忘


源代碼下載（VC6工程）:http://download.csdn.net/detail/leixiaohua1020/6374387


liveMedia 項目(http://www.live555.com/)的源代碼包括四個基本的庫，各種測試代碼以及
Media Server。四個基本的庫分別是: UsageEnvironment&TaskScheduler, groupsock, liveMedia
和BasicUsageEnvironment。
UsageEnvironment 和TaskScheduler 類用於事件的調度，實現異步讀取事件的句柄的設置以
及錯誤信息的輸出。另外，還有一個HashTable 類定義了一個通用的hash 表，其它代碼要
用到這個表。這些都是抽象類，在應用程序中基於這些類來實現自己的子類。
groupsock 類是對網絡接口的封裝，用於收發數據包。正如名字本身，groupsock 主要是面向
多播數據的收發的，它也同時支持單播數據的收發。
liveMedia 庫中有一系列類，基類是Medium，這些類針對不同的流媒體類型和編碼。
各種測試代碼在testProgram 目錄下，比如openRTSP 等，這些代碼有助於理解liveMedia 的
應用。
Media Server 是一個純粹的RTSP 服務器。支持多種格式的媒體文件:
* TS 流文件，擴展名ts。
* PS 流文件，擴展名mpg。
* MPEG-4視頻基本流文件，擴展名m4e。
* MP3文件，擴展名mp3。
* WAV 文件(PCM)，擴展名wav。
* AMR 音頻文件，擴展名.amr。
* AAC 文件，ADTS 格式，擴展名aac。
用live555開發應用程序
基於liveMedia 的程序，需要通過繼承UsageEnvironment 抽象類和TaskScheduler 抽象類，
定義相應的類來處理事件調度，數據讀寫以及錯誤處理。live 項目的源代碼裏有這些類的
一個基本實現，這就是“BasicUsageEnvironment”庫。BasicUsageEnvironment 主要是針對簡
單的控制檯應用程序，利用select 實現事件獲取和處理。這個庫利用Unix 或者Windows 的
控制檯作爲輸入輸出，處於應用程序原形或者調試的目的，可以用這個庫用戶可以開發傳統
的運行與控制檯的應用。
通過使用自定義的“UsageEnvironment”和“TaskScheduler”抽象類的子類，這些應用程序就可
以在特定的環境中運行， 不需要做過多的修改。需要指出的是在圖形環境（GUI toolkit）
下，抽象類TaskScheduler 的子類在實現doEventLoop()的時候應該與圖形環境自己的事件
處理框架集成。
基本概念
先來熟悉在liveMedia 庫中Source，Sink 以及Filter 等概念。Sink 就是消費數據的對象，比
如把接收到的數據存儲到文件， 這個文件就是一個Sink。Source 就是生產數據的對象，比
如通過RTP 讀取數據。數據流經過多個'source'和'sink's，下面是一個示例：
'source1' -> 'source2' (a filter) -> 'source3' (a filter) -> 'sink'
從其它Source 接收數據的source 也叫做"filters"。Module 是一個sink 或者一個filter。數據
接收的終點是Sink 類，MediaSink 是所有Sink 類的基類。Sink 類實現對數據的處理是通過
實現純虛函數continuePlaying()，通常情況下continuePlaying 調用fSource->getNextFrame 來
爲Source 設置數據緩衝區，處理數據的回調函數等，fSource 是MediaSink 的類型爲
FramedSource*的類成員。
基本控制流程
基於liveMedia 的應用程序的控制流程如下:
應用程序是事件驅動的，使用如下方式的循環
while (1) {
通過查找讀網絡句柄的列表和延遲隊列（delay queue）來發現需要完成的任務
完成這個任務
}
對於每個sink，在進入這個循環之前，應用程序通常調用下面的方法來啓動需要做的生成任
務： someSinkObject->startPlaying()。任何時候，一個Module 需要獲取數據都通過調用剛
好在它之前的那個Module 的FramedSource::getNextFrame() 方法。這是通過純虛函數
FramedSource::doGetNextFrame() 實現的，每一個Source module 都有相應的實現。
Each 'source' module's implementation of "doGetNextFrame()" works by arranging for an 'after
getting' function to be called (from an event handler) when new data becomes available for the
caller.
Note that the flow of data from 'sources' to 'sinks' happens within each application, and doesn't
necessarily correspond to the sending or receiving of network packets. For example, a server
application (such as "testMP3Streamer") that sends RTP packets will do so using one or more
"RTPSink" modules. These "RTPSink" modules receive data from other, "*Source" modules (e.g.,
to read data from a file), and, as a side effect, transmit RTP packets.
live555代碼解讀之一：RTSP 連接的建立過程
RTSPServer 類用於構建一個RTSP 服務器，該類同時在其內部定義了一個RTSPClientSession
類，用於處理單獨的客戶會話。
首先創建RTSP 服務器( 具體實現類是DynamicRTSPServer) ， 在創建過程中， 先建立
Socket(ourSocket) 在TCP 的554 端口進行監聽， 然後把連接處理函數句柄
(RTSPServer::incomingConnectionHandler)和socket 句柄傳給任務調度器(taskScheduler)。
任務調度器把socket 句柄放入後面select 調用中用到的socket 句柄集(fReadSet)中，同時將
socket 句柄和incomingConnectionHandler 句柄關聯起來。接着，主程序開始進入任務調度器
的主循環（doEventLoop），在主循環中調用系統函數select 阻塞，等待網絡連接。
當RTSP 客戶端輸入(rtsp://192.168.1.109/1.mpg)連接服務器時，select 返回對應的scoket，進
而根據前面保存的對應關係， 可找到對應處理函數句柄， 這裏就是前面提到的
incomingConnectionHandler 了。在incomingConnectionHandler 中創建了RTSPClientSession，
開始對這個客戶端的會話進行處理。
live555代碼解讀之二：DESCRIBE 請求消息處理過程
RTSP 服務器收到客戶端的DESCRIBE 請求後，根據請求URL(rtsp://192.168.1.109/1.mpg)，
找到對應的流媒體資源， 返回響應消息。live555中的ServerMediaSession 類用來處理會話
中描述，它包含多個（音頻或視頻）的子會話描述(ServerMediaSubsession)。
上節我們談到RTSP 服務器收到客戶端的連接請求，建立了RTSPClientSession 類，處理單
獨的客戶會話。在建立RTSPClientSession 的過程中，將新建立的socket 句柄（clientSocket）
和RTSP 請求處理函數句柄RTSPClientSession::incomingRequestHandler 傳給任務調度器，
由任務調度器對兩者進行一對一關聯。當客戶端發出RTSP 請求後，服務器主循環中的select
調用返回，根據socket 句柄找到對應的incomingRequestHandler，開始消息處理。先進行消
息的解析，如果發現請求是DESCRIBE 則進入handleCmd_DESCRIBE 函數。根據客戶端請
求URL 的後綴(例如是1.mpg), 調用成員函數DynamicRTSPServer::lookupServerMediaSession
查找對應的流媒體信息ServerMediaSession。如果ServerMediaSession 不存在，但是本地存
在1.mpg 文件，則創建一個新的ServerMediaSession。在創建ServerMediaSession 過程中，
根據文件後綴.mpg，創建媒體MPEG-1or2的解複用器(MPEG1or2FileServerDemux)。再由
MPEG1or2FileServerDemux 創建一個子會話描述
MPEG1or2DemuxedServerMediaSubsession。最後由ServerMediaSession 完成組裝響應消息中
的SDP 信息（SDP 組裝過程見下面的描述），然後將響應消息發給客戶端，完成一次消息
交互。
SDP 消息組裝過程：
ServerMediaSession 負責產生會話公共描述信息， 子會話描述由
MPEG1or2DemuxedServerMediaSubsession 產生。MPEG1or2DemuxedServerMediaSubsession
在其父類成員函數OnDemandServerMediaSubsession::sdpLines()中生成會話描述信息。在
sdpLines() 實現裏面， 創建一個虛構(dummy) 的FramedSource( 具體實現類爲
MPEG1or2AudioStreamFramer 和MPEG1or2VideoStreamFramer)和RTPSink（具體實現類爲
MPEG1or2AudioRTPSink 和MPEG1or2VideoRTPSink ） ， 最後調用
setSDPLinesFromRTPSink(...)成員函數生成子會話描述。
以上涉及到的類以及繼承關係：
Medium <- ServerMediaSession
Medium <- ServerMediaSubsession <- OnDemandServerMediaSubsession <-
MPEG1or2DemuxedServerMediaSubsession
Medium <- MediaSource <- FramedSouse <- FramedFileSource <- ByteStreamFileSource
Medium <- MediaSource <- FramedSouse <- MPEG1or2DemuxedElementaryStream
Medium <- MPEG1or2FileServerDemux
Medium <- MPEG1or2Demux
Medium <- MediaSource <- FramedSouse <- MPEG1or2DemuxedElementaryStream
Medium <- MediaSource <- FramedSouse <- FramedFilter <- MPEGVideoStreamFramer <-
MPEG1or2VideoStreamFramer
Medium <- MediaSink <- RTPSink <- MultiFramedRTPSink <- VideoRTPSink <-
MPEG1or2VideoRTPSink
live555代碼解讀之三：SETUP 和PLAY 請求消息處理過程
前面已經提到RTSPClientSession 類， 用於處理單獨的客戶會話。其類成員函數
handleCmd_SETUP()處理客戶端的SETUP 請求。調用parseTransportHeader()對SETUP 請
求的傳輸頭解析，調用子會話(這裏具體實現類爲OnDemandServerMediaSubsession)的
getStreamParameters()函數獲取流媒體發送傳輸參數。將這些參數組裝成響應消息，返回給
客戶端。
獲取發送傳輸參數的過程： 調用子會話( 具體實現類
MPEG1or2DemuxedServerMediaSubsession) 的createNewStreamSource(...) 創建
MPEG1or2VideoStreamFramer，選擇發送傳輸參數，並調用子會話的createNewRTPSink(...)
創建MPEG1or2VideoRTPSink。同時將這些信息保存在StreamState 類對象中，用於記錄流
的狀態。
客戶端發送兩個SETUP 請求，分別用於建立音頻和視頻的RTP 接收。
PLAY 請求消息處理過程
RTSPClientSession 類成員函數handleCmd_PLAY()處理客戶端的播放請求。首先調用子會話
的startStream(), 內部調用MediaSink::startPlaying(...) ， 然後是
MultiFramedRTPSink::continuePlaying() ， 接着調用
MultiFramedRTPSink::buildAndSendPacket(...)。buildAndSendPacke 內部先設置RTP 包頭，內
部再調用MultiFramedRTPSink::packFrame()填充編碼幀數據。
packFrame 內部通過FramedSource::getNextFrame(), 接着
MPEGVideoStreamFramer::doGetNextFrame() ， 再接着經過
MPEGVideoStreamFramer::continueReadProcessing() ， FramedSource::afterGetting(...),
MultiFramedRTPSink::afterGettingFrame(...), MultiFramedRTPSink::afterGettingFrame1(...) 等
一系列繁瑣調用，最後到了MultiFramedRTPSink::sendPacketIfNecessary(), 這裏才真正發送
RTP 數據包。然後是計算下一個數據包發送時間，把MultiFramedRTPSink::sendNext(...)函數
句柄傳給任務調度器， 作爲一個延時事件調度。在主循環中， 當
MultiFramedRTPSink::sendNext() 被調度時， 又開始調用
MultiFramedRTPSink::buildAndSendPacket(...)開始新的發送數據過程，這樣客戶端可以源源
不斷的收到服務器傳來的RTP 包了。
發送RTP 數據包的間隔計算方法：
Update the time at which the next packet should be sent, based on the duration of the frame that
we just packed into it.
涉及到一些類有：
MPEGVideoStreamFramer: A filter that breaks up an MPEG video elementary stream into headers
and frames
MPEG1or2VideoStreamFramer: A filter that breaks up an MPEG 1 or 2 video elementary stream
into frames for: Video_Sequence_Header, GOP_Header, Picture_Header
MPEG1or2DemuxedElementaryStream: A MPEG 1 or 2 Elementary Stream, demultiplexed from
a Program Stream
MPEG1or2Demux: Demultiplexer for a MPEG 1 or 2 Program Stream
ByteStreamFileSource: A file source that is a plain byte stream (rather than frames)
MPEGProgramStreamParser: Class for parsing MPEG program stream
StreamParser: Abstract class for parsing a byte stream
StreamState：A class that represents the state of an ongoing stream


rtsp 簡介(ZT)
Real Time Streaming Protocol 或者RTSP（實時流媒體協議），是由Real network 和Netscape
共同提出的如何有效地在IP 網絡上傳輸流媒體數據的應用層協議。RTSP 提供一種可擴展的
框架，使能夠提供能控制的，按需傳輸實時數據，比如音頻和視頻文件。源數據可以包括現
場數據的反饋和存貯的文件。rtsp 對流媒體提供了諸如暫停，快進等控制，而它本身並不傳
輸數據，rtsp 作用相當於流媒體服務器的遠程控制。傳輸數據可以通過傳輸層的tcp，udp
協議，rtsp 也提供了基於rtp 傳輸機制的一些有效的方法。
RTSP 消息格式:
RTSP 的消息有兩大類,一是請求消息(request),一是迴應消息(response),兩種
消息的格式不同.


請求消息:
方法URI RTSP 版本CR LF
消息頭CR LF CR LF
消息體CR LF
其中方法包括OPTION 迴應中所有的命令,URI 是接受方的地址,例如
:rtsp://192.168.20.136
RTSP 版本一般都是RTSP/1.0.每行後面的CR LF 表示回車換行，需要接受端有相應的解
析，最後一個消息頭需要有兩個CR LF


迴應消息:
RTSP 版本狀態碼解釋CR LF
消息頭CR LF CR LF
消息體CR LF
其中RTSP 版本一般都是RTSP/1.0,狀態碼是一個數值,200表示成功,解釋是與狀態碼對應
的文本解釋.


簡單的rtsp 交互過程:
C 表示rtsp 客戶端,S 表示rtsp 服務端

[html] view plaincopy
  1. 1.C->S:OPTION request //詢問S 有哪些方法可用  
  2. 1.S->C:OPTION response //S 迴應信息中包括提供的所有可用方法  
  3. 2.C->S:DESCRIBE request //要求得到S 提供的媒體初始化描述信息  
  4. 2.S->C:DESCRIBE response //S 迴應媒體初始化描述信息，主要是sdp  
  5. 3.C->S:SETUP request //設置會話的屬性，以及傳輸模式，提醒S 建立會  
  6. 話  
  7. 3.S->C:SETUP response //S 建立會話，返回會話標識符，以及會話相關信息  
  8. 4.C->S:PLAY request //C 請求播放  
  9. 4.S->C:PLAY response //S 迴應該請求的信息  
  10. S->C:發送流媒體數據  
  11. 5.C->S:TEARDOWN request //C 請求關閉會話  
  12. 5.S->C:TEARDOWN response //S 迴應該請求  


上述的過程是標準的、友好的rtsp 流程，但實際的需求中並不一定按部就班來。
其中第3和4步是必需的！第一步，只要服務器客戶端約定好，有哪些方法可用，則
option 請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如
http 請求等等），則我們也不需要通過rtsp 中的describe 請求來完成。第五步，可以根
據系統需求的設計來決定是否需要。
rtsp 中常用方法:
1.OPTION
目的是得到服務器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每個消息都有序號來標記，第一個包通常是option 請求消息
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器的迴應信息包括提供的一些方法,例如:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 1 //每個迴應消息的cseq 數值和請求消息的cseq 相對應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,
GET_PARAMETER //服務器提供的可用的方法
2.DESCRIBE
C 向S 發起DESCRIBE 請求,爲了得到會話描述信息(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 2
token:
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器迴應一些對此會話的描述信息(sdp):
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 2
x-prev-url: rtsp://192.168.20.136:5000
x-next-url: rtsp://192.168.20.136:5000
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri, 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp://192.168.20.136:5000/xxx666/
Content-Length: 344
Content-Type: application/sdp
v=0 //以下都是sdp 信息
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136
s=/xxx666
u=http:///
e=admin@
c=IN IP4 0.0.0.0
t=0 0
a=isma-compliance:1,1.0,1
a=range:npt=0-
m=video 0 RTP/AVP 96 //m 表示媒體描述，下面是對會話中視頻通道的媒體描述
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96
profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D
089028307
a=control:trackID=0//trackID＝0表示視頻流用的是通道0
3.SETUP
客戶端提醒服務器建立會話,並確定傳輸模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
//uri 中帶有trackID＝0，表示對該通道進行設置。Transport 參數設置了傳輸模式，包
的結構。接下來的數據包頭部第二個字節位置就是interleaved，它的值是每個通道都
不同的，trackID＝0的interleaved 值有兩個0或1，0表示rtp 包，1表示rtcp 包，接受端
根據interleaved 的值來區別是哪種數據包。
服務器迴應信息:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 3
Session: 6310936469860791894 //服務器迴應的會話標識符
Cache-Control: no-cache
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567
4.PLAY
客戶端發送播放請求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 4
Session: 6310936469860791894
Range: npt=0.000- //設置播放時間的範圍
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器迴應信息:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 4
Session: 6310936469860791894
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309
//seq 和rtptime 都是rtp 包中的信息
5.TEARDOWN
客戶端發起關閉請求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 5
Session: 6310936469860791894
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器迴應:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 5
Session: 6310936469860791894
Connection: Close
以上方法都是交互過程中最爲常用的,其它還有一些重要的方法如
get/set_parameter,pause,redirect 等等
ps:
sdp 的格式

[html] view plaincopy
  1. v=<version>  
  2. o=<username> <session id> <version> <network type> <address type> <address>  
  3. s=<session name>  
  4. i=<session description>  
  5. u=<URI>  
  6. e=<email address>  
  7. p=<phone number>  
  8. c=<network type> <address type> <connection address>  
  9. b=<modifier>:<bandwidth-value>  
  10. t=<start time> <stop time>  
  11. r=<repeat interval> <active duration> <list of offsets from start-time>  
  12. z=<adjustment time> <offset> <adjustment time> <offset> ....  
  13. k=<method>  
  14. k=<method>:<encryption key>  
  15. a=<attribute>  
  16. a=<attribute>:<value>  
  17. m=<media> <port> <transport> <fmt list>  
  18. v = （協議版本）  
  19. o = （所有者/創建者和會話標識符）  
  20. s = （會話名稱）  
  21. i = * （會話信息）  
  22. u = * （URI 描述）  
  23. e = * （Email 地址）  
  24. p = * （電話號碼）  
  25. c = * （連接信息）  
  26. b = * （帶寬信息）  
  27. z = * （時間區域調整）  
  28. k = * （加密密鑰）  
  29. a = * （0 個或多個會話屬性行）  
  30. 時間描述：  
  31. t = （會話活動時間）  
  32. r = * （0或多次重複次數）  
  33. 媒體描述：  
  34. m = （媒體名稱和傳輸地址）  
  35. i = * （媒體標題）  
  36. c = * （連接信息— 如果包含在會話層則該字段可選）  
  37. b = * （帶寬信息）  
  38. k = * （加密密鑰）  
  39. a = * （0 個或多個媒體屬性行）  


參考文章：rfc2326（rtsp）；rfc2327（sdp）
RTSP 點播消息流程實例（客戶端：VLC， RTSP 服務器：LIVE555 Media Server)
1)C(Client)-> M(Media Server)
[html] view plaincopy
  1. OPTIONS rtsp://192.168.1.109/1.mpg RTSP/1.0  
  2. CSeq: 1  
  3. user-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)  
  4. 1)M -> C  
  5. RTSP/1.0 200 OK  
  6. CSeq: 1  
  7. Date: wed, Feb 20 2008 07:13:24 GMT  
  8. Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE  

2)C -> M
[html] view plaincopy
  1. DESCRIBE rtsp://192.168.1.109/1.mpg RTSP/1.0  
  2. CSeq: 2  
  3. Accept: application/sdp  
  4. User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)  

2)M -> C
[html] view plaincopy
  1. RTSP/1.0 200 OK  
  2. CSeq: 2  
  3. Date: wed, Feb 20 2008 07:13:25 GMT  
  4. Content-Base: rtsp://192.168.1.109/1.mpg/  
  5. Content-type: application/sdp  
  6. Content-length: 447  
  7. v=0  
  8. o =- 2284269756 1 IN IP4 192.168.1.109  
  9. s=MPEG-1 or 2 program Stream, streamed by the LIVE555 Media Server  
  10. i=1.mpg  
  11. t=0 0  
  12. a=tool:LIVE555 Streaming Media v2008.02.08  
  13. a=type:broadcast  
  14. a=control:*  
  15. a=range:npt=0-66.181  
  16. a=x-qt-text-nam:MPEG-1 or Program Stream, streamed by the LIVE555 Media Server  
  17. a=x-qt-text-inf:1.mpg  
  18. m=video 0 RTP/AVP 32  
  19. c=IN IP4 0.0.0.0  
  20. a=control:track1  
  21. m=audio 0 RTP/AVP 14  
  22. c=IN IP4 0.0.0.0  
  23. a=control:track2  

3)C -> M
[html] view plaincopy
  1. SETUP rtsp://192.168.1.109/1.mpg/track1 RTSP/1.0  
  2. CSeq: 3  
  3. Transport: RTP/AVP; unicast;client_port=1112-1113  
  4. User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)  

3)M -> C
[html] view plaincopy
  1. RTSP/1.0 200 OK  
  2. CSeq: 3  
  3. Date: wed, Feb 20 2008 07:13:25 GMT  
  4. Transport:  
  5. RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1112-1113;server  
  6. _port=6970-6971  
  7. Session: 3  

4)C -> M
[html] view plaincopy
  1. SETUP rtsp://192.168.1.109/1.mpg/track2 RTSP/1.0  
  2. CSeq: 4  
  3. Transport: RTP/AVP; unicast;client_port=1114-1115  
  4. Session: 3  
  5. User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)  

4)M -> C
[html] view plaincopy
  1. RTSP/1.0 200 OK  
  2. CSeq: 4  
  3. Date: wed, Feb 20 2008 07:13:25 GMT  
  4. Transport:  
  5. RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1114-1115;server  
  6. _port=6972-6973  
  7. Session: 3  

5)C -> M
[html] view plaincopy
  1. PLAY rtsp://192.168.1.109/1.mpg/ RTSP/1.0  
  2. CSeq: 5  
  3. Session: 3  
  4. Range: npt=0.000-  
  5. User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20)  

5)M -> C
[html] view plaincopy
  1. RTSP/1.0 200 OK  
  2. CSeq: 5  
  3. Range: npt=0.000-  
  4. Session: 3  
  5. RTP-Info:  
  6. url=rtsp://192.168.1.109/1.mpg/track1;seq=9200;rtptime=214793785,url=rtsp://192.168.1.109/1.  
  7. mpg/track2;seq=12770;rtptime=31721  
  8. (開始傳輸流媒體...)  
mtour
發佈了47 篇原創文章 · 獲贊 7 · 訪問量 6萬+
私信 關注
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

【網絡通信 -- 直播】IM 學習系列 -- 網絡通信協議簡介(HTTP 協議 七)

【網絡通信 -- 直播】IM 學習系列 -- 網絡通信協議簡介(HTTP 協議 七) 【1】HTTP/2 特性概覽 HTTP/2 把 HTTP 分解成了“語義”和“語法”兩個部分，“語義”層不做改動，與 HTTP/1 完全一致；同時 HT

奋斗企鹅copper 2020-07-07 23:16:50

基於live555的rtsp客戶端模塊

</pre><pre name="code" class="html">基於live555 testRtspClient.cpp 改造， 已經封裝成 dll 模塊，提供了視頻幀回調接口. live555 需要編譯成靜態庫， 請自行編譯，網

mtour 2020-07-07 15:28:25

通過rtmpdump推送海康視頻流到red5服務器

     現在主流的網絡攝像機都支持標準H264視頻格式，例如 海康網絡攝像機， 通過海康提供的網絡SDK可以獲取到視頻碼流。我測試的這款相機，視頻編碼採用的是H264，音頻編碼採用的是G711a。 這裏，我僅測試了視頻。 通過海康SD

mtour 2020-07-07 15:28:25

【網絡通信 -- 直播】IM 學習系列 -- 網絡通信協議簡介(HTTP 協議 四)

【網絡通信 -- 直播】IM 學習系列 -- 網絡通信協議簡介(HTTP 協議 四) 【1】HTTP 的連接管理 【1.1】短連接與長連接 短連接 HTTP 協議最初（0.9/1.0）是個非常簡單的協議，通信過程也採用了簡單的“請求 -

奋斗企鹅copper 2020-07-07 05:28:02

【網絡通信 -- 直播】IM 學習系列 -- 網絡通信協議簡介(HTTP 協議 二)

【網絡通信 -- 直播】IM 學習系列 -- 網絡通信協議簡介(HTTP 協議 二) 【1】一次 HTTP 請求過程 圖示爲一次 HTTP 請求的抓包數據分析 圖示爲瀏覽器與 Web 服務器通過 HTTP 協議交換過程 大致交換流程如

奋斗企鹅copper 2020-07-07 05:28:02

基於live555的rtsp播放器：數據接收（拉流）

live555的使用都是從研究源碼中的testRTSPClient例子開始的，這個例子包含了RTSP消息交互和數據接收。 一.RTSP消息交互 一次基本的RTSP操作過程如下:C表示RTSP客戶端,S表示RTSP服務端 1.第一步：查詢服

osc_rjwgyutp 2021-01-30 11:06:45

基於live555的rtsp播放器之十九：實現多路切換

一.效果 二.實現 爲了控制視頻的顯示路數，通常需要做通道切換，這裏提供了1通道+4通道+9通道+16通道，其他通道基本上不會用到，因爲一般來說，超過9個通道實時顯示視頻流，建議採用子碼流來顯示，如果都採用主碼流，解碼壓力大，CPU和

osc_x5cptzgg 2021-01-30 10:38:57

基於live555的rtsp播放器：斷網重連

live555原生不支持斷網重連，需要客戶端自己實現。 我的實現方法是，在sendPlayCommand的回調函數中啓動超時處理函數，函數中通過延時任務每秒鐘調用自己一次，並累加檢測次數值，當檢測次數達到超時時間時，認爲網絡異常，釋放所有l

osc_smzoc82r 2021-01-30 10:38:16

基於live555的rtsp播放器：使用SDL2播放音頻

一.pcm文件準備 找一個mp3文件，然後用FFmpeg命令將它轉換成pcm文件，這裏使用NorwayForest-500.mp3（挪威的森林-伍佰）。 首先要使用ffmpeg查看mp3文件的一些信息，比如採樣率、聲道數等。 ffmpeg

osc_1mofhvr6 2021-01-30 10:11:45

基於live555的rtsp播放器：使用QOpenGLWidget渲染yuv420p

上篇博客基於live555的rtsp播放器：使用SDL2\D3D9渲染yuv420p中指出在mac上使用SDL2會有問題，因此在mac上可以使用QOpenGLWidget渲染yuv420p。 一.GLSL Versions You can

osc_evac23lh 2021-01-30 10:10:16

基於live555的rtsp播放器：使用SDL2\D3D9渲染yuv420p

一.yuv文件準備 找到一個mp4文件，然後用FFmpeg命令將它轉換成yuv文件，這裏使用一個野生動物視頻Wildlife.mp4。 首先要使用ffmpeg查看mp4文件的一些信息，比如編碼器類型、像素格式、分辨率、幀率等。 ffmpe

osc_r9yyhhqz 2021-01-30 09:59:58

基於live555的rtsp播放器：音頻解碼

這裏使用FFmpeg解碼AAC、G711A/G711u和G726，最開始嘗試過用faad2來解碼AAC，但存在一些問題。 一.初始化解碼器 void QHAudioDecoder::openDecoder(Format *format)

osc_kdarxvx0 2021-01-30 09:56:20

基於live555的rtsp播放器之十三：錄製mp4

錄製這裏是指是音頻和視頻同步錄製。 一.使用ffmpeg錄製的流程 實現錄製的方法有多種，我嘗試成功過的有以下三種： 1.使用mp4v2庫錄製mp4，這個庫主要用於錄製h264+AAC，多年未更新。如果要錄製h265+AAC，需要自己改源

osc_n0c6719w 2021-01-30 09:42:49

基於live555的rtsp播放器之十八：G711a/G711u/G726轉AAC

封裝格式的主要作用是把視頻碼流和音頻碼流按照一定的格式存儲在一個文件中。現如今流行的封裝格式如下表所示： 此表來自雷神：[總結]視音頻編解碼技術零基礎學習方法，由表可見： 1.除了AVI之外，其他封裝格式都支持流媒體，即可以“邊下邊播”。

osc_7tjf46li 2021-01-30 09:29:44

基於live555的rtsp播放器：數據接收（拉流）時應該注意的問題

一.h264中的I、P和B幀 I-幀：也成爲關鍵幀，I-幀完全自我指涉的，並且不使用任何其他幀的信息。它在三種幀中佔最大的比例，並且具有最高的質量，但是壓縮效率是最低的。 P-幀：P-幀是所謂的“預測”幀。當創建了一個P-幀時，編碼器可以

osc_gwtkg2dc 2021-01-30 09:09:39