問題現象：現場hik ipc在vlc通過rtsp取流地址（rtsp://admin:xxxxxxxx@44.110.81.45:554/Streaming/Channels/101?transportmode=unicast）取流，發現vlc界面並沒有畫面，但是看編碼統計卻是有收到碼流包的。而且換另一個ipc可以預覽，僅僅這個可以而已。
分析：據我所了解，rtsp取流跟onvif是一致的，也就是根據報文交互來確定取流、發流的相關屬性。思路：分別抓包，看報文，對比，猜測，驗證。
首先抓了個能預覽的：
來的碼流包是RTP？納尼，發現了些什么東西。熟悉的作案手法，RTP分析一波：
丟包率看起來還稍微能接收的樣子。此時想起現場反饋過這個ipc能預覽，但是有時會卡，猜測就是這1%+的丟包所致，繼續看其他的：
另外一個是UDP，轉RTP分析看看：
WC！這丟包率能播放就神奇了，再看另一個，
好吧，基本上能確定是網絡丟包所導致的。但是平常見到hik rtsp取流不都是tcp嗎，怎么這里是udp的？問了下，才知道原來vlc可以設置的。
默認是通過HTTP進行流傳輸，也就是udp，網絡不太好的時候，要改成tcp才行。測試一發，果然沒問題。
到這里問題是查出原因了，接下來繼續了解下rtsp吧！抓一下tcp和udp的報文，compare對比一下看看有何差異：
就是SETUP指令，這里默認是通過UDP進行流傳輸，指定TCP后才會通過tcp流傳輸。
然后看到這篇文章，講解很詳細！轉載一下：RTSP請求詳解及RTP 基於UDP和TCP協議傳輸數據的對比，好像鏈接不太穩定，貼一下以留着自己記錄吧。
以下內容轉載：
下面是我用VLC播放器獲取海康NVR視頻的截圖（此次獲取是基於TCP的）：
下面來看一下針對每一條消息的詳細截圖：
客戶端發送的OPTION消息：
服務器對OPTION回復的200OK消息：
客戶端發送的DESCRIBE不帶鑒權的消息：
服務器回復的401消息：
客戶端請求帶鑒權的DESCRIBE消息：
服務器回復200OK消息帶SDP消息體：
客戶端請求的SETUP消息：
服務器對SETUP回復的200OK消息：
客戶端發起PLAY消息：
服務器針對PLAY回復的200OK消息：
服務器發送完PLAY的200OK消息以后就開始發送數據，RTP基於TCP的數據傳輸截圖如下：
客戶端發送的TEARDOWN消息：
VLC停止播放時沒有收到服務器針對TEARDOWN消息發送的200OK消息，不知道是什么原因，初步懷疑是海康NVR沒有發送這個消息。
以上是基於TCP的截圖，下面是針對UDP的截圖，只截取和TCP不同的部分，相同的部分不再截圖，請參考TCP截圖：
第一個不同點是SETUP消息及回復部分：
數據傳輸部分：
總結：以上是RTP基於TCP和UDP傳輸數據不同的地方