nginx-rtmp-module 모듈을 기반으로 구현된 HTTP-FLV 라이브 방송 모듈 nginx-http-flv-module을 이해하는 방법

이 글의 내용은 nginx-rtmp-module 모듈을 기반으로 하는 HTTP-FLV 라이브 방송 모듈 nginx-http-flv-module을 이해하는 방법에 대한 것입니다. 필요한 친구들이 참고할 수 있기를 바랍니다. 도움이 됩니다.

현재 많은 개인과 제조사가 이 모듈의 상용화를 준비하고 있습니다. 네티즌들의 피드백에 따르면 이미 이 모듈을 사용하는 해외 생방송 웹사이트가 있습니다. 상용화를 준비하고 있는 가장 유명한 제조사는 화웨이입니다. 네티즌들과 제조사들이 많은 버그를 제보해 왔는데, 수리 후 기능이 점점 더 안정되어 감사의 말씀을 전하고 싶습니다.

2018-06-04: CDN 제조업체는 nginx-http-flv-module을 공식 출시했으며, RTMP 방식을 사용하고 gop_cache 구성을 켭니다(인터리브 구성을 끄면 켤 때 지연이 발생하거나 소리가 들리지 않습니다). , 현재 어떻게 해결해야 할지 모르겠습니다.) 고객으로는 Inke와 Weihou가 있습니다.

2018-06-28: 온라인 비디오 제조업체는 gop_cache 구성을 활성화하지 않고 HTTP-FLV 방법을 사용하여 nginx-http-flv-module을 공식적으로 출시했습니다. 아직 완전히 활성화되지 않았으며 안정성을 관찰하기를 기다리고 있습니다.

2018-07-28: 일부 네티즌의 요구에 부응하여 RHEL6(CentOS 6) 및 RHEL7(CentOS 7)용 rpm 설치 패키지가 제공되었습니다. nginx-http-flv-module-packages를 참조하세요.

                    nginx-http-flv-module 및 nginx-rtmp-module 기능 비교:

Function	nginx-http-flv-모듈	nginx-rtmp-모듈	비고
HTTP-FLV	√	×	nginx-http-flv-module은 HTTPS-FLV를 지원합니다
GOP 캐시	√	×
vhost	√	×
듣기 구성 생략	√	x
JSON 스타일 통계	√	x
RTMP 302	베타	×	nginx-http-flv-모듈을 서버 또는 클라이언트로

2018-03-09 업데이트:

최근에는 다양한 플랫폼에서 모듈의 안정성을 주로 테스트했지만 현재 이 부분에서는 조건부 제한으로 인해 테스트를 거치지 않았습니다. FreeBSD 플랫폼인 Windows 7, Debian 7.x 둘 다 macOS Sierra에서 테스트되었습니다. Windows에 대한 Nginx의 공식 지원은 그다지 좋지 않고 Windows 플랫폼에서 가장 강력한 IOCP 인터페이스를 사용하지 않기 때문에(select가 사용됨) Windows 플랫폼의 운영 효율성은 그다지 높지 않으며 이는 푸시 스트리밍 대기 시간에 반영됩니다. 3초 이상, 첫 번째 화면 시간이 4초 이상 매우 길고 선택 자체로 인해 클라이언트 수가 제한됩니다. , 기본값은 1024입니다. 푸시 스트리밍 대기 시간과 첫 번째 화면 시간이 가장 짧은 것은 macOS Sierra입니다. 이 컴퓨터에서 테스트하면 기본적으로 몇 초 내에 푸시되고 열립니다. 어젯밤에 특별히 주의를 기울였습니다. macOS Sierra에서 컴파일할 때 SO_REUSEPORT와 TCP_FASTOPEN이 모두 지원됩니다. 전자는 Nginx의 각 하위 프로세스를 수신할 수 있게 하고 후자의 경우 천둥소리 효과를 해결하는 전용 승인 대기열을 갖습니다. 핸드셰이크가 완료된 후 실제 데이터를 전송하는 대신 SYN이 시작될 때 이미 전달됩니다. 몇 초 만에 밀어서 여는 것은 이 두 가지 옵션과 관련이 있을 수 있습니다. 하지만 macOS Sierra는 프로세스를 CPU에 바인딩하는 것을 지원하지 않기 때문에 프로세스 컨텍스트 전환에 오버헤드가 있을 수 있고, 시스템 부하가 클 경우 효율성이 Linux만큼 좋지 않을 수 있습니다. macOS Sierra는 회사 컴퓨터이므로 스트레스 테스트는 수행되지 않았습니다. 내 노트북에는 Debian 7.x가 설치되어 있습니다. 커널 버전이 낮기 때문에 macOS Sierra에서 지원되는 두 가지 옵션이 지원되지 않습니다. 테스트 중 푸시 대기 시간과 첫 번째 화면 시간은 Windows 7과 macOS Sierra 사이였습니다. 서버(시스템 CentOS 6.4, SO_REUSEPORT는 지원하지만 TCP_FASTOPEN은 지원하지 않음)에서는 macOS Sierra와 유사했지만 서버의 CPU 성능이 훨씬 강력하므로 macOS Sierra는 부하가 높지 않을 때 가장 잘 작동합니다. macOS Sierra는 Mac OS X에서 업데이트되고, Mac OS X의 하위 레이어는 원래 FreeBSD를 기반으로 개발되었기 때문에 FreeBSD에서의 성능도 좋을 것이라는 추측이 나옵니다.

또한 최근 RTMP 302 리디렉션을 HTTP 302 리디렉션으로 변환하는 기능을 추가하려고 합니다. 많은 플레이어가 RTMP 302 리디렉션을 지원하지 않기 때문에 HTTP 302 리디렉션을 지원하는 기능은 기본적으로 표준이며 실제 테스트 VLC에서는 지원합니다. 그것. 현재 기능은 기본적으로 완료되었으나, 문제가 되는 부분은 HTTP 프레임워크의 전송 인터페이스를 사용할 때 오랜 시간 동안 재생하면 연결 리스트가 루프를 형성하게 되어 진행을 계속할 수 없고 아직까지 진행되지 않고 있다는 점입니다. github으로 업데이트되었습니다. 다음은 nginx의 기본 rtmp 구성 조각과 VLC 재생 중 HTTP 302 리디렉션 스크린샷입니다. 푸시 스트림은 hls라는 애플리케이션에 푸시됩니다(FFmpeg는 RTMP 302 리디렉션을 지원하지 않으므로 hls로만 푸시할 수 있습니다).

application myapp {

rewrite '^/myapp/(.*)' '/hsl/$1';

}

1.HTTP 302 리디렉션 패킷 캡처 스케치

2.HTTP 302 리디렉션 상세 사진 방향성 패킷 캡처

2018-03-15 업데이트:

일부 네티즌들은 디버깅 후 추가된 ngx_http_flv_live 모듈의 순서에 문제가 있어서 on_play 명령을 사용할 수 없다고 보고했습니다. 이제 모듈의 순서가 변경되지 않는다는 전제로 수정되었습니다. 다음으로 일부 상태 수정을 통해 우회되고 일부 기능은 나중에 호출되어 해당 기능이 원래 nginx-rtmp-module과 일치하는지 확인합니다.

2018-03-16 업데이트:

일부 네티즌이 제안한 CORS(교차 도메인) 기능을 이제 사용할 수 있습니다. HTTP-FLV 응답 데이터는 더 이상 하드 코딩되지 않고 일부 HTTP의 코드를 사용하여 다시 작성되었습니다. 프레임워크. 또한 on_connect 기능에 문제가 있어 일시적으로 사용이 불가능하여 수리를 기다리고 있습니다.

2018-03-18 업데이트:

on_connect 문제가 수정되었습니다.

2018년 3월 20일 업데이트:

검색할 애플리케이션이 첫 번째 서버 블록에 없어 해당 on_connect 및 on_play를 찾을 수 없는 버그를 수정했습니다. 조사 결과 올바른 서버 구성이 발견되었습니다. 일치하지 않아 수정되었습니다.

2018년 3월 22일 업데이트:

오래 전에 일부 네티즌들은 유휴_스트림이 꺼짐(기본값은 켜짐)으로 설정되어 있으면 HTTP-FLV를 사용하여 풀을 재생할 수 없다고 제안했습니다.

2018-03-25 업데이트:

일부 네티즌은 flv.js를 사용하여 nginx-http-flv-module에서 가져온 라이브 스트림을 재생하고 버그를 발견했습니다. (1) 사용된 Nginx 버전 번호가 1.13.9인 경우, (2) 플레이어는 flv.js입니다. (3) 풀 스트림을 재생할 때 flv.js가 HTTP 헤더 "Connection: keep-alive", nginx-http-를 전송하기 때문에 재생되지 않습니다. flv-module 업스트림에 요청을 하면 일반적으로 업스트림 요청이 반환되기 전에 다운스트림 요청이 반환됩니다. 그러나 Nginx는 버전 1.13.1부터 r->blocked 판단을 삭제했으며 "Connection: keep-alive"가 발생합니다. ngx_http_finalize_request ngx_http_set_keepalive를 호출하면 이 함수는 등록된 정리 함수를 호출하여 다운스트림 요청을 닫고 재생이 실패하게 됩니다. 이미 수정되었습니다. 이 버그를 디버깅하는 과정에서 nginx-http-flv-module이 gop_cache 구성 항목 flv.js을 켰을 때 다른 주류 플레이어(예: vlc)와 비교했을 때 첫 번째 화면이 시간은 지연이 거의 없이 가장 빠릅니다. 사용된 풀 소스는 홍콩 위성 TV의 라이브 소스입니다: rtmp://live.hkstv.hk.lxdns.com/live/hks.

2018-03-27 업데이트:

코드만 변경하면 버그가 있어서 정말 짜증납니다. 최근 일부 네티즌들의 요청에 따라 맞춤형 HTTP 헤더 추가 기능이 수정되어 Nginx의 HTTP 프레임워크의 필터 인터페이스를 다시 도입하려 했으나 여전히 실패하여 간단하고 투박하게 골랐습니다. 마지막 필터 모듈과 header_filter 모듈을 사용하지 않는 코드를 많이 제거했습니다. Nginx의 공식 안정 버전인 nginx-1.12.2는 github에서의 컴파일에 사용됩니다. 그 결과, 오늘 일부 네티즌들은 컴파일이 불가능하다는 제보를 했는데요, 확인해 보니 제가 nginx-rtmp-module을 수정한 이후로 계속 사용하고 있는 nginx-1.11.10에 이런 찾을 수 없는 매크로가 추가된 현상이 발생했습니다. , 네티즌이 사용하는 버전이 낮아서 컴파일할 수 없어 수정되었습니다.

2018-03-29 업데이트:

며칠 전 일부 네티즌들은 nginx-1.13.1 이상 버전을 사용하여 nginx-http-flv-module로 컴파일할 때 flv.js를 사용하여 풀 스트림을 재생한다고 보고했습니다. 2018-03-25 업데이트를 참조하여 스트림을 먼저 푸시한 후 flv.js를 사용하여 재생하지 못하는 문제도 쉽게 해결되었습니다. 최신 버전의 Nginx와 약간 오래된 버전(nginx-1.11.10)이 테스트를 거쳐 통과되었습니다.

2018-04-05 기록:

이번 업데이트는 아닙니다 :) 어제 일부 네티즌들이 flv.js를 사용하여 푸시 스트림을 재생할 때 nginx에 문제가 있는 줄 알았는데 재생되지 않는다는 제보가 있었습니다. http-flv-module을 다시 테스트해서 최신 nginx-1.13.10으로 컴파일했습니다. push 및 pull 스트림 재생에는 문제가 없습니다. 공식 안정 버전인 nginx-1.12.2로도 컴파일했습니다. 아직 문제는 없습니다. 오늘 밤에 어디에서 문제가 발생하는지 확인하겠습니다. 당시 한 네티즌은 브라우저에서 flv.js의 수를 제한했다고 밝혔습니다. 테스트에 따르면 단일 브라우저에서만 가능했습니다. 6 flv.js를 열어서 오늘 정오에 Firefox로 테스트했는데 역시 같은 문제가 발생했습니다. 문제가 nginx-http-flv-module이 아닌 것을 확인할 수 있습니다. 그러나 이는 매우 중요한 정보입니다. flv.js 재생을 지원하는 브라우저 수에는 제한이 있습니다. Chrome과 Firefox는 모두 6개로 제한됩니다. 다른 브라우저는 테스트되지 않았습니다.

2018-04-06 업데이트:

이전 통계에는 http-flv 라이브 방송의 허용 수 및 출력이 포함되지 않았지만 이제 추가되었습니다. 이제 flv.js에 대한 지원이 안정되었으므로 다음은 flv.js를 사용하여 재생한 스크린샷입니다.

한 상용 제조업체에서 비디오 소스가 순수 비디오인 경우 어떤 플레이어를 사용하더라도 재생 연결에는 문제가 없지만 계속 수신됩니다. 비디오 데이터를 사용할 수 없습니다. 디버깅 후 순수 오디오를 판단하는 로직에 버그가 있어 nginx-http-flv-module이 무한 루프되는 것으로 나타났습니다. 오디오 및 비디오 데이터 전송을 위한 인터페이스가 수정되었습니다.

2018-04-14 업데이트:

어제 일부 네티즌들은 gop_cache 옵션이 켜져 있으면 푸시 스트리밍으로 인해 메모리 누수가 발생한다고 보고했습니다. 푸시 시 Gop 캐시 모듈에서 할당한 메모리가 해제되지 않는 것으로 나타났습니다. 흐름이 꺼졌습니다. 이 문제가 해결되었습니다. 또한 네티즌들의 피드백에 따르면 다중 프로세스 모드에서 on_connect 및 on_play 명령에 문제가 있다고 합니다. 수리를 기다리는 동안 당분간 다중 프로세스 모드에서 이 두 명령을 사용하지 마십시오.

2018년 4월 15일 업데이트:

한 상용 제조사에서 랜덤 플래시 테스트 중에 메모리가 계속 증가한다고 보고했는데, 야간 디버깅 중에 메모리 누수가 있는 것으로 의심되는 것으로 확인되었습니다. ngx_http_request_t 구조의 메모리 풀이 해제되지 않아 실제로 메모리 누수가 발생했으며 수정되었습니다.

2018-04-21 업데이트:

일부 네티즌들은 다중 프로세스 모드에서 on_play가 인증 작업에 사용되지만 스트림을 푸시할 때 로컬 릴레이(스트림을 수락하는 하위 프로세스)가 스트림을 다른 프로세스로 푸시한다고 보고했습니다. 하위 프로세스))도 on_play 인증을 수행하는데, 이는 이전에 인증이 수행되었기 때문에 불합리하지만 실제로는 버그는 아닙니다. 이제 로컬 릴레이의 on_play 작업이 제거되었습니다. nginx-http-flv-module은 on_play가 무엇에 사용되는지 상관하지 않지만 로컬 릴레이가 더 이상 on_play 작업을 수행하지 않아야 한다는 점을 고려하면 수정된 코드가 비교적 간단하고 복구가 가능합니다. 쉽기 때문에 임시로 이렇게 수정해 보세요. 또한, 네티즌 @qqzzzx가 보고한 스트레스 테스트 충돌 문제가 부분적으로 수정되었습니다. 남은 문제는 스트레스 테스트 그룹 연결이 끊어진 후 메모리 누수가 발생한다는 점입니다. 수정 후 github에 업데이트할 예정입니다.

2018-04-25 업데이트:

스트레스 테스트 충돌 문제가 수정되었으며, 과도한 CPU 사용 문제도 해결되었습니다. 스트레스 테스트가 1시간 이상 진행되었습니다(srs-bench 자체 테스트). 비디오, 500 HTTP-FLV 및 200 RTMP), 아직 문제가 발견되지 않았습니다. 버그를 신고해 주시면 감사하겠습니다.

2018-05-12 업데이트:

일부 네티즌들은 gop_cache 옵션을 켜면 스트레스 테스트로 인해 메모리가 많이 소모되는 경우가 있다고 보고했습니다. 스트레스 테스트는 여러 번 재현할 수 없다. 네티즌들은 스트레스 테스트 도구와 서버가 같은 호스트에 있지 않으면 재현하기 쉽다고 지적했다. 이런 식으로 스트레스 테스트를 재현하는 것이 실제로 더 쉽습니다. 그러나 메모리 소비가 상대적으로 크다면 스트레스 테스트를 중지한 다음 스트레스 테스트를 반복하면 동시성 수가 변하지 않는다는 것이 증명됩니다. 메모리 누수 문제가 아니라는 것입니다. 소스 코드를 반복해서 확인한 결과, GOP를 보낼 때 GOP 데이터가 동시에 송신 링 배열에 들어가는 것으로 추측했습니다. Nginx는 비동기식이며 비차단형이기 때문에 Nginx는 실제로 링 배열에서 네트워크로 데이터를 보내지 않을 수도 있습니다. (예를 들어, 서버와 클라이언트 사이의 네트워크 대역폭이 부족한 경우) 할당된 메모리는 즉시 재활용할 수 없으며 실제로 GOP가 전송된 후에는 할당된 메모리가 더 이상 해제되지 않습니다(메모리 풀에서 및 이를 사용하여). 연결과는 아무 관련이 없으며 구성 구조만 관련됩니다). 후속 데이터 전송은 한꺼번에 전송되는 GOP 데이터와는 다르므로 재활용된 메모리를 완전히 사용할 수 없으며 많은 부분이 유휴 상태입니다. 이제 자체 독립 메모리 풀을 사용하도록 gop 캐시 모듈을 수정하고, GOP가 전송된 후 이 메모리 풀을 해제합니다.

2018-05-14 업데이트:

2018-05-12 업데이트에서 소개된 메모리 누수 버그를 수정했습니다. 오랜 시간이 지나서 문제가 발생했을 때 변경했습니다. 높은 버전의 gcc 컴파일 프로젝트가 실패한 버그를 수정합니다(온라인으로 확인했는데, gcc-7.x.x는 특정 컴파일 옵션을 추가할 때 스위치 케이스에 오류가 있는지 확인합니다). 아직 발견되지 않은 컴파일 오류가 있을 수 있으며 현재 네티즌들의 답변을 기다리고 있습니다.

2018-05-16 업데이트:

낮에 gcc-7.2.0을 컴파일하고 설치했는데 컴파일 경고를 통해 모든 가을을 알아냈습니다(Nginx 컴파일 옵션은 오류로 간주) 버그가 수정되었습니다.

2018-05-18 기록:

업데이트가 아닌데 2018-05-12 업데이트 때 스트레스 테스트 중(도구) 켜졌었나 봐요. 사용된 것은 srs-bench) gop_cache 옵션이 메모리를 많이 소모하는 이유는 오늘 밤 로그를 확인해본 결과 이전 추측이 주된 이유가 아니라는 것을 알았습니다. Nginx는 항상 128바이트의 데이터를 수신한다는 것을 로그에서 볼 수 있습니다. 구성에 Chunk_size 구성 항목이 지정되지 않은 경우, 즉 서버가 Set Chunk Size 프로토콜 제어 메시지를 보낸 후 기본값은 4096바이트입니다. , 클라이언트 클라이언트가 Set Chunk Size 프로토콜 제어 메시지에 응답하지 않았기 때문에 서버는 이전 128바이트를 계속 사용했습니다. 최악의 경우 nginx-http-flv-module이 패키지에 메모리를 할당하게 됩니다. 128바이트의 데이터를 압축하기 위해 너무 많은 바이트(4096 + 최대 RTMP 헤더 크기)의 공간을 사용하면 32배 더 많은 데이터가 낭비됩니다. 비교 테스트에는 ffmpeg를 사용하세요. ffmpeg는 Set Chunk Size 프로토콜 제어 메시지에 응답하므로 메모리 낭비가 발생하지 않습니다. SRS(Simple-RTMP-Server) 작성자에게 문제가 제출되었습니다. 시간이 나면 nginx-http-flv-module의 이 예외 처리 방법을 업데이트하겠습니다.

2018-05-20 업데이트:

경우에 따라 특히 메모리 소모 문제가 수정되었습니다. 그래도 사용량이 너무 크다면 위에서 언급한 두 번째 이유 때문에 발생했습니다.

2018-06-14 업데이트:

네티즌들이 신고한 문제를 수정했습니다. 일정 시간 동안 실행한 후 ngx_stat_active 매개변수의 값이 잘못된 것으로 나타났습니다. 반복된 빼기 작업으로 인해 발생한 문제입니다. 예, 수정되었으며 정상적인 기능에는 영향을 미치지 않습니다.

2018-06-19 업데이트:

nginx-rtmp-module의 풀 요청에서 여러 버그 수정을 동기화했습니다. 기본적으로 주요 변경 사항은 모두 동기화되지 않았습니다. 또한 nginx-http-flv-module에 fmp4를 직접 푸시하는 기능이 추가되었습니다. 오늘 밤에는 MSE(Media Source Extensions, 현재 iOS의 Safari에서는 지원되지 않는 Media Source Extensions)를 지원하는 브라우저에 순수 비디오 fmp4를 직접 푸시하도록 구현되었습니다. ) 재생하면 오디오가 나중에 추가됩니다.

2018-06-25 업데이트:

fmp4 푸시의 기본 기능이 기본적으로 완료되었습니다. 일부 네티즌이 stat를 JSON 형식으로 지원하는 PR을 푸시했는데, 시도해 보니 작은 버그도 수정되었습니다.

2018-06-29 업데이트:

두 제조사가 공식적으로 RTMP를 상용화한 점을 고려하여 stat의 원래 rtmp 정보를 http-flv로 수정합니다(켜기). gop_cache) 및 HTTP-FLV(gop_cache 활성화 안 함)가 마일스톤 버전 1.2.4를 출시했습니다.

2018-07-09 업데이트:

3가지 작은 버그 수정: DASH 기능이 켜져 있으면 파일에서 읽은 데이터가 다음과 같기 때문에 무한 루프가 발생할 수 있습니다. 0 ;xml stat에 nginx-http-flv-module의 버전 번호를 표시할 수 없는 문제를 수정했습니다(네티즌의 홍보). HEAD 요청이 flv_live를 구성하지 않을 때 405(허용되지 않는 메소드)를 반환하는 버그를 수정했습니다. 위치

위 내용은 nginx-rtmp-module 모듈을 기반으로 구현된 HTTP-FLV 라이브 방송 모듈 nginx-http-flv-module을 이해하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!