転載は出典を明記してください.https://blog.csdn.net/impingoプロジェクトのアドレス:https://github.com/im-pingo/nginx-rtmp-module

目次

hls遅延現状

血脈純正lowlatency hls案

草の根出身のHLS+

オープンソースプロジェクトpingoを使用してhls+サービス

を構築

hls+テスト効果

QQ交流群:697773082

hls遅延現状

hlsの遅延が大きすぎるのはよく知られている状況で、ネット上でも多くの資料がなぜそんなに大きな遅延を生んだのかを分析しています.しかし、遅延を低減する案は非常に少ない.

血脈純正lowlatency hlsスキーム

2019年のWWDC大会でアップルはlowlatency hlsソリューションを提案し、遅延を2 s以内に減らすと主張した.しかし、同業者が公開したテスト結果によると、アップルの公式設備はまだこの案を完全に支持していないという.このスキームはhttp 2に基づいている.0実装は、実装プロセスが非常に複雑であり、大規模な普及にはCDNメーカーと各ブラウザメーカーの強力なサポートが必要である.これは非常に大きなソフトウェアのアップグレードであり、実際に導入されたのはいつなのか、最終的に普及する前により優れたソリューションが現れるかどうかは分からない.したがって、現在のところ、アップルが提案したlowlatency hls案を用いて低遅延を実現することは現実的ではない.ここにはlowlatency hlsソリューションの説明とテスト資料があります.参考にしてください.

草の根出身のHLS+

ネット上でhls+のソリューションが提案されていますが、大体の構想は再生側ごとに仮想sessionを維持することです.第1の保証スライスは、最も近いIフレームで開始され、第2の保証スライスは、十分に小さい(1 s以下).実際のテストの遅延は4 s程度に縮小できる.例えば、この文章で述べた解決策です.
このソリューションは比較的野道的に見えるが、確かに現在、実装コストが最も低く(http 1.0または1.1に基づいてm 3 u 8を変更していない)、メンテナンス性がより高いソリューションである.その利点は,この論文で述べたように,(1)従来のHLSプロトコルの遅延を大幅に低減する;
(2)HLS+はRTMP/FLVなどのプロトコルと同じストリームメディアサーバクラスタを共用し、CDNネットワークは設備グループ(多くの機械室と設備建設)を節約することができる.
(3)HLS+はRTMP/FLV/HLSなどと同じドメイン名を使用し、ユーザー配置が簡単で、使用が簡単で、ドメイン名CNAMEが簡単である.
(4)データの統一、システムが与えたオンライン人数、帯域幅、料金計算、盗難防止チェーン、認証など、すべて統一的に実現し、プロトコルを単独で区別する必要はない.
(5)ソースを統合し、RTMP/FLV/HLS+にアクセスするには、RTMPを1回だけ戻す必要があり、アクセス時にソースを返す必要があり、顧客のソース局の帯域幅とソースの圧力を大幅に低減する.
(6)高速誤り訂正、HLS+はクラウドBMSの遡及可能なログを使用し、ミリ秒レベルで各クライアントのリンクデータをキャプチャし、高速誤り訂正を実現することができる.
(7)高速起動、GOP最適化により感覚差のない高速起動が可能
(8)404を回避し、HLSはスライスファイルの配布であり、一定の確率の404があり、HLS+はフローバックソースのためにこの状況を根絶した.
(9)各スライスは、ソース局からエッジまでの間、各スライスが、ソースに戻る時間を避ける一方、HLS+は、長い接続を使用してソースに戻る.

オープンソースプロジェクトpingoを使用してhls+サービスを構築

プロジェクトのアドレス:https://github.com/im-pingo/nginx-rtmp-module
pingoプロジェクトはnginx-rtmp-moduleに基づいて実現されたhls hls+http-ts http-flv rtmpの複数の生中継プロトコルをサポートするストリーミングメディアサーバであり、現在数社が使用している.その他のプロトコルの構成は私の前の文章分布式生放送システム(二)【単点rtmphttp-flvhlsストリームメディアサーバを構築する】を参考にすることができ、各プロトコルの構成方法と詳細な構成テンプレートが詳しく紹介されています.ここではhls+の構成テンプレートのみを提供します.

user  root;
daemon on;
master_process on;
worker_processes  1;
#worker_rlimit 4g;
#working_directory /usr/local/openresty/nginx/logs;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
error_log  logs/error.log  info;

worker_rlimit_nofile 102400;
worker_rlimit_core   2G;
working_directory    /tmp;

#pid        logs/nginx.pid;

events {
    use epoll;
    worker_connections  1024;
    multi_listen unix:/tmp/http 80;
}

stream_zone buckets=1024 streams=4096;

rtmp {
    log_format log_json '{$remote_addr, [$time_local]}';
    access_log logs/rtmp.log trunc=2s;
    server {
        listen 1935;
        serverid 000;
        out_queue 2048;
   
        application live {
            rtmp_auto_pull on;
            rtmp_auto_pull_port unix:/tmp/rtmp;
            live on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 1300ms;
            hls_max_fragment 1800ms;
            hls_playlist_length 3900ms;

            hls2memory on;
            mpegts_cache_time 20s;

            hls2_fragment 1000ms;
            hls2_max_fragment 1300ms;
            hls2_playlist_length 3000ms;

            wait_key on;
            wait_video on;
            cache_time 3s;
            low_latency off;
            fix_timestamp 0s;
# h265 codecid, default 12
            hevc_codecid  12;
        }
    }
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_X-Forwarded-For" "$http_X-Real-IP" "$host"';


    access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #reset_server_name www.test1.com www.test2.com;
    #gzip  on;
    server {
         listen 80;
        location /rtmp_stat {
            rtmp_stat all;
            rtmp_stat_stylesheet /stat.xsl;
        }

        location /xstat {
            rtmp_stat all;
        }

        location /sys_stat {
            sys_stat;
        }

         location /live {
            flv_live 1935;
         }
         location /hls {
            # Serve HLS fragments
             types {
                 application/vnd.apple.mpegurl m3u8;
                 video/mp2t ts;
             }
             root /tmp;
             expires -1;
             add_header Cache-Control no-cache;
         }

        location /hls2 {
             hls2_live 1935 app=live;
             add_header 'Access-Control-Allow-Origin' '*';
         }
         location / {
             chunked_transfer_encoding on;
             root html/;
         }
    }
}

上記の構成テンプレートを使用して、プッシュフローをテストします:rtmpプッシュアドレス:rtmp://i p/l i v e/{ip}/live/ip/live/{stream}hls+(http://i p/h l s 2/{ip}/hls 2/{stream}http://i p/l i v e/{ip}/live/ip/ip/live/ip/live/{stream}rtmp再生アドレス:rtmp://i p/l i v e/{ip}/live/ip/live/{stream}

hls+テスト効果

上記の構成テンプレートを例にとると、プッシュエンドは2 s gopサイズに設定され、最終試験遅延は約4 s~5 sである.hls+とhttp-flv、rtmp、および従来のhls生中継遅延の比較例を図に示す.

QQ交流群：697773082