WebRTC는 긴급 지휘, 융합 통신, 산업 제어, 공공 안전 및 원격 운영을 위한 브라우저 기반 디스패치 콘솔을 구축하는 데 점점 더 많이 사용되고 있습니다. 실시간 오디오 및 비디오 기능을 통해 운영자가 기존 데스크톱 클라이언트를 설치할 필요 없이 하나의 웹 인터페이스에서 통화, 회의, 지휘 기능 및 멀티미디어 통신을 결합할 수 있습니다.

디스패치 플랫폼이 기존 감시 시스템, 휴대용 모니터링 카메라, 드론, 바디 장착형 장치 또는 타사 비디오 플랫폼의 비디오도 표시해야 할 때 과제가 나타납니다. 이러한 시스템은 다양한 코덱, 전송 프로토콜, 해상도, 프레임 속도 및 스트리밍 형식을 사용할 수 있습니다. 따라서 감시 플랫폼 내에서 올바르게 작동하는 비디오 스트림이 WebRTC 디스패치 콘솔 내에서 직접 재생되지 않을 수 있습니다. 실용적인 해결책은 전체 디스패치 애플리케이션을 재설계하는 것이 아니라 비디오 소스와 브라우저 기반 콘솔 사이에 미디어 변환 및 프로토콜 적응 계층을 배치하는 것입니다.

비디오 액세스가 어려워지는 이유

최신 디스패치 시스템은 음성으로 제한되는 경우가 거의 없습니다. 운영자는 통화에 응답하고, 현장 직원과 통신하고, CCTV 피드를 모니터링하고, 드론 카메라를 보고, 화상 회의에 참여하고, 동일한 워크스테이션에서 사건 현장을 검사해야 할 수 있습니다. 따라서 시스템은 원래 독립적으로 설계된 통신 리소스를 연결해야 합니다.

WebRTC는 대화형 브라우저 통신에 특히 적합합니다. 낮은 지연 시간의 미디어 전송을 제공하며 브라우저 기반 오디오, 비디오 및 화상 회의 애플리케이션에 널리 사용됩니다. WebRTC를 중심으로 구축된 디스패치 콘솔은 표준 웹 인터페이스를 통해 통신 제어 기능을 노출할 수 있으며 폐쇄형 데스크톱 클라이언트보다 다른 비즈니스 애플리케이션과 더 쉽게 통합할 수 있습니다.

그러나 감시 인프라는 다른 기술적 역사를 따릅니다. 카메라, 네트워크 비디오 레코더, 비디오 관리 시스템, 휴대용 감시 단말기, 드론 및 업계별 모니터링 플랫폼은 GB/T28181, RTSP, RTP, RTMP, HLS, SIP 또는 기타 인터페이스를 통해 스트림을 제공할 수 있습니다. 또한 브라우저 재생보다는 저장 효율성을 위해 주로 선택된 비디오 코덱을 사용할 수도 있습니다.

결과적인 문제는 상호 운용성 격차입니다. 비디오 소스를 사용할 수 있고, 디스패치 콘솔이 정상적으로 작동하며, 네트워크 연결이 작동하지만 브라우저는 여전히 원래 형식의 스트림을 디코딩하거나 소비할 수 없습니다.

관련 제품: Becke 디스패치 콘솔

H.265가 호환성 격차를 만드는 부분

감시 시스템이 H.265 비디오를 전달할 때 가장 일반적인 통합 문제 중 하나가 나타납니다. HEVC라고도 알려진 H.265는 이전 인코딩 방법과 비교하여 유사한 화질에서 대역폭 및 저장 요구 사항을 줄일 수 있기 때문에 모니터링 애플리케이션에 매력적입니다. 대규모 카메라 배포에서 이러한 효율성은 가치가 있을 수 있습니다.

문제는 H.265 재생 지원이 일반적인 WebRTC 및 브라우저 환경에서 일관되게 제공되지 않는다는 것입니다. 따라서 감시 플랫폼은 디스패치 위치에서 사용되는 WebRTC 애플리케이션이 직접 소비할 수 없는 완전히 유효한 H.265 스트림을 제공할 수 있습니다.

브라우저를 만족시키기 위해 모든 카메라를 교체하거나 전체 감시 플랫폼을 변경하는 것은 일반적으로 비실용적입니다. 가능한 모든 타사 코덱에 맞춰 디스패치 콘솔을 수정하는 것도 불필요한 개발 복잡성을 초래합니다. 보다 관리하기 쉬운 접근 방식은 미디어가 WebRTC에 도달하기 전에 정규화하는 것입니다.

이 아키텍처에서 비디오 트랜스코딩 서비스는 원본 H.265 스트림을 수신하여 대상 WebRTC 환경에서 지원되는 H.264 또는 다른 형식으로 변환합니다. 그런 다음 디스패치 콘솔은 원본 H.265 미디어를 직접 디코딩하려고 시도하는 대신 변환된 스트림을 소비합니다.

이러한 분리는 미디어 호환성을 코어 디스패치 애플리케이션 외부에 유지하기 때문에 중요합니다. 브라우저 인터페이스는 일반적인 WebRTC 워크플로를 계속 사용할 수 있으며 게이트웨이는 백그라운드에서 코덱 적응을 처리합니다.

실용적인 트랜스코딩 게이트웨이 아키텍처

비디오 트랜스코딩 게이트웨이는 감시 리소스와 WebRTC 디스패치 계층 간의 미디어 브리지 역할을 합니다. 그 역할은 단순한 코덱 변환보다 더 광범위합니다. 실제 융합 통신 프로젝트에서는 여러 비디오 플랫폼에서 스트림을 수신하고, 미디어 매개변수를 변환하고, 스트림을 재패키징하고, 디스패치 시스템이 사용할 수 있는 형식으로 게시해야 할 수 있습니다.

일반적인 워크플로는 5단계로 나눌 수 있습니다:

1. 디스패치 플랫폼이 특정 카메라, 드론, 휴대용 모니터링 장치 또는 타사 비디오 리소스를 요청합니다.

2. 게이트웨이는 사용 가능한 감시 또는 스트리밍 프로토콜을 통해 소스 스트림을 획득합니다.

3. 미디어 서비스는 수신 코덱, 해상도, 프레임 속도, 비트레이트 및 스트림 형식을 확인합니다.

4. 필요한 경우 비디오는 WebRTC 환경에 적합한 형식으로 트랜스코딩되거나 재패키징됩니다.

5. 변환된 미디어는 실시간 시청을 위해 브라우저 기반 디스패치 콘솔에 전달됩니다.

H.265 소스의 경우 가장 중요한 단계는 일반적으로 H.265에서 H.264로의 변환입니다. 다른 프로젝트에서는 코덱이 이미 호환될 수 있지만 해상도, 비트레이트, 프레임 속도 또는 프로토콜 패키징이 여전히 조정이 필요할 수 있습니다.

이 아키텍처는 시스템 간 결합도 줄입니다. 감시 플랫폼은 디스패치 인터페이스가 어떻게 구현되었는지 이해할 필요가 없으며 WebRTC 애플리케이션은 모든 카메라 공급업체 또는 스트리밍 형식에 대한 전용 로직을 포함할 필요가 없습니다. 각 측은 상호 운용성을 위해 특별히 설계된 미디어 적응 계층에 연결됩니다.

비디오 시스템 간 프로토콜 연동

코덱 변환은 통합 문제의 일부만 해결합니다. 다른 시스템은 다른 시그널링 및 전송 프로토콜을 사용할 수도 있습니다. 따라서 완전한 비디오 게이트웨이는 미디어 처리뿐만 아니라 프로토콜 적응도 수행해야 합니다.

지휘 및 감시 환경에서 접하는 일반적인 인터페이스에는 GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP 및 WebRTC가 포함됩니다. 그 목적은 동일하지 않습니다. 일부는 감시 장치 액세스 및 제어에 사용되고, 일부는 실시간 미디어 전송에, 일부는 스트리밍 배포에, 그리고 다른 일부는 세션 시그널링 또는 브라우저 통신에 사용됩니다.

이러한 시스템 사이에 위치한 게이트웨이는 한 형식의 스트림을 수신하여 디스패치 플랫폼에서 요구하는 다른 인터페이스를 통해 제공할 수 있습니다. 예를 들어, 감시 카메라는 RTSP를 통해 액세스될 수 있는 반면 기존 모니터링 플랫폼은 GB/T28181을 통해 리소스를 노출할 수 있습니다. 게이트웨이가 이를 WebRTC 호환 전달 경로로 변환하면 디스패치 애플리케이션이 이러한 프로토콜을 직접 소비할 필요가 없습니다.

통합 스트리밍 서비스는 스트림 풀링 및 게시도 관리할 수 있습니다. 운영자가 카메라를 선택하면 시스템이 소스 플랫폼에서 풀 작업을 시작하고, 미디어를 처리하고, 결과 스트림을 디스패치 콘솔에 게시할 수 있습니다. 이렇게 하면 리소스가 보기되지 않을 때 불필요한 스트림을 유지하지 않아도 됩니다.

동일한 아키텍처는 CCTV 이외에도 유용합니다. 휴대용 감시 카메라, 드론 비디오, 비디오폰, 화상 회의 시스템 및 기타 실시간 미디어 리소스는 모두 다양한 프로토콜을 통해 통합 지휘 환경에 들어갈 수 있습니다. 프로토콜 인식 게이트웨이는 이러한 차이점을 처리하기 위한 공통 지점을 제공합니다.

실제 프로젝트를 위한 배포 워크플로

성공적인 통합 프로젝트는 WebRTC 인터페이스 단독이 아닌 기존 비디오 환경에서 시작해야 합니다. 첫 번째 작업은 표시해야 할 리소스와 해당 리소스가 현재 어떻게 노출되는지 식별하는 것입니다.

기존 비디오 소스 매핑

프로젝트 팀은 감시 플랫폼, 고정 카메라, 휴대용 카메라, 드론, 화상 회의 시스템, 비디오폰 및 기타 관련 소스를 나열해야 합니다. 각 리소스에 대해 사용 가능한 프로토콜, 코덱, 해상도, 프레임 속도, 인증 방법 및 네트워크 위치를 문서화해야 합니다.

시그널링을 미디어와 분리

일부 시스템에서는 시그널링이 액세스할 장치를 결정하는 반면 미디어는 다른 프로토콜을 통해 전송됩니다. 시그널링과 미디어를 별도의 통합 계층으로 처리하면 문제 해결이 더 쉬워집니다. 카메라는 등록 및 제어에 성공할 수 있지만 코덱 또는 전송 비호환성으로 인해 비디오 스트림은 여전히 실패할 수 있습니다.

필요한 경우에만 정규화

트랜스코딩은 컴퓨팅 리소스를 소비하고 추가 처리 지연을 발생시킬 수 있습니다. 따라서 실용적인 게이트웨이는 불필요한 변환을 피해야 합니다. 소스가 이미 WebRTC 환경에서 허용되는 코덱 및 미디어 프로파일을 사용하는 경우 재패키징 또는 전달로 충분할 수 있습니다. 완전한 트랜스코딩은 코덱 또는 미디어 매개변수가 실제로 호환되지 않을 때 사용해야 합니다.

온디맨드 스트림 풀링 사용

대규모 모니터링 시스템에는 수백 또는 수천 개의 카메라가 포함될 수 있지만 디스패치 운영자는 일반적으로 한 번에 작은 하위 집합만 봅니다. 운영자가 요청할 때만 스트림을 시작하면 대역폭, 미디어 처리 부하 및 불필요한 서버 리소스 소비를 줄일 수 있습니다.

운영자 워크플로를 간단하게 유지

미디어 변환은 디스패치 운영자에게 보이지 않아야 합니다. 이상적으로 운영자는 연락처 목록, GIS 지도, 사건 페이지 또는 비디오 리소스 패널에서 카메라를 선택하고 이미지가 직접 열립니다. 프로토콜 선택, 코덱 변환, 스트림 설정 및 복구는 백엔드에서 처리해야 합니다.

신뢰성과 미디어 품질이 중요합니다

스트림을 보이게 만드는 것은 첫 번째 단계일 뿐입니다. 긴급 지휘 및 산업용 디스패치 애플리케이션은 변화하는 네트워크 조건에서도 안정적인 비디오가 필요합니다. 따라서 사용 가능한 미디어 계층은 코덱만이 아닌 더 많은 것을 적응할 수 있어야 합니다.

고해상도 카메라를 더 작은 디스패치 창에 표시하거나 제한된 네트워크 연결을 통해 전달해야 할 때 해상도 조정이 유용할 수 있습니다. 프레임 속도 변환은 매우 높은 프레임 속도가 필요하지 않은 모니터링 시나리오에서 처리 및 대역폭 요구 사항을 줄일 수 있습니다. 비트레이트 제어는 사용 가능한 네트워크 용량이 변경될 때 연속성을 유지하는 데 도움이 될 수 있습니다.

이러한 기능은 두 비디오 시스템이 명목상 모두 H.264를 지원하더라도 다른 미디어 프로파일을 사용할 때 유용합니다. 해상도, 프로파일, 프레임 속도, 비트레이트 또는 패킷화의 차이점이 여전히 원활한 상호 운용성을 방해할 수 있습니다.

따라서 미디어 게이트웨이는 비디오폰, 화상 회의 플랫폼, CCTV 시스템, 드론 피드 및 브라우저 기반 디스패치 애플리케이션 간의 정규화 지점 역할을 할 수 있습니다. 모든 하위 시스템이 다른 모든 하위 시스템과 직접 일치해야 하는 대신 각 시스템은 게이트웨이에 대한 안정적인 연결만 있으면 됩니다.

네트워크 설계는 지연, 패킷 손실, 스트림 복구, 인증, 액세스 제어 및 동시 시청 요구 사항도 고려해야 합니다. 지휘 센터는 여러 운영자가 동일한 소스를 볼 필요가 있을 수 있으며, 사건이 갑자기 여러 비디오 리소스를 동시에 열어야 할 수도 있습니다. 용량 계획은 단일 테스트 스트림이 아닌 현실적인 최대 워크플로를 반영해야 합니다.

최종 노트

WebRTC는 브라우저 기반 디스패치 콘솔에 효과적인 기반을 제공하지만 실제 지휘 시스템은 기본 WebRTC 엔드포인트보다 훨씬 더 많이 연결해야 합니다. CCTV 플랫폼, 드론, 휴대용 모니터링 장비, 화상 회의 시스템 및 레거시 비디오 리소스는 종종 다른 코덱과 스트리밍 프로토콜을 도입합니다.

H.265는 특히 일반적인 비호환성의 원인입니다. 디스패치 콘솔을 재설계하거나 기존 감시 장비를 교체하는 대신 미디어 트랜스코딩 게이트웨이가 원본 스트림을 수신하고, 필요에 따라 H.265를 H.264로 변환하고, 해상도, 프레임 속도 및 비트레이트를 적응시키고, WebRTC 호환 경로를 통해 결과를 전달할 수 있습니다.

동일한 게이트웨이가 GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP 및 WebRTC와 같은 인터페이스도 지원할 때 더 넓은 융합 통신 아키텍처를 위한 실용적인 상호 운용성 계층이 됩니다. 결과적으로 운영자는 단일 인터페이스를 통해 이기종 비디오 리소스에 액세스할 수 있으며 코덱 변환 및 프로토콜 적응은 백그라운드에서 이루어지는 디스패치 워크플로가 구현됩니다.

FAQ

모든 감시 스트림이 운영자가 요청하기 전에 영구적으로 변환되어야 합니까?

일반적으로 그렇지 않습니다. 대규모 배포에서는 온디맨드 처리가 더 효율적인 경우가 많습니다. 미디어 서비스는 운영자가 해당 리소스를 열 때 스트림 풀링 및 적응을 시작하고 스트림이 더 이상 필요하지 않을 때 처리 용량을 해제할 수 있습니다.

동일한 카메라 스트림을 여러 디스패치 운영자에게 전달할 수 있습니까?

예, 스트리밍 아키텍처가 일대다 배포용으로 설계된 경우 가능합니다. 미디어 서비스는 소스를 한 번 수신하고 처리된 출력을 여러 권한 있는 시청자에게 배포할 수 있으므로 각 운영자에 대해 별도의 업스트림 연결을 열 필요가 없습니다.

비디오 액세스 권한은 어떻게 관리해야 합니까?

카메라 액세스는 일반적으로 디스패치 플랫폼의 사용자 및 역할 권한을 따라야 합니다. 운영자는 특정 지역, 시설, 카메라 그룹 또는 사건 관련 리소스만 볼 수 있도록 허용될 수 있으며 관리자는 더 광범위한 제어 및 구성 권한을 받을 수 있습니다.

원본 비디오 소스를 일시적으로 사용할 수 없게 되면 어떻게 됩니까?

디스패치 애플리케이션은 무기한 정지된 이미지를 표시하는 대신 명확한 오프라인 또는 재연결 중 상태를 수신해야 합니다. 백엔드는 정의된 재시도 정책에 따라 재연결을 시도하고 업스트림 소스를 다시 사용할 수 있게 된 후 스트림을 자동으로 복원할 수 있습니다.