VIGI NVR OpenAPI의 RTSP 스트림 인터페이스 사용 방법

내용

서론

요구 사항

설정

NVR RTSP 설정 확인

RTSP를 통한 라이브 뷰 및 재생 스트림 액세스

통화 음성 전송 프로세스

결론

질문과 답변

 

서론

VIGI NVR OpenAPI는 라이브 뷰, 재생, 통화 음성 전송을 위한 RTSP 기반 스트림 인터페이스를 지원합니다. 라이브 뷰/재생은 클라이언트가 오디오 및 비디오 스트림을 수신하여 실시간 영상/녹화 영상에 액세스할 수 있는 기능이며, 통화는 마이크 음성을 선택한 카메라 채널로 전송하는 기능입니다.

이러한 기능은 RTSP를 통한 세션 설정 및 제어, 다이제스트 인증을 통한 액세스 인증, RTP를 통한 미디어 데이터 전송으로 구현됩니다. 라이브 뷰 및 재생의 경우, RTSP SETUP 프로세스에서 협상된 전송 모드에 따라 TCP 연결이나 UDP 연결로 RTP 데이터를 전송합니다. 이 문서에서 설명하는 통화 음성은 별도의 세션에서 전용 TCP 연결을 통해 전송됩니다.

요구 사항

• OpenAPI를 지원하는 VIGI NVR (지원 장치는 ‘VIGI Open API 지원 장치’에서 확인)
• VIGI NVR OpenAPI 문서
• 네트워크를 통해 NVR에 접속할 수 있는 RTSP 클라이언트 또는 타사 플랫폼

설정

NVR RTSP 설정 확인

VIGI NVR OpenAPI 스트림 인터페이스는 RTSP를 기반으로 구현됩니다. VIGI NVR에서는 RTSP가 기본적으로 활성화되어 있으며, 기본 RTSP 포트는 554입니다. 라이브 뷰 또는 재생 스트림에 액세스하거나 통화 세션을 설정하기 전에 RTSP가 활성화되어 있는지 확인하고, 설정한 RTSP 포트를 확인하십시오.

다음 과정에서는 NVR 웹 관리 페이지를 예시로 사용합니다.

1단계. NVR의 IP 주소를 사용하여 NVR 웹 인터페이스에 로그인합니다. 사용자 이름과 비밀번호를 입력한 후 ‘로그인’을 클릭하세요.

 

2단계. 설정 > 네트워크 > 네트워크 서비스 > RTSP(S)로 이동합니다. RTSP 스위치가 활성화되어 있는지 확인하고, 설정된 RTSP 포트를 기록해 두세요.

참고: RTSPS 및 SRTP는 비활성화되어 있어야 합니다. 활성화되어 있으면 타사 플랫폼이 표준 RTSP를 통해 스트림에 액세스하지 못할 수 있습니다.

 

RTSP를 통한 라이브 뷰 및 재생 스트림 액세스

VIGI NVR의 라이브 뷰 및 재생 인터페이스는 표준 RTSP를 사용하여 스트리밍 세션을 설정하고 제어하며, RTP는 오디오 및 비디오 데이터를 전송합니다. 표준 RTSP 클라이언트나 타사 플랫폼은 해당 URL을 사용하고 RTSP 인증 및 세션 설정을 완료하여 스트림에 액세스할 수 있습니다.

라이브 뷰와 재생은 전반적으로 동일한 절차를 따르므로, 다음 워크플로에서는 라이브 뷰를 예시로 다룹니다. 재생의 경우, 해당하는 재생 URL과 시간 범위를 사용하세요. 지원되는 메서드, URL 형식, 매개변수, 다이제스트 인증에 관해서는 VIGI NVR OpenAPI 문서의 5.1~5.3절과 본 문서의 질문과 답변 섹션에 있는 Q2에서 알아보세요.

1단계. RTSP 연결을 설정하고 지원되는 메서드를 조회합니다.

먼저 클라이언트가 사전 설정된 RTSP 포트(기본값인 554)를 통해 NVR과 TCP 연결을 설정합니다. 그 과정은 다음과 같습니다.

 

(1) NVR이 지원하는 RTSP 메서드를 조회하기 위해 클라이언트가 인증되지 않은 최초 OPTIONS 요청을 전송합니다.

/* No authentication request  */ C->S : OPTIONS rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 1\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n \r\n

 

(2) NVR은 200 OK를 반환하고 지원되는 RTSP 메서드 목록을 Public 헤더에 나열합니다.

S->C : RTSP/1.0 200 OK\r\n CSeq: 1\r\n Date: Mon, 20 Jul 2026 21:57:33 GMT\r\n User-Agent: vigi\r\n Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER\r\n Content-Length: 0\r\n \r\n

 

다음 Wireshark 캡처는 최초 OPTIONS 요청과 그에 따라 NVR이 반환한 200 OK 응답을 보여줍니다.

 

2단계. 미디어 설명 요청 및 다이제스트 인증 완료

클라이언트가 요청한 스트림의 미디어 설명을 가져오기 위해 인증되지 않은 DESCRIBE 요청을 보냅니다. 이 요청에는 인증 정보가 포함되어 있지 않으므로 NVR이 401 Unauthorized로 응답하고 WWW-Authenticate 헤더에 다이제스트 인증 챌린지를 제공합니다.

 

(1) 클라이언트가 SDP 미디어 설명을 가져오기 위해 인증되지 않은 DESCRIBE 요청을 보냅니다.

/* No authentication request */ C->S : DESCRIBE rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 2\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Accept: application/sdp\r\n \r\n

 

(2) NVR이 401 Unauthorized를 반환하고 WWW-Authenticate 헤더에 Digest 인증 챌린지를 제공합니다.

S->C:\r\n RTSP/1.0 401 Unauthorized\r\n CSeq: 2\r\n User-Agent: vigi\r\n WWW-Authenticate: Digest realm="vigi", nonce="668a48d0", stale="FALSE"\r\n Content-Length: 0\r\n \r\n

참고: 401 Unauthorized 응답은 다이제스트 인증 과정에서 거치는 과정이며, 최종적인 인증 실패를 의미하지는 않습니다.

 

(3) 클라이언트가 WWW-Authenticate 헤더에서 realm과 nonce를 가져오고 사용자 이름, 암호, 현재 RTSP 메서드, 요청 URI와 함께 사용하여 다이제스트 응답을 계산합니다. 그런 다음 Authorization 헤더를 포함하여 DESCRIBE 요청을 다시 전송합니다.

예시:

Method (메서드): DESCRIBE

Request URI (요청 URI): rtsp://192.168.0.110:554/live/1/2/avm

다이제스트 알고리즘은 NVR에 설정된 인증 알고리즘과 일치해야 합니다.

이 예시에서 NVR은 MD5를 사용하도록 설정되어 있습니다.

HA1 = MD5(username:realm:password)

HA2 = MD5(method:request-uri)

response (응답) = MD5(HA1:nonce:HA2)

참고: 설정 > 네트워크 > 네트워크 서비스 > RTSP(S)에서 인증 알고리즘을 확인하세요. 클라이언트가 다이제스트 응답을 계산할 때 동일한 알고리즘을 사용해야 합니다.

 

클라이언트가 Authorization 헤더에 다이제스트 자격증명을 포함하여 DESCRIBE 요청을 다시 전송합니다.

C->S : DESCRIBE rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 3\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Accept: application/sdp\r\n Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm", response="<calculated_digest_response>"\r\n \r\n

 

(4) NVR이 다이제스트 응답을 검증합니다. 인증에 성공하면 SDP 미디어 설명과 함께 200 OK를 반환합니다.

SDP 응답에는 사용 가능한 미디어 트랙과 해당 트랙의 코덱 정보가 들어갑니다. 이 예시에서 track1은 H.264 동영상을, track2는 PCMA 오디오를 전달합니다.
참고: track3은 VIGI 전용 프로토콜로 정의된 데이터를 전달하며, 일반 동영상 및 오디오 스트리밍에는 필요하지 않습니다.

S->C : RTSP/1.0 200 OK\r\n CSeq: 3\r\n Date: Mon, 20 Jul 2026 19:01:11 GMT\r\n Content-Type: application/sdp\r\n Content-Length: 395\r\n \r\n <SDP> v=0\r\n s=Session streamed by "TP-Link RTSP Server"\r\n t=0 0\r\n m=video 0 RTP/AVP 96\r\n a=control:track1\r\n a=rtpmap:96 H264/90000\r\n a=fmtp:96 packetization-mode=1; profile-level-id=4D4032; sprop-parameter-sets=Z00AKpY1QPAET8s3AQEBQAABwgAAV+QB,aO48gA==\r\n m=audio 0 RTP/AVP 8\r\n a=control:track2\r\n a=rtpmap:8 PCMA/8000\r\n m=application/TP-LINK 0 RTP/AVP smart/0/25000\r\n a=control:track3\r\n a=rtpmap:95 TP-LINK/25000\r\n

 

 

3단계. 미디어 트랙을 설정하고 RTP 전송을 시작합니다.

인증에 성공하면 클라이언트가 필요한 미디어 트랙을 설정하고 전송 모드를 협상합니다. UDP 기반 RTP와 RTSP/TCP 기반 RTP가 모두 지원됩니다. 이 예제에서는 인터리브 전송 방식을 사용하는 RTSP/TCP 기반 RTP를 사용합니다.

 

(1) 클라이언트가 필요한 비디오 및 오디오 트랙에 대해 별도의 SETUP 요청을 전송하고 각 트랙의 전송 모드를 지정합니다. NVR은 각 요청에 대해 200 OK를 반환합니다. 이 예제에서는 두 트랙 모두 동일한 RTSP 세션 ID를 사용하며, 클라이언트는 RTSP/TCP를 통한 RTP를 요청합니다. 인터리브 채널 0과 1은 비디오 RTP 및 RTCP 스트림에 할당되고, 채널 2와 3은 오디오 RTP 및 RTCP 스트림에 할당됩니다.

C->S:\r\n SETUP rtsp://192.168.0.110:554/live/1/2/avm/track1 RTSP/1.0\r\n CSeq: 4\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Transport: RTP/AVP/TCP;unicast;interleaved=0-1\r\n Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm/track1", response="<calculated_digest_response>"\r\n \r\n   S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 4\r\n User-Agent: vigi\r\n Session: 0x7fb484;timeout=60\r\n Transport: RTP/AVP/TCP;interleaved=0-1\r\n Content-Length: 0\r\n \r\n   C->S:\r\n SETUP rtsp://192.168.0.110:554/live/1/2/avm/track2 RTSP/1.0\r\n CSeq: 5\r\n Session: 0x7fb484\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Transport: RTP/AVP/TCP;unicast;interleaved=2-3\r\n Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm/track2", response="<calculated_digest_response>"\r\n \r\n   S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 5\r\n User-Agent: vigi\r\n Session: 0x7fb484;timeout=60\r\n Transport: RTP/AVP/TCP;interleaved=2-3\r\n Content-Length: 0\r\n \r\n

 

참고: RTSP 인터리브 전송 모드에서는 여러 미디어 트랙의 RTP 및 RTCP 패킷이 동일한 TCP 연결을 공유하며, 인터리브 채널 번호로 구별됩니다.

 

(2) 클라이언트가 미디어 전송을 시작하기 위해 세션 ID가 포함된 PLAY 요청을 보냅니다.

C->S:\r\n PLAY rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 6\r\n Session: 0x7fb484\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Authorization: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm", response="<calculated_digest_response>"\r\n \r\n

 

 

(3) NVR이 200 OK를 반환하고, 설정된 RTSP TCP 연결을 통해 RTP 미디어 패킷 전송을 시작합니다.
참고: Wireshark의 Follow TCP Stream 화면에서는 인터리브 RTP 데이터가 RTSP 응답 뒤에 바이너리 콘텐츠 형식으로 표시됩니다.

S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 6\r\n Date: Mon, 20 Jul 2026 21:57:33 GMT\r\n User-Agent: vigi\r\n Session: 0x7fb484;timeout=60\r\n RTP-Info: url=rtsp://192.168.0.110:554/live/1/2/avm;seq=34976;rtptime=2315908260\r\n Content-Length: 0\r\n \r\n

 

PLAY 요청이 수락되면 클라이언트가 협상된 전송 방식을 통해 RTP 미디어 패킷을 지속적으로 수신합니다. 이 예제에서는 인터리브 전송 방식을 사용하여 설정된 RTSP TCP 연결을 통해 미디어 패킷이 전송됩니다.

 

4단계. RTP 미디어 패킷 파싱 및 디코딩

클라이언트가 RTP 미디어 패킷을 수신한 후에 파싱하고 디코딩하여 실시간 동영상을 렌더링하고 연결된 오디오를 재생합니다. 그 과정은 다음과 같습니다:

 

(1) RTP 패킷 헤더를 파싱합니다.

클라이언트가 시퀀스 번호, 타임스탬프, 마커 비트, 페이로드 유형과 같은 필드를 읽습니다. 시퀀스 번호는 패킷 순서와 패킷 손실을 감지하는 데 사용되며, 타임스탬프는 미디어 타이밍 및 동기화에 사용됩니다. 페이로드 유형은 SDP의 a=rtpmap 속성과 함께 사용되어 해당 코덱 및 클럭 속도를 식별하는 데 사용됩니다.

VIGI NVR 스트림에 대해 정의되거나 권장되는 페이로드 유형 값은 VIGI NVR OpenAPI 문서의 Appendix II, Payload Type(부록 II, 페이로드 유형’)을 참조하세요. 동적 페이로드 유형은 달라질 수 있으므로 NVR에서 반환하는 SDP 정보를 주요 기준으로 삼아야 합니다.

이 예시에서는:

a=rtpmap:96 H264/90000

a=rtpmap:8 PCMA/8000

페이로드 유형 96은 H.264 비디오를 전달하고, 페이로드 유형 8은 PCMA 오디오를 전달합니다.

 

(2) RTP 페이로드를 처리합니다.

클라이언트가 RTP 헤더를 제거하고 인코딩된 미디어 페이로드를 추출합니다. H.264 비디오는 클라이언트가 RTP 페이로드로부터 완전한 NAL 유닛을 재구성하며, 가능하다면 분리되거나 병합된 NAL 유닛도 포함합니다. PCMA 오디오는 클라이언트가 RTP 페이로드에서 G.711 A-law 오디오 샘플을 추출합니다.

 

(3) 미디어를 디코딩하고 렌더링합니다.
클라이언트가 재구성된 비디오 및 오디오 데이터를 해당 디코더로 전달합니다. FFmpeg와 같은 미디어 라이브러리는 H.264 비디오를 일련의 프레임으로 디코딩하고, PCMA 오디오를 재생 가능한 PCM 샘플로 변환할 수 있습니다. 그런 다음 클라이언트는 비디오 프레임을 렌더링하고 재생 장치를 통해 오디오를 출력합니다.

참고: 정확한 디패킷화 및 디코딩 과정은 SDP에서 식별된 코덱에 따라 달라집니다. 클라이언트는 지원되는 각 코덱에 대해 해당 RTP 페이로드 형식과 디코더를 구현해야 합니다.

 

통화 음성 전송 프로세스

'RTSP를 통한 라이브 뷰 및 재생 스트림 액세스'에서 설명한 바와 같이, 클라이언트는 라이브 뷰 세션을 통해 NVR로부터 비디오와 오디오를 수신합니다. 이 섹션에서는 클라이언트가 마이크 오디오를 캡처하여 NVR 또는 NVR이 관리하는 카메라로 전송하고 이를 스피커로 출력하는 '통화' 프로세스에 대해 설명합니다.

통화 기능은 VIGI 전용 RTSP 확장 기능을 통해 사용합니다. 클라이언트는 별도의 Talk 세션을 설정하고, 필요한 세션 명령, 오디오 형식, RTP 캡슐화 규칙에 따라 오디오를 전송해야 합니다.

 

1단계. 통화 전용의 RTSP 연결을 별도로 설정합니다.

클라이언트가 구성된 RTSP 포트를 통해 NVR과 별도의 TCP 연결을 설정합니다. 이 연결은 오디오 전송 전용이며 라이브 뷰 세션과는 별개로 작동합니다. 그런 다음 클라이언트가 /multitrans URI로 인증되지 않은 최초 MULTITRANS 요청을 전송합니다.

참고: MULTITRANS는 VIGI NVR에서 구현한 독점적인 RTSP 확장 기능으로, 표준 RTSP 세션에서 반환되는 Public 헤더에는 표시되지 않을 수 있습니다.

C->S:\r\n MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n CSeq: 1\r\n User-Agent: VIGI-Python-Talk/1.0\r\n Content-Type: application/json\r\n Content-Length: 0\r\n \r\n

 

 

2단계. 다이제스트 인증을 완료합니다.

최초 MULTITRANS 요청에는 인증 정보가 포함되어 있지 않으므로 NVR이 401 Unauthorized 오류와 함께 다이제스트 인증 챌린지를 반환합니다. 클라이언트는 이전 섹션에서 설명한 대로 다이제스트 응답을 계산하고, Authorization 헤더를 포함하여 MULTITRANS 요청을 다시 전송합니다.

S->C:\r\n RTSP/1.0 401 Unauthorized\r\n CSeq: 1\r\n Date Mon, 27 Jul 2026 22:42:08 GMT \r\n User-Agent: vigi\r\n WWW-Authenticate: Digest realm="vigi", nonce=" f62dd168 ", stale="FALSE"\r\n Content-Length: 0\r\n \r\n   C->S:\r\n MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n CSeq: 2\r\n User-Agent: VIGI-Python-Talk/1.0\r\n Content-Type: application/json\r\n Content-Length: 0\r\n Authorization: Digest username="admin", realm="vigi", nonce="6061d988", uri="rtsp://192.168.0.110:554/multitrans", response="<calculated_digest_response>"\r\n \r\n

 

 

3단계. 통화 세션이 생성됩니다.

인증된 MULTITRANS 요청이 수락되면 NVR이 200 OK를 반환하고 통화 연결을 위한 전용 RTSP 세션을 생성합니다. 응답에는 RTSP 세션 값과 JSON 형식의 session_id가 포함됩니다. 클라이언트는 해당 값을 보관하여 이후의 통화 상호작용에 필요에 따라 사용해야 합니다.

S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 2\r\n Date: Mon, 27 Jul 2026 22:42:08 GMT \r\n User-Agent: vigi\r\n Session: 0x822e60\r\n Content-Type: application/json\r\n Content-Length: 80\r\n \r\n {"type":"response","seq":2,"params":{"error_code":0,"session_id":"14684328"}}

 

error_code 값이 0이면 Talk 세션이 성공적으로 생성되었음을 나타냅니다.

 

4단계. 통화 명령을 전송합니다.

통화 세션이 생성되면 클라이언트가 JSON Talk 명령이 포함된 또 다른 인증된 MULTITRANS 요청을 보냅니다. 이 명령은 통화 모드와 업로드된 오디오를 재생할 카메라 스피커가 있는 대상 NVR 채널을 지정합니다.

C->S:\r\n MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n CSeq: 3\r\n User-Agent: VIGI-Python-Talk/1.0\r\n Content-Type: application/json\r\n Content-Length: 93\r\n Session 0x822e60\r\n Authorization: Digest username="admin", realm="vigi", nonce="6061d988", uri="rtsp://192.168.0.110:554/multitrans", response="<calculated_digest_response>"\r\n \r\n {"type":"request","seq":1,"params":{"method":"do","talk":{"mode":"half_duplex","channel":1}}}   S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 3\r\n Date: Mon, 27 Jul 2026 22:42:08 GMT\r\n User-Agent: vigi\r\n Session: 0x822e60\r\n Content-Type: application/json\r\n Content-Length: 80\r\n \r\n {"type":"response","seq":3,"params":{"error_code":0,"session_id":"14684328"}}

 

error_code 값이 0이면 통화 명령이 성공적으로 수락되었음을 나타냅니다.

 

5단계. 통화 오디오 데이터를 준비하고 캡슐화하여 전송합니다.

통화 명령이 수락되면 클라이언트가 마이크 오디오를 캡처하여 필요한 통화 오디오 형식으로 변환합니다.

권장 오디오 설정:

• 코덱: G.711 μ-law
• 샘플 레이트: 16 kHz
• 오디오 채널: 모노
• 패킷 크기: 1056바이트
• 전송 간격: 패킷당 66 ms

대체 전송 프로필:

• 패킷 크기: 640바이트
• 전송 간격: 패킷당 40 ms

 

마이크가 48 kHz PCM과 같은 다른 기본 오디오 형식을 사용하면 클라이언트 애플리케이션이 전송 전에 오디오를 16 kHz로 리샘플링하고 모노로 변환한 후 G.711 μ-law로 인코딩해야 합니다

인코딩된 각 오디오 블록은 RTSP 인터리브된 바이너리 프레임에 캡슐화되어 전용 Talk TCP 연결을 통해 전송됩니다.

다음 예제는 권장되는 1056바이트 전송 프로필을 사용합니다.

$(1B)	채널 ID (1B)	길이 (2B)	원시 오디오 데이터
0x24	0x00	0x04 0x20	예시: 1056바이트 G.711 μ-law 페이로드

위에 표시된 값들은 테스트 구현에서 가져온 것입니다:

• 0x24는 RTSP 인터리브 프레임 식별자입니다.
• 0x00은 클라이언트 애플리케이션이 Talk 오디오 데이터를 위해 설정한 인터리브된 채널 ID입니다.
• 0x04 0x20은 뒤따르는 원시 오디오 데이터의 길이가 1056바이트임을 나타냅니다.
• 인터리브 헤더 뒤에 오는 데이터는 원시 G.711 μ-law 오디오이며 RTP 헤더를 포함하지 않습니다.

Length 필드는 실제 오디오 페이로드 크기와 일치해야 합니다. 대체 프로파일을 사용하는 경우, Length 필드는 0x02 0x80이며, 이는 640바이트 오디오 블록을 나타냅니다.

Talk 오디오 패킷 구조에 대한 자세한 내용은 VIGI NVR OpenAPI 문서의 5.4 Talk 섹션을 참조하십시오.

 

참고: 다음 Wireshark 16진수 덤프에서 강조 표시된 바이트는 위에 표시된 예제 프레임에 해당합니다.

 

결론

VIGI NVR 스트림 인터페이스를 사용하면 타사 클라이언트가 표준 RTSP 및 RTP 워크플로를 통해 라이브 뷰 및 재생 스트림에 액세스할 수 있습니다. 이 문서에서 설명한 워크플로에서 음성 오디오 전송은 별도의 VIGI 전용 통화 세션을 사용하여 마이크 오디오를 선택한 카메라 채널로 업로드합니다.

 

질문과 답변

Q1: VIGI NVR OpenAPI 문서는 어디에서 찾을 수 있나요?
A1: 다운로드 센터로 이동하여 NVR 모델을 검색한 후, 해당 제품 다운로드 페이지를 여세요. ‘매뉴얼’ 섹션에서 해당 VIGI NVR OpenAPI 문서를 다운로드하시면 됩니다.

 

Q2: 라이브 뷰 및 재생용 RTSP URL 형식은 어떻게 되나요?

A2: RTSP URL 형식은 다음과 같습니다.

라이브 뷰:

rtsp://<IP>/live/<channel>/<stream>/avm

재생:

rtsp://<IP>/replay/<channel>/<stream>/avm?starttime=<starttime>&endtime=<endtime>

• channel: NVR 채널 번호입니다.
• stream: 메인 스트림은 1, 서브 스트림은 2입니다.
• starttime 및 endtime: UTC+0 기준 YYYYMMDDtHHMMSSz 형식을 사용하여 재생 시작 및 종료 시간을 지정합니다. 펌웨어가 지원할 경우, z를 l로 대체하고 NVR의 현지 시간대로 재생 시간을 입력하세요. UTC 변환은 필요하지 않습니다.

예시:

라이브 뷰 URL 예시:

rtsp://192.168.0.240/live/1/1/avm

UTC+0를 사용하는 재생 URL 예시:

rtsp://192.168.0.240/replay/1/1/avm?starttime=20260720t154500z&endtime=20260720t161000z

NVR 현지 시간을 사용하는 재생 URL 예시:

rtsp://192.168.0.240/replay/1/1/avm?starttime=20260720t084500l&endtime=20260720t091000l
참고: 'l' 접미사를 사용하려면 펌웨어가 해당 기능을 지원해야 합니다.

 

Q3. RTSP 스트림에 영상은 포함되어 있지만 오디오는 없는 이유는 무엇입니까?

A3: SDP에 오디오 트랙이 포함되어 있으면 클라이언트가 해당 트랙에 대해 별도의 SETUP 요청을 보내야 합니다. 비디오 트랙만 설정되어 있으면 클라이언트가 오디오 없이 비디오만 수신합니다.

 

Q4: 클라이언트 애플리케이션은 통화 오디오 전송에 어떤 오디오 형식을 사용해야 합니까?
A4: 클라이언트 애플리케이션은 다음 설정을 사용하여 마이크 오디오를 인코딩해야 합니다.

• 코덱: G.711 μ-law
• 샘플 레이트: 16 kHz
• 오디오 채널: 모노
• 권장 패킷 크기: 1056바이트
• 권장 전송 간격: 66 ms

또는 클라이언트 애플리케이션이 40 ms마다 640바이트 오디오 블록을 전송할 수도 있습니다.

마이크가 다른 기본 오디오 형식을 사용하는 경우, 클라이언트 애플리케이션은 오디오를 G.711 μ-law로 인코딩하기 전에 16 kHz 모노로 변환해야 합니다.

 

각 기능 및 설정에 대한 자세한 내용을 확인하려면 지원 홈페이지를 방문하여 해당 제품의 설명서를 다운로드하거나 확인하시기 바랍니다.

이 문서에는 기계 번역이 적용되었으며, 정확한 내용을 확인하려면 원본 영문 문서를 참고하시기 바랍니다.