H.265 CCTV가 브라우저에서 안 나올 때: H.264·WebRTC·HLS 해결법

H.265 CCTV 영상이 NVR이나 VLC에서는 나오지만 브라우저에서 안 나오는 이유는 RTSP 연결보다 브라우저의 코덱·컨테이너·전달 방식 지원 차이일 가능성이 큽니다. H.265를 지원한다는 문구만 확인하지 말고 카메라부터 미디어 서버, 운영체제와 브라우저까지 전체 경로를 봐야 합니다.

가장 실용적인 해결책은 녹화용 H.265 메인 스트림을 유지하면서 웹 관제에는 H.264 서브 스트림을 사용하거나, 서버에서 브라우저가 받을 수 있는 형식으로 변환하는 것입니다.

1. VLC와 NVR에서는 되는데 브라우저에서는 왜 안 될까?

VLC와 NVR은 자체 디코더나 하드웨어 디코딩 기능을 사용해 H.265를 처리할 수 있습니다. 반면 브라우저는 운영체제의 디코더, 하드웨어, 브라우저 버전, 미디어 컨테이너와 전송 방식의 영향을 함께 받습니다.

MDN 코덱 선택 안내는 코덱 지원 여부와 효율뿐 아니라 대상 사용자 환경을 함께 고려해야 한다고 설명합니다. 같은 Chrome이라도 운영체제와 장치가 다르면 결과가 달라질 수 있으므로 개발 PC 한 대의 성공을 전체 사용자 지원으로 확대해 해석하면 안 됩니다.

구성	장점	확인할 점
H.264 서브 스트림	구성이 단순하고 호환성이 넓음	카메라 동시 스트림 한도
H.265 그대로 전달	재인코딩 부하가 적음	브라우저·OS 실제 지원
서버에서 H.264 변환	다양한 브라우저 대응	CPU·GPU·지연·화질
HLS 변환	HTTP 배포와 캐시 활용	초기 지연과 세그먼트
WebRTC 변환	낮은 지연 관제에 유리	코덱 협상·NAT·TURN

직접 제작한 H.265 브라우저 재생 해결도. 녹화용 메인 스트림과 웹 관제용 서브 스트림을 분리하거나, 서버에서 지원 코덱으로 변환하는 방법을 비교합니다.

2. 먼저 실제 입력 코덱을 확인하세요

카메라 설정 화면의 표시만 믿지 말고 수신한 스트림에서 코덱을 확인합니다. 메인 스트림과 서브 스트림이 서로 다른 코덱일 수 있고, 설정을 바꾼 뒤 기존 세션이 남아 이전 코덱을 계속 받을 수도 있습니다.

ffprobe -rtsp_transport tcp -v error \
  -show_entries stream=codec_name,width,height,r_frame_rate \
  "rtsp://USER:PASSWORD@CAMERA_IP:554/STREAM_PATH"

codec_name=hevc가 나오면 H.265 입력입니다. 패킷 자체가 들어오지 않거나 401·404가 발생한다면 브라우저 코덱보다 앞단의 인증·주소 문제를 먼저 해결하세요. RTSP 401 해결 글에서 오류별 점검 순서를 확인할 수 있습니다.

3. 가장 단순한 방법은 H.264 서브 스트림입니다

많은 IP 카메라는 고화질 메인 스트림과 저해상도 서브 스트림을 동시에 제공합니다. NVR에는 H.265 메인 스트림을 저장하고, 여러 화면을 동시에 보는 웹 관제에는 H.264 서브 스트림을 연결하면 저장 효율과 브라우저 호환성을 분리할 수 있습니다.

이 방법은 서버 재인코딩 부하가 거의 없다는 장점이 있습니다. 다만 카메라가 지원하는 동시 인코딩 수, 서브 스트림의 최대 해상도·프레임률·비트레이트와 접속 세션 제한을 확인해야 합니다.

작은 다중 화면에서는 서브 스트림을 쓰고, 사용자가 카메라 하나를 확대할 때만 메인 스트림이나 고화질 변환 스트림을 요청하는 구성이 효율적입니다.

4. H.265를 서버에서 H.264로 변환하는 방법

카메라가 H.264를 제공하지 않거나 웹에서도 높은 해상도가 필요하면 미디어 서버나 FFmpeg가 H.265를 디코딩한 뒤 H.264로 다시 인코딩할 수 있습니다. 브라우저 쪽 호환성은 좋아지지만 CPU·GPU 사용량, 지연, 전력과 화질 손실이 추가됩니다.

채널 수가 늘면 한 채널 테스트의 자원 사용량을 단순히 곱하지 말고 동시 부하를 측정하세요. 해상도·프레임률·비트레이트를 제한하고 하드웨어 인코더의 세션 수와 지원 프로필을 확인합니다. 장애 시 원본 녹화까지 영향을 받지 않도록 녹화 경로와 웹 변환 경로를 분리하는 것이 좋습니다.

ITU-T H.265 공식 자료에서 표준 정보를 확인할 수 있지만, 표준 존재와 특정 브라우저 조합의 재생 가능성은 별도 문제입니다.

5. WebRTC와 HLS 중 무엇을 선택할까?

조작 반응과 실시간성이 중요한 관제 화면은 WebRTC를 먼저 검토할 수 있습니다. 다수 시청자에게 안정적으로 배포하거나 수초 이상의 지연을 허용할 수 있다면 HLS가 운영하기 쉬운 경우가 많습니다.

프로토콜을 WebRTC나 HLS로 바꾼다고 코덱이 자동으로 H.264가 되는 것은 아닙니다. 서버가 단순 재포장하는지, 실제로 디코딩·재인코딩하는지 확인하세요. MediaMTX WebRTC 코덱 문서처럼 서버가 설명하는 코덱과 브라우저 제한을 함께 봐야 합니다.

WebRTC와 HLS의 지연·확장성 차이는 WebRTC와 HLS 선택 글, HLS 배포 구조는 HLS와 MPEG-DASH 비교에서 자세히 설명합니다.

6. 검은 화면을 단계별로 진단하는 순서

1. VLC나 FFprobe에서 카메라 원본과 코덱을 확인합니다.
2. 미디어 서버 입력 로그에서 RTSP 인증과 패킷 수신을 확인합니다.
3. 서버 출력이 H.265 유지인지 H.264 변환인지 확인합니다.
4. 브라우저 개발자 도구에서 네트워크 실패와 미디어 오류를 구분합니다.
5. 같은 주소를 대상 OS·브라우저 조합에서 시험합니다.
6. H.264 서브 스트림으로 바꿔 결과가 달라지는지 비교합니다.

검은 화면과 연결 실패를 같은 오류로 묶지 마세요. HTTP 상태 코드, WebRTC 연결 상태, 세그먼트 요청, 디코더 오류 중 어디에서 멈추는지 기록하면 불필요한 재인코딩을 줄일 수 있습니다.

7. 자주 묻는 질문

H.265를 HLS로 만들면 모든 브라우저에서 나오나요?
아닙니다. HLS라는 전달 방식과 H.265 디코딩 지원은 별도입니다. 컨테이너·코덱과 대상 브라우저 조합을 실제로 시험해야 합니다.

H.264로 바꾸면 저장 용량이 무조건 두 배가 되나요?
고정 비율은 없습니다. 장면, 목표 화질, 프레임률, 비트레이트 제어와 인코더에 따라 달라집니다. 같은 조건의 실제 평균 비트레이트로 비교하세요.

재인코딩 없이 지연을 줄일 수 있나요?
브라우저가 입력 코덱을 지원한다면 재포장만으로 자원과 지연을 줄일 수 있습니다. 지원이 불확실하면 H.264 서브 스트림이 더 예측 가능한 선택일 수 있습니다.

코덱의 기본 차이는 H.264와 H.265 비교 글, ONVIF 이후 영상 경로는 ONVIF 검색 후 영상 문제 해결 글에서 이어서 볼 수 있습니다.

자료 확인일: 2026년 9월 14일. MDN·ITU-T·MediaMTX·FFmpeg 공식 문서를 바탕으로 작성했으며 브라우저 코덱 지원은 운영체제·하드웨어·버전에 따라 달라질 수 있습니다.