使用librtmp庫將拉取監控的rtsp流推送給srs服務器，發現一個異常，在長時間大概1個月後發現系統內存被srs吃滿，也不知道是什麼原因產生的這個現象，並且通過top去查看srs的內存在持續增長，通過ffmpeg推流沒有這個現象，感覺還是librtmp使用的問題，暫時也沒有很好的思路分析；
通過查看srs的git庫，發現srs提供了一個srs-librtmp的源碼庫，能完成推送h264裸流的功能，然後嘗試使用這個庫推送流到srs，發現srs的內存沒有明顯的增長，所以就選擇換成srs-librtmp的推流庫來推流，並且srs-librtmp的接口使用非常簡單；
使用srs-librtmp推流也碰到新的問題，是srs-librtmp是根據NALU單元來發送video數據，但我們的視頻包是多SLICE，也就是一個I幀會有多個0x65的slice，VLC播放器只能顯示出一張圖片的上半部分，不能完整顯示，原來是和ffmpeg編碼時的thread參數有關係，將 c->thread_type = 1;//FF_THREAD_SLICE;//just 1 thread encode for 1 slice ，VLC就能正常解碼；主要參考： https://blog.csdn.net/wupengqiangqinli/article/details/51200927 ，這篇博文的作者對多slice能否正常在rtmp推流中使用表示了擔心，果然如作者所說，所以修改爲單線程編碼後功能正常；
另外，公司採購了新的海康球形機，默認開啓rtsp的認證，但使用MD5認證使用認證失敗，一直返回401，剛開始懷疑是MD5算法的問題，參考：https://yq.aliyun.com/articles/243675中的計算md5的方式，算出來的MD5值也是一樣的，正好對rtsp的md5認證的算法也有了瞭解：
RTSP客戶端應該使用username + password並計算response如下:
(1)當password爲MD5編碼,則
response = md5( password:nonce:md5(public_method:url) );
(2)當password爲ANSI字符串,則
response= md5( md5(username:realm:password):nonce:md5(public_method:url) );
但問題還是沒有找到，最後發現是配置地址和實際的url地址不一致，少了一部分，並且xml解析的時候還有報錯，但被忽略了，原來是在xml中配置該球形機取流的rtsp地址有問題，該球形機的取流地址是：rtsp://11.12.115.118:554/Streaming/Channels/101?transportmode=unicast&profile=Profile_1
如果在xml文件中配置，發現解析的時候提示：EntityRef: expecting ';'錯誤；需要將url中的條件分割符&寫成& 也就是：
rtsp://11.12.115.118:554/Streaming/Channels/101?transportmode=unicast& profile=Profile_1
這樣子修改之後，認證和取流就都正常了。