꿈꾸는삶 의 기억 도서관

https://www.photopea.com/

해당Site 에서 진행

*주의 : 사진이 1장밖에 안불러와짐

-. Web RTC란, Web Real-Time Communication의 약자이며 JS API로 위와 같은 기능들을 제공해주는 오픈소스일뿐이고 우리가 직접 구현해야 한다.

-. Web RTC를 간단히 번역해보자면 웹 실시간 통신이라는 것을 쉽게 알 수 있는데 이 말에서 의미하는 바와 같이 웹, 앱에서 비디오, 마이크 등을 이용해서 실시간 통신을 제공한다는 것이다.

-. Web RTC에서는 우리가 실시간 통신을 하면서 나오는 데이터(비디오에서 나오는 영상 스트림, 마이크에서 나오는 음성 스트림)들을 P2P방식으로 Peer 간의 전송이 되도록 지원하고 있다.

Web RTC에서는 다양한 개념들을 다룬다.

이들을 간단히 언급하자면 시그널링(Signaling), ICE(Interactive Connectivity Establishment), STUN(Session Traversal Utilities for NAT), TURN(Traversal Using Relay NAT) 등이 존재한다

[ 시그널링 ] 

상대방과 P2P연결을 통해 데이터를 상호교환 한다.

하지만 연결을 하고 교환하기 전에 고려해야할 부분은 몇몇 존재 한다.

먼저, 상대방과 연결을 하기 위해서는 상대방의 네트워크 정보가 필요할 것이며 상대방이 보내는 미디어 데이터 정보(해상도, 형식, 코덱 등)가 무엇인지에 대해 알고 전송과 수신 여부에 대해서 알아야할 필요가 있을 것이다.

*******

세션 제어 정보 - 통신의 초기화, 종료, 에러

네트워크 정보 - IP, PORT

미디어 정보 - SDP 형식으로 코덱, 해상도, 송수신 여부를 응답 모델(Offer <-> Answer)을 통해 협상

(SDP(Session Description Protocol)이란, 위에서 언급한 두 개의 Peer 간에 다양한 멀티미디어 컨텐츠의 초기 인수를 설명하기 위한 프로토콜이다.)

*******

그래서 우리는 시그널링(Signaling)을 진행한다.

우리는 시그널링 서버를 구축하고 시그널링을 통해 Peer간 위에서 언급한 정보들을 교환한다.

Web RTC에서는 이러한 시그널링에 대해서 어떠한 제한을 두고 있지 않으며 우리가 어떠한 방식으로도 시그널링을 진행할 수 있다.

[ NAT ]

우리는 글로벌 인터넷 세계에서 살아가고 있기에 수많은 IP들이 각각의 컴퓨터들에 할당되어 누구와도 소통할 수 있다.

하지만 우리가 사용하는 IPv4 체계는 전 세계의 사람들을 충당하기에는 너무 부족하다. (2^32 => 4,294,967,296)

IPv6가 나온다면 지금보다 나아질 것이지만 그에 대한 대안으로 단순 사설 IP를 사용하기보다는 공인 IP를 사용하기로 하였다. 

이것을 해결해주는 것이 바로 NAT(Network Address Traversal)

집에서 각각의 컴퓨터들을 사용하고 핸드폰을 위한 와이파이도 사용하고 다른 스마트 제품들을 위한 인터넷도 공유기를 통해 받는다.

즉, 하나의 공인 IP를 여러 개의 사설 IP로 쪼개 안에서 사용하고 있으면서 외부와 통신할 때는 앞에서 언급한 공인 IP로 통신을 진행하게 된다는 것이다.

하지만 이렇게 되면 외부 IP를 사용해 외부로 나갔다가 다시 결과값이 반환되어 들어올 때 해당 공인 IP를 목적지로 해서 들어올 텐데 어떤 사설 IP에서 요청했는지 어떻게 알지? 라는 의문을 품을 수도 있는데 NAT는 테이블을 통해 내부 네트워크에 존재하는 사설 IP와 포트 번호를 외부 네트워크와 통신할 때 사용하는 공인 IP와 포트와 매핑하여 저장해놓음으로써 이를 가능하게 해준다.

[ STUN, 홀 펀칭 ]

그렇다면 A라는 사람과 B라는 사람이 WebRTC를 이용할 때 A가 B의 공인 IP로 보내면 NAT에서 알아서 B의 사설 IP로 보내주겠지?라고 생각하면 오산이다.

우리에게 아직 문제점이 존재한다.

NAT의 경우, B가 요청을 보내면서 NAT를 거치며 해당 사설 IP 정보와 공인 IP 정보가 매핑되어 테이블에 저장되게 되면 위의 경우는 성립한다.

하지만, 어느 것도 없던 경우 A와 B NAT 테이블에는 어떠한 것도 존재하지 않으므로 각각에 도착할 수 없을 것이다.

​

이를 위해 존재하는 것이 바로 홀 펀칭(Hole Punching)이다.

여기서는 추가적인 서버 S가 존재한다고 하자.

A와 B는 각각 서버 S에 접속하게 되면 NAT를 통해 공인 IP로 변환(Traversal)되어 가므로 S에서는 해당 공인 IP를 알 수 있으며 A와 B가 사설 IP도 알려준다면 사설 IP 정보까지 캐치할 수 있게 된다.

S가 이제 A, B에게 각각의 정보에 대해서 알려준다. 여기까지 된다면, 서버 S의 존재 가치는 여기서 끝이다.

A와 B가 받은 정보를 토대로 각자 진행하면 될 것이다.

[ TURN ]

• Full cone NAT
  • A 서버로 요청을 보내기 위해 한번 [사설 IP/PORT : 공인 IP/PORT] 쌍이 NAT 테이블에 저장되면 항상 그 공인 IP/PORT로의 요청은 해당 사설 IP/PORT로 간다.
  • B 서버와 통신을 한적이 없는 데도 불구하고 NAT 매핑 정보만 안다면 해당 사설 IP/PORT로 정보 전송이 가능하다.
• Address Restrict Cone NAT
  • Full Cone NAT에서와 달리 기존에 통신하던 서버가 아니라면 불가하다. (위에서 A 서버만 가능, B 불가)
• Port Restricted Cone NAT
  • Address Restrict Cone NAT에서 포트도 본다.
• Symmetric NAT
  • 위 세 개와 달리 다른 서버와 통신을 하게 된다면 매핑 정보가 아예 바뀌어 버린다.

여기서 문제가 되는 부분은 Symmetric NAT이다.

우리가 기껏 STUN Server를 통해서 사설 IP/PORT와 공인 IP/PORT를 알아왔더니 A, B 각자와 통신을 할때에는 매핑 정보가 아예 바뀌어버려 사용할수도 없게 된다.

이러한 부분을 해결하기 위해 등장한 것이 바로 TURN(Traversal Using Relay NAT)이다.

이 부분에 대한 설명은 간단하다.

그냥 단순히 TURN Server과 A, B가 각각 연결을 맺고 이 서버에서 모든 교환 과정을 중계해준다.

[ 결론 ]

이와 같이 우리는 A라는 사용자와 B라는 사용자가 PeerConnection을 맺기 위해 정보를 교환하는 과정에 대해서 알아보았다.

위에서 설명한 과정들 속에서 상대방의 네트워크 정보를 알게 되는데 각각을 사용해서 얻을 수 있는 정보는 다음과 같다.

• 자신의 사설 IP/PORT
• 자신의 공인 IP/PORT (By STUN, TURN)
• TURN 서버의 IP/PORT (By TURN)

이렇게 상대방과 연결하기 위한 최적의 경로를 알기 위한 과정을 제공하는 프레임워크를 바로 ICE(Interactive Connectivity Establishment)라고 한다.

1. 상대방의 네트워크 정보와 미디어 정보를 알기 위해 시그널링 과정을 거친다.
2. 네트워크 정보에 대해서 문제점이 발생하는 경우가 빈번히 있기에 이러한 부분을 해결하기 위해 ICE 프레임워크로 최적의 경로를 찾게 된다.
3. 이에 대한 방법으로는 STUN, TURN 서버를 이용하는 방법이 존재한다

Web RTC는 Peer 간에 Peer-To-Peer로 이루어진다고 설명을 했는데 이 방식은 사람의 수가 늘어날 수록 부담이 매우 심해지게 된다.

​

출처 : https://gilssang97.tistory.com/79

-. HLS(HTTP 라이브 스트리밍)은 가장 널리 사용되는 비디오스트리밍  프로토콜입니다.

-. HLS는 비디오 파일을 다운로드할 수 있는 HTTP 파일 조각으로 나누고 HTTP 프로토콜을 이용하여 전송합니다. 

-.클라이언트 장치는 이러한 HTTP 파일을 로드한 후 비디오로 재생합니다.

[ 장점 ]

1. 호환성

• HLS는 스마트폰, 태블릿, 노트북 등 다양한 장치에서 스트리밍된 콘텐츠의 소비를 지원합니다.

2. 부드러운 재생

• ABR 기능은 HLS를 비디오 스트리밍, 특히 중단할 수 없는 방송 중에 품질을 저하시키더라도 재생되게끔 해줍니다.

3. 비용 효율성

• HLS는 HTTP를 기반으로 하며 어떤 장치에서도 확장할 필요 없이 콘텐츠 전송 네트워크를 통해 전달할 수 있으므로 비용 효율적입니다.

4. 보안

• HLS는 또한 Flash와 같은 솔루션에 비해 더 안전한 프로토콜입니다.

5. 확장성

• HLS는 스트리밍을 확장하여 품질 저하 없이 동시에 전 세계 수백만 명의 시청자를 지원할 수 있습니다.

[ 단점 ]

1. 높은 대기 시간

• 다른 스트리밍 프로토콜에 비해 HLS는 대기 시간이 더 깁니다
• 최대 30초 이상의 지연이 생길 수 있음

2. 느린 인터넷 속도

• HLS 스트리밍은 지연 시간이 상대적으로 높기 때문에 비디오 게임이나 스포츠 방송과 같이 빠른 라이브 스트리밍이 필요한 사용 사례에는 적합하지 않을 수 있습니다.

[ 첫번째 HLS 재생 목록의 청크 수 설정 ]

일반적으로 스트리밍 서버는 HLS를 사용할 때 재생 전에 충분한 청크를 저장해야 합니다.

이것은 플레이어에 따라 다릅니다.

재생은 일반적으로 플레이어가 3개의 청크가 포함된 첫 번째 HLS 매니페스트를 가져온 후에 시작됩니다.

그러나 일부 플레이어는 3개 미만의 청크 수를 지원합니다.

이러한 상황에서는 재생이 시작되기 전에 첫 번째 매니페스트에서 수신 및 패키징되는 청크 수를 결정하여 지연 시간을 줄이기 위해 이 숫자를 조정할 수 있습니다.

[ 키 프레임 간격 줄이기 ]

GOP(Group of Pictures)라고도 잘 알려진 키프레임 간격은 청크 크기에 영향을 미치는 핵심 요소입니다.

HLS 청크는 키프레임 경계에서 생성되므로 설정한 GOP가 클수록 청크가 커져 라이브 브로드캐스트의 지연 시간이 결정될 수 있습니다.

OBS 및 Wirecast와 같은 인코더를 통해 스트림을 푸시할 때 GOP를 2~3초로 설정하는 것이 좋습니다.

[ 결론 ] 

HLS의 장점 중 하나는 모든 인터넷 연결 장치가 HTTP를 지원하기 때문에 전용 서버가 필요한 스트리밍 프로토콜보다 간단하게 실행할 수 있다는 것입니다.

또 다른 장점은 HLS 스트리밍은 재생에 지장을 주지 않고 네트워크 상태에 따라 비디오 품질을 높이거나 낮출 수 있다는 것입니다. 이 때문에 사용자가 비디오를 보는 중에 품질이 나빠지거나 좋아질 수 있습니다. 이 기능은 "적응 비트 전송률 비디오 전송" 또는 "적응 비트 전송률 스트리밍" 이라 알려져 있으며 이 기능이 없으면 네트워크가 느려진 경우 비디오 재생이 완전히 멈출 수 있습니다.

HLS는 Apple이 자사 제품에 사용하기 위해 개발했지만, 현재 다양한 장치에서 사용되고 있습니다.

Flatbuffers 란?

두괄식 으로, 플랫버퍼는 메세지 송/수신에 사용되는 플랫폼 종속성 없이 사용가능한 "직/역직렬화 라이브러리" 이다.

Flatbuffers 사용 이유

• 데이터 송/수신시 파킹/언패킹 불 필요
• 메모리 효율성↑  /  빠른 속도
• 사용하는 데이터타입에 대한 유연성
• 적은 양의 코드로 작성 가능   ( * 코드가 간단하진 않다..... )
• 사용하기 편리함
• 크로스 플랫폼, 종속성 없이 사용 가능

기존에 구글이 만들어놓은 직렬화 라이브러리 Protocol Buffer 가 존재 하였음

<<순서>>

1. IDL 작성
   인터페이스를 정의하는 IDL을 먼저 작성해야 함.
   이는, 크로스 플랫폼을 지원하며 어떤 방식으로 컴파일 할 것인지만 결정하면
   해당 플랫폼에 맞게 라이브러리가 생성됨.
   
   ex) Object를 송/수신 하고싶다면
        아래와같이작성 ( 예시 코드는 C/C++ 로 작성 되어짐. )
   

   table Monster {
     pos:Vec3;
     mana:short = 150;
     hp:short = 100;
     name:string;
     friendly:bool = false (deprecated, priority: 1);
     inventory:[ubyte];
     color:Color = Blue;
     test:Any;
   }​

    (이런식으로 정의를 하고 컴파일을 하면 C++, JAVA, C# ....  에 맞게 알아서 Class 가 생성되어짐.
   그 클래스를 Import 해서 쓰기만 하면 byte[] <---> Monster 간의 변환이 알아서 적절하게 완료가 되어짐.)
   
   
2. 컴파일
   FlatBuffer 의 버전에 따라 동작이 다름으로
   IDL 을 작성해서 나온 컴파일 결과와, 종속성으로 넣어주는 라이브러리 파일의 버전이 같아야 한다.
   
   Github에 해당 라이브러리가 등록 되어있고 Release 를 사용하면 됨.
   
   컴파일을 하려면 flatc.exe 가 필요함.
   flatc_Windows_exe 를 받아서 압축을 풀면 flatc.exe 가 나옴.
   
   컴파일 방법은 
   커맨드창에서 flatc.exe 를 실행
   

   flatc [ GENERATOR OPTIONS ] [ -o PATH ] [ -I PATH ] [ -S ] FILES...
         [ -- FILES...]

   해당 인자를 넣어서 실행시키면 됨.
   
   ex1) IDL 파일을 JAVA로 만들때
           *.fbs 파일은 그냥 임의로 작성 되어짐. idl 파일을 어떤 형식으로 저장해도 무관(txt 도 가능)
           
           flatc --java -o ./src/main/java/ ./protocol_idl/javaGompangProtocol.fbs
   
   ex2) IDL 파일을 C#으로 만들때
           flayc --csharp -o ./src/main/java/ ./protocol_idl/csGompangProtocol.fbs
   
   컴파일이 성공했을경우 해당폴더에 플랫폼 별 클래스가 생성되어짐.
   
   
   
3. FlatBuffer의 라이브러리 파일 추가
   * 컴파일된 플랫버퍼가 만들어준 Class 도 같이 추가
   
   
4.  사용
   사용 "순서"에 따라 오류가 날수 있음.
   
   [직렬화 순서]  - EchoMsg 기준
   - FlatBufferBuilder 생성
   - String이 존재한다면 CreateString 으로 문자열을 생성해두고 offset 을 저장(중요)
   - EchoMsg.StartEchoMsg();
   - EchoMsg.AddMsg();
   - EchoMsg.EndEchoMsg(fbb);
   - fbb.Finish();
   - fbb.SizedByteArray()   
      => 최종 byte[] 이다. 반드시 SizedByteArray() 를 사용해야하며 fbb에 담긴 메모리를 직접 접근해서 쓰지 않기.
   
   

   FlatBufferBuilder fbb = new FlatBufferBuilder(1);
   var offset = fbb.CreateString(msg);
   EchoMsg.StartEchoMsg(fbb);
   EchoMsg.AddProtocolId(fbb, (short)1);
   EchoMsg.AddMsg(fbb, offset);
   var endOffset = EchoMsg.EndEchoMsg(fbb);
   fbb.Finish(endOffset.Value);
   byte[] packet = fbb.SizedByteArray();​

   위 소스는 C# 기준.
   
   [역직렬화]
   - byte[] data = socket.read();
   - EchoMsg echoMsg = EchoMsg.getRootAsEchoMsg(data);
   - echoMsg.Msg();  // String 형태의 Msg를 받을수 있음.
   
   byte[]배열을 getRootAsEchoMsg()에 인자로 넘겨주게 되면,
   해당 byte[]에서 원하는 데이터들을 메소드로 접근 가능하다.
   이와 같이 데이터 송/수신 시 객체를 만들어서 사용하면 성능좋은 동작을 보장할 수 있다고 한다.

Mutex 란?

동기화 객체로, 멀티스레드 환경에서 여러 스레드가 동일한 리소스에 동시에 접근하지 못하도록 막아주는 도구입니다. 이를 통해 여러 스레드가 동일한 자원을 동시에 사용하는 경우 발생할 수 있는 데이터 충돌이나 비정상 동작을 방지할 수 있습니다.

주요 특징

1. 상호 배제(Mutual Exclusion): 한 번에 하나의 스레드만 리소스에 접근할 수 있도록 보장합니다.
2. 스레드 안전(Thread Safety): 뮤텍스를 사용하면 다중 스레드 환경에서 데이터 일관성과 무결성을 유지할 수 있습니다.
3. 프로세스 간 동기화: 뮤텍스는 단순히 하나의 프로세스 내에서만 사용되는 것이 아니라, 여러 프로세스 간에도 사용될 수 있습니다. 이는 프로세스 간 자원 접근을 동기화하는 데도 유용합니다.

뮤텍스의 동작 원리

뮤텍스는 **잠금(Lock)과 해제(Unlock)**의 개념을 기반으로 동작합니다. 한 스레드가 뮤텍스를 획득하면(잠금), 다른 스레드는 해당 리소스에 접근하지 못하고 대기하게 됩니다. 뮤텍스를 획득한 스레드가 작업을 끝낸 후 뮤텍스를 해제하면, 대기 중이던 다른 스레드가 뮤텍스를 획득하고 리소스에 접근할 수 있게 됩니다.

뮤텍스와 세마포어 차이

• 뮤텍스(Mutex): 한 번에 오직 하나의 스레드만 자원에 접근할 수 있습니다.
• 세마포어(Semaphore): 카운터를 기반으로 동작하여, 여러 스레드가 동시에 자원에 접근할 수 있습니다(최대 N개의 스레드).

요약

• **뮤텍스(Mutex)**는 상호 배제를 보장하는 동기화 도구로, 멀티스레드 환경에서 한 스레드가 자원을 사용하고 있을 때 다른 스레드가 접근하지 못하도록 제어합니다.
• 이를 통해 동시성 문제를 해결하고, 데이터의 일관성과 무결성을 유지할 수 있습니다.

이 코드는 주로 다중 인스턴스 방지를 위해 사용됩니다.

• Mutex를 이용해 특정 리소스나 실행 상태를 하나의 인스턴스만 점유할 수 있도록 제한합니다.
• 이름이 _mutexName인 Mutex가 이미 존재한다면, 이는 다른 인스턴스가 이미 실행 중이라는 뜻이므로 현재 인스턴스를 종료하게 됩니다.

new Mutex(true, _mutexName, out bool createNew):

• Mutex 객체를 생성하고, 첫 번째 매개변수로 true를 전달함으로써 즉시 Mutex를 소유하려고 시도합니다.
• _mutexName은 이 Mutex의 고유 이름을 지정하는 문자열입니다. 이 이름을 통해 시스템 전체에서 동일한 Mutex를 참조할 수 있습니다.
• createNew는 Mutex가 처음 생성되었는지 여부를 반환합니다.
  • true이면 이 Mutex가 현재 애플리케이션에서 처음 생성된 것이고,
  • false이면 이미 같은 이름의 Mutex가 존재하는 것입니다(즉, 이미 다른 인스턴스가 실행 중).

if (!createNew):

• 만약 createNew가 false라면, 이미 동일한 이름의 Mutex가 존재하는 것이므로 다른 인스턴스가 실행 중이라는 의미입니다.
• 이때, 애플리케이션을 종료하는 Shutdown()을 호출합니다.

Telerik 社 의 AutomationManager 사용

사용 이유 : Microsoft UI Automation (UIA) 프레임 워크는 Win32, WinForms 및 WPF 애플리케이션에서 대부분의

                  사용자 인터페이스 요소에 대한 프로그래밍 방식 액세스를 제공합니다.

                  주로 자동화된 UI 테스트 및 접근성 지원 목적으로 사용됩니다.

                  UIA 프레임워크는 모든 UI 구성 요소를 AutomationElement 개체로 노출합니다.

                  이러한 개체는 Windows 데스크톱이 루트 요소인 트리 구조를 구성합니다.

                  각 AutomationElement는 클라이언트가 상호 작용하는 방식을 정의하는 일련의 컨트롤 패턴을 노출합니다.

                  예를 들어, 요소가 ValuePattern을 정의하는 경우 클라이언트는 이 패턴을 가져와 ValuePattern 개체에

                  저장하고 해당 개체의 getValue 및 setValue 메서드를 사용하여 UI 요소의 값(예: 텍스트 상자의 텍스트)에

                  액세스할 수 있습니다.

비활성화 하게되면 생기는 문제 : 기본적으로 컨트롤에는 UI 자동화 피어가 켜져 있고

                                                     해당 코드는 터치 디바이스에서 여러 번 호출됩니다.

                                                     비활성화하면  Code UI를 사용하여  테스트를 수행할 수 없습니다.

                                                     또한 MS 내레이터 도구나 자동화 피어를 사용하는 다른 최종 도구를 사용할 수

                                                     없습니다.

[사용 예시]

참고 Site : https://www.telerik.com/forums/automationmode

AppDomain.CurrentDomain.UnhandledException

이벤트 생성

Application.ThreadExeption 처리와 마찬가지로

Program.cs 에 구현

* WPF 경우 App.xaml.cs 에서 구현

[ 지능형 선별 관제 ( IVS-DeepEye ) ]   

( IVS 는 아이브스 라는 회사.. 따라서 해당 포스팅? 은 해당 회사의 솔루션 내용 일뿐 느낌만 갖고 이해 하는것을 목표로 삼는다. )

-. 관제 필터를 적용하여 사용자 관심 영상만 관제

-. 시간/사람/차량/색상 필터 기능 제공

-. 이벤트 썸네일 지원

-. 라이브 영상 관제 시 필터 적용

-. 검색 시 필터 적용후 검색

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ 참고 영상 ]

https://www.youtube.com/watch?v=UQygh-U5NRA&t=7s

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ 시스템 구성도 ]

( 해당 회사 제품에 대한 구성도 임으로 이런식으로 진행되어진다 정도의 이해만 갖도록 할것 )

[ 불렛  ( Bullet ) ]

-. 포탄 케이스를 연상시키는 원통 모양에서 나온 이름.

-. 고정형 카메라

-. 범위가 길고 넓어서 외부 모니터링에 최적화 되어 있음.

-. 주변을 따라 실회에 설치될때가 많으며, 침입 탐지를 위해 동영상 분석 솔루션과 자주 결합 되어짐.

-. 일반적 으로 태양광의 섬광과 가혹한 날씨로부터 보호하기 위해 렌즈 너머로 확장되는 썬 실드 가 포함.

-. 쉽게 눈에 띄므로 잠재적 범죄자들이 범죄를 저지르는 것을 막는 시각적인 억제장치로도 작용 되어짐.

-. 장착 브래킷 또는 렌즈를 조정하여 쉽게 위치를 변경 할수 있음.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ PTZ ( Pan Tilt Zoom) ]

-. 지향성 또는 무지향성으로 이동할수 있는 모터식 플랫폼이 있음.

-. 원격 또는 사전 설정된 투어를 통해 제어 가능.

-. 크기가 크고 해상도가 높은 경우가 많음.

-. 왼쪽 또는 오른쪽으로 패닝 하거나, 위 아래로 틸트하거나, 확대 및 축소 를 할수 있음.

-. 전체 현장을 감시할 수 있도록 시야가 넓은 외벽이나 기둥에 실외 장착 되는 경우가 많음.

-. 주변에 있는 고정형 카메라에서 넘어온 목표물을 받고 추적하여 위협 평가 및 용의자 식별을 함.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ 돔 ( DOM ) ]

-. 주변 환경과 조화를 이루는 분산형 디자인.

-. 기물 파손이나 변조로부터 카메라를 보호하기위해 금속 베이스와 폴리카보네이트 플라스틱이 덮쳐져 있음.

-. 일반적으로 사무실 로비나 소매점 통로와 같은 실내 공간의 천장에 장착되어 있음.

-. 넓은 면적의 감시기능 제공.

-. 돔 카메라는 돔 재질에 그을리거나 착색된 색조를 사용하여

   내부 렌즈를 보기 어렵게하여 렌즈가 가리키고 있는 곳을 최대한 알아볼수 없게 만들수 있음.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* 어떤 영역을 감시해야 하는지, 고객이 인식 및 탐지해야하는 범위가 어느정도인지 등에 따라 적합한 카메라를 선택

[ RTSP ( Real Time Streaming Protocol ) ]

-. 미디어 스트림을 제어하는 데에 사용되는 프로토콜.

-. URI에 정의된 프로토콜 사용.

-. ONVIF 미디어 서비스 Specification 에 정의된 GetStreamURI 명령어에 URI가 반환 되어 짐.

-. RTSP 같은경우 TCP/UDP 를 전송 프로토콜로 사용

-. RTP / RTCP 와 달리 예약된 포트번호가 있음. ( 기본 TCP 포트는 554 )

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ 스트리밍 재생 관련 명령어 ] 

-. Setup : 연결설정

-. Play : 재생

-. Forward, Rewind, Pause : 일시 멈춤

-. Stop : 완전 정지

-. Resume : 다시 시작

-. Record, Teardown : 연결해제