Sunday, January 13, 2019

打造一個多人串流系統 html5 publish to adobe media server ? part4

推送到了html5 瀏覽器又怎樣呢，我們的客戶端，假設也必須要，傳輸自己的畫面自server 怎麼辦呢? 找了一下子發現又有 solution 可以用了
https://github.com/chenxiaoqino/getusermedia-to-rtmp

Install ffmpeg

加入系統變數

c:\ffmpeg\bin

Cmd >>>ffmpeg –version

Install successful!

Node.js install

一直下一步~

Cmd >>> node -v

Clone github download getusermedia-to-rtmp

我們的主角

https://github.com/chenxiaoqino/getusermedia-to-rtmp

必須切去該路徑然後 cmd 輸入 npm install

ffmpeg param setting

Path:

C:\Users\x2132\Desktop\nodejs\getusermedia-to-rtmp-master\server.js

run nodejs server!

node server.js

Html5 Rtmp server location

rtmp://127.0.0.1:1935/live/test

注意後面跟 flex 版本一樣必須要指定

確實收到數據了!

檢查 flex 端是否可以撥放

成功! ，終於可以交貨了

Wednesday, January 9, 2019

打造一個多人串流系統 adobe media server f4m to HTTP Live Streaming(hls) part3

Adobe宣布Flash不再更新2020年全面停用,HTML5淘汰Flash成為多媒體網頁主流

HTML5 出現之後，和 Flash 的比較、取代到淘汰的話題始終熱門。Flash 歷經 Macromedia 時代到 Adobe 時代，可以說是平面2D多媒體設計的主流軟體；然而，時至今日Flash 已經是走入末途，越來越多的開發公司表示不採用 Flash Player 與其相關技術，主流瀏覽器也陸續停止支援這個漏洞永遠補不完且很吃系統資源的舊技術。

自2016年 Google 表示最快該年底就會將 Chrome 瀏覽器預設停止支援與使用Flash後，2017年的現在，Adobe 都已經確定宣告 Flash 將走入歷史。

Adobe宣布Flash不再更新2020年全面停用,HTML5淘汰Flash成為多媒體網頁主流 (比較,取代,2D動畫,多媒體,ActionScript,Safari,Firefox,Flash Player)

https://liangyowen.blogspot.com/2017/09/html5-replace-adobe-flash.html

綜合於上述原因我們來思考一下解決方案吧!

HTTP Live Streaming(hls)

HTTP Live Streaming（縮寫是HLS）是一個由蘋果公司提出的基於HTTP的流媒體網絡傳輸協議。是蘋果公司QuickTime X和iPhone軟體系統的一部分。它的工作原理是把整個流分成一個個小的基於HTTP的文件來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。在開始一個流媒體會話時，客戶端會下載一個包含元數據的extended M3U (m3u8) playlist文件，用於尋找可用的媒體流。

HLS只請求基本的HTTP報文，與實時傳輸協議（RTP）不同，HLS可以穿過任何允許HTTP數據通過的防火牆或者代理伺服器。它也很容易使用內容分發網絡來傳輸媒體流。

蘋果公司把HLS協議作為一個網際網路草案（逐步提交），在第一階段中已作為一個非正式的標準提交到IETF。2017年8月，RFC 8216發布，描述了HLS協議第7版的定義。

adobe media server to hls

恩恩看來新版adobe media server 有支援 hls 之間的轉換，就來看怎樣實現過程吧!

Flex to HTTP Live Streaming

使用html5進行撥放，並不支援原生撥放數據，所以必須再轉成hls

http://localhost/hds-live/livepkgr/_definst_/liveevent/livestream.m3u8

http://localhost/hds-live/livepkgr/_definst_/liveevent/livestream.f4m

使用html5進行撥放，並不支援原生撥放數據，所以必須再轉成hls

http://localhost/hds-live/livepkgr/_definst_/liveevent/livestream.m3u8

輸入範例
rtmp://localhost/livepkgr
和
livestream?adbe-live-event=liveevent

[name]? adbe-live-event=liveevent

Stream里面输入：livestream?adbe-live-event=liveevent 如果左边的Preset设置了多路，Stream就要修改为：livestream%i?adbe-live-event=liveevent

新建crossdomain.xml跨網域權限文件

目前設為最寬鬆

位置

C:\Program Files\Adobe\Adobe Media Server 5\webroot\crossdomain.xml

推送頻道範例

推送去123頻道成功會在

C:\Program Files\Adobe\Adobe Media Server5\applications\livepkgr\streams\_definst_
產生該頻道資料夾

注意端口，和url文件位置與檔案格式

http://172.16.2.111:8134/hds-live/livepkgr/_definst_/liveevent/livestream.f4m

http://172.16.2.111:8134/hls-live/livepkgr/_definst_/liveevent/livestream.m3u8

檢測是否成功推送可以鍵入此連結
http://172.16.2.111:8134/hds-live/livepkgr/_definst_/liveevent/livestream.f4m

多路推送品質修改 (尚未研究)

(好像是自動適應，依網路速度自行切換吧?

C:\Program Files\Adobe\Adobe Media Server 5\applications\livepkgr\events\_definst_\liveevent\ Manifest.xml

Html5使用hls.js 撥放器，撥放m3u8串流

adobe media server to hls !

Sunday, January 6, 2019

打造一個多人串流系統 adobe_media_server part2

RTMFP VS RTMP

什么是RTMFP？

RTMFP 是 Real‐Time Media Flow Protocol的缩写，是Adobe准备推出的一种新的通信协议，这种通信协议可以让 Flash 客户端直接和另外一个Flash 客户端之间进行数据通信，也就是常说的p2p的方式进行通信。

什么时候能用上RTMFP？需要什么技术支持？

只有下一个版本的播放器：Flash Player10 才支持RTMFP 协议，同时服务器端还需要下一个版本的 Flash Media Server，估计就是FMS4了，（我博客之前的一篇文章：http://www.cuplayer.com/index.php?play=reply&id=115没猜错）。
目前虽然Flash Player10的预览版本已经出来了，但是FMS4发布日期还没有定下来。所以目前RTMFP还体验不了。

RTMFP有哪些新的功能？

使用RTMFP，一些使用即时通讯技术的Flash应用，例如在线聊天，在线多人游戏等应用的通信效率将会大大提高，因为RTMFP支持客户端之间直接通信，包括麦克风、摄像头的共享等。（目前Flash客户端之间的通信都是要先经过服务器中转的，所以效率不高，服务器压力比较大，RTMFP技术出现后这些问题将会迎刃而解）。
不过RTMFP不支持文件的传输和共享。

RTMFP给我们带来什么好处？

RTMFP将会大大地减少音视频直播、点播、多人在线游戏等应用的网络带宽的消耗，减轻服务器的负担。因为很多数据都是客户端之间直接传输了，无须再经过服务器中转了。
RTMFP由于使用了UDP网络协议，所以相对之前的TCP协议在数据传输效率上也会大大提高，这种优势在音视频数据传输方面是非常明显的。
关于TCP和UDP网络通信协议之间的区别以及各自的优缺点大家可以去网上搜索相关的介绍，这里就不再做过多的介绍了。

RTMFP和RTMP有哪些区别？

从本质上的区别就是网络通信的协议不一样，RTMFP是使用User Datagram Protocol (UDP)协议，而RTMP是使用Transmission Control Protocol (TCP)协议。

UDP协议对比TCP协议最大的优点就是传输流媒体数据的时候效率非常高，网络延迟少，增强音视频的传输质量，以及网络连接的可靠性增强。
RTMP的客户端之间要进行数据通信，必须先将数据发送到FMS等服务器端，然后服务器端再转发到另外一个用户，而RTMFP则支持客户端直接发送数据到另外一个客户端，无需经过服务器的中转。此时你也许会问，居然客户端之间的数据可以之间通信，还要FMS服务器做什么？其实此时的FMS服务器只起到桥梁作用，因为客户端之间要创建通信会话就必须要知道对方客户端的相关信息，就相当于你找对象要先经过媒婆介绍一样的道理，哈哈。

下面的示意图表现了RTMFP和RTMP的不同之处：

RTMFP适合用于哪些类型的应用？

RTMFP比较适合用于网络通信数据量比较大，通信即时性要求比较强的应用，例如VoIP，音视频即时沟通工具（IM），多人网络游戏等等。

Adobe以后还会丰富RTMFP相关技术吗？

会的，Adobe以后还会一如既往地对RTMFP进行进一步增强、优化以适合市场发展的需求，不过目前还没有进一步的相关声明。

推送去有支援rtmp的mediaserver，不過延遲的問題可能要考慮到buffertime

打造一個多人視訊系統

請注意參數設定的

ams.ini Application.xml terminal

這關係到應用程式是否能正常運行，上述檔案有關檔案是否有權限。

防火牆設定

最重要!，連到伺服器外面端口，一定要把輸出輸入原則納編新增連接端口1935設為允許，
不同電腦之間連接，防火牆一定要設置，否則debug到爽。

shareObject

痾最後我不打算用shareObject，由於在性能上，適用共享去廣播參數，這會導致客戶端有無想接收訊息都會接受到廣播，第二個原因就是我弄到今天，在flash非同步的狀況下，fso檔案到底有沒有被寫入，原因可能就是上述，功力不夠?，綜合以上所已改用其他來開發

https://blog.csdn.net/wkyb608/article/details/5930823

結

上述算是未完成的程式碼懶得寫了，主要可以獲得該執行程式可以透過廣播的方式去傳遞，只要自行定義傳遞參數，把自己直播推流，和id傳遞過來基本再加一點邏輯判斷，一對多多對多，基本上都可以，視訊，監視器，直播阿應該都可以透過adobe media server實現，rtmp ，至於詬病https://blog.csdn.net/haima1998/article/details/78007123，速度方面可能改天再做一個p2p之間的傳輸，目前adobe media server 會自動轉為 rtmfp所以之前的癥結點沒囉，目前等公司提案再來考慮要不要搭建其他平台囉。