본문 바로가기
IOT

ESP32-CAM을 Synology NAS Surveillance Station에 연결하기 (HTTP MJPEG → RTSP 변환)

wookingwoo 2025. 10. 30. 00:34

ESP32-CAM은 저렴하고 작은 Wi-Fi 카메라 모듈로, 다양한 DIY 프로젝트와 홈 IoT 환경에서 많이 활용됩니다.
저는 ESP32-CAM 화면을 시놀로지 NAS의 Surveillance Station에 연결하고 싶었지만, 바로 연결이 쉽지 않았습니다. 이번 글에서는 그 이유와 해결 방법, 그리고 VLC로 테스트하는 과정까지 자세히 정리했습니다.

 

ESP32-CAM은 저렴하고 크기가 작아 DIY 카메라나 홈 IoT 프로젝트에서 자주 사용된다. Wi-Fi만 연결하면 바로 영상 스트림을 볼 수 있다는 점도 큰 장점이다.

 

문제는 이 ESP32-CAM 화면을 Synology NAS의 Surveillance Station에 연결하려고 했을 때였다.
브라우저에서는 잘 보이는데, NAS에서는 카메라로 인식되지 않았다. 이 글에서는 왜 이런 문제가 발생했는지, 어떻게 해결했는지를 정리해 보았다.


더 좋은 방법이 있다면 댓글로 공유해주시면 좋을 것 같아요~

 

1. 문제의 원인: 스트리밍 프로토콜 불일치

ESP32-CAM은 기본적으로 HTTP 기반 MJPEG 스트림을 제공한다.

http://<esp32-ip>:8080

 

이 주소는 브라우저에서 바로 열 수 있고, 영상도 문제없이 출력된다.
하지만 시놀로지 나스의 Surveillance Station은 기본적으로 RTSP(RTP 기반) 스트림을 전제로 설계되어 있다.
MJPEG 스트림도 지원을 한다고 하지만, 나는 정상적으로 동작하지 않는다ㅠㅠ 이유 아시는분 있으시면 알려주세요ㅠㅠ

정리하면 다음과 같다.

  • ESP32-CAM
    • HTTP MJPEG
    • 단순 연속 이미지 전송
    • 구현이 간단하고 MCU 부담이 적음
  • Surveillance Station
    • RTSP / RTP 기반 스트림
    • 실시간 녹화, 다중 카메라 관리에 최적화
    • MJPEG를 직접 카메라 스트림으로 인식하지 않음

즉, ESP32-CAM과 NAS 사이에는 프로토콜 레벨의 간극이 존재한다.
사실 Surveillance Station에서도 MJPEG 스트림을 지원하고 관련 설정 항목도 제공한다.
하지만 ESP32-CAM의 MJPEG 스트림을 그대로 등록하면, 카메라는 추가되지만 실제 영상 스트림이 송출되지 않는 문제에 부딪혔다.

 

이 상태에서는 코덱 설정이나 인증 방식, URL 옵션 등을 아무리 바꿔도 영상이 출력되지 않았다.
결국 단순히 “지원 여부”의 문제가 아니라, Surveillance Station이 기대하는 MJPEG 스트림 형태와 ESP32-CAM이 제공하는 방식 사이의 미묘한 불일치가 있는것 같다.

 

2. 해결 전략: 중간에서 RTSP로 변환

이를 해결하기 위해 굴러다니는 라즈베리파이를 하나 더 사용했다.
ESP32-CAM이 내보내는 MJPEG 스트림을 RTSP(H.264) 로 변환해주는 중간 계층을 하나 두는 것이다.

 

나는 이 역할을 라즈베리파이에 맡겼다.

 

구성 흐름은 다음과 같다.

ESP32-CAM (HTTP MJPEG)
        ↓
Raspberry Pi (FFmpeg + RTSP Server)
        ↓
Synology NAS Surveillance Station (RTSP)

 

2-1. 라즈베리파이에 RTSP 서버 구성

RTSP 서버로는 mediamtx(구 rtsp-simple-server)를 사용했다.
가볍고 설정이 단순해서 이 용도로 적합하다.

라즈베리파이 OS 아키텍처에 맞는 바이너리를 선택한다.

  • 32bit OS → linux_armv7
  • 64bit OS → linux_arm64
wget https://github.com/bluenviron/mediamtx/releases/download/v1.15.3/mediamtx_v1.15.3_linux_arm64.tar.gz
tar xzf mediamtx_v1.15.3_linux_arm64.tar.gz
cd mediamtx
./mediamtx

 

기본 설정 그대로 실행하면 RTSP 포트 8554에서 서버가 열린다.

 

2-2. MJPEG → H.264 → RTSP 변환 (FFmpeg)

 

이제 ESP32-CAM의 MJPEG 스트림을 받아서 RTSP 서버로 밀어 넣는다.
여기서 핵심은 H.264로 재인코딩하는 것이다.

# 예시 ESP32-CAM IP: 192.168.1.1

ffmpeg -i http://192.168.1.1:8080 \
       -c:v libx264 -preset ultrafast -tune zerolatency \
       -f rtsp rtsp://localhost:8554/mystream

 

옵션 설명은 다음과 같다.

  • -c:v libx264
    Surveillance Station에서 안정적으로 인식 가능한 코덱
  • -preset ultrafast
    인코딩 지연 최소화
  • -tune zerolatency
    실시간 스트리밍 최적화
  • -f rtsp
    출력 포맷을 RTSP로 지정

 

 

여기서 중요한 포인트가 하나 있다.

 

 

VLC에서는 MJPEG를 그대로 copy만 해도 잘 재생되지만,
Surveillance Station은 H.264 기반의 정규 RTSP 스트림을 엄격하게 요구한다.



이 차이를 이해하지 못하면 VLC에서는 되는데 NAS에서는 안 된는 상황에 빠지게 된다.

 

 

3. VLC로 RTSP 스트림 사전 검증

NAS에 붙이기 전에 RTSP 스트림이 정상인지 먼저 확인하는 것이 좋다.
이때 VideoLAN VLC가 가장 편하다.

 

 

3-1. VLC에서 확인

  • 메뉴 → File → Open Network
  • URL 입력
rtsp://<라즈베리파이 IP>:8554/mystream

영상이 바로 출력되면 변환 파이프라인은 정상이다.

 

 

3-2. 터미널에서 확인 (선택)

ffplay rtsp://<라즈베리파이 IP>:8554/mystream

ffplay는 FFmpeg 패키지에 포함되어 있다.

 

 

4. Surveillance Station에 카메라 추가

이제 NAS에서 카메라를 추가한다.

  • 카메라 추가 → 사용자 정의 / RTSP
  • 스트림 URL 입력
rtsp://<라즈베리파이 IP>:8554/mystream

 

정상적으로 영상이 표시되며, 녹화 및 이벤트 설정도 문제없이 동작한다.

 

 

5. 기술적으로 정리해보면

1) ESP32-CAM이 RTSP를 직접 지원하지 않는 이유

ESP32-CAM은 MCU 기반 보드다.

  • H.264 실시간 인코딩
  • RTSP 세션 관리
  • RTP 패킷 처리

이 모든 것을 동시에 처리하기에는 메모리와 CPU가 매우 제한적이다.
그래서 구현 부담이 적은 MJPEG + HTTP 방식이 기본 선택이다.

2) 중간 서버를 두는 구조의 장점

  • 프로토콜 변환 유연성 (MJPEG → H.264 → RTSP)
  • NAS, NVR, CCTV 소프트웨어와의 호환성 확보
  • Raspberry Pi Foundation Raspberry Pi 같은 저전력 장치로 충분히 처리 가능

3) 성능 조정 포인트

  • 지연이 크면 해상도 / FPS 감소
  • CPU 사용률이 높으면 인코딩 옵션 조정
  • Raspberry Pi 4 이상이면 실시간 변환에 무리 없음

 

한계점

중간에 라즈베리파이를 두고 MJPEG를 H.264 RTSP로 변환하면 Surveillance Station에서도 안정적으로 인식된다.

이 구조를 한 번 만들어두면 ESP32-CAM 같은 저가 모듈로도 NAS 기반의 홈 CCTV 환경을 충분히 구성할 수 있다.
동시에 스트리밍과 미디어 파이프라인을 이해하는 데도 꽤 좋은 경험이었다.

 

 

다만 이 방식에도 분명한 한계는 있다.


가장 먼저 체감되는 문제는 지연과 끊김이다.
MJPEG를 받아서 다시 H.264로 실시간 인코딩하는 과정 자체가 한 단계를 더 거치기 때문에, 네트워크 상태나 라즈베리파이의 부하에 따라 프레임 드롭이나 끊김이 발생하곤 한다. 특히 해상도나 FPS를 조금만 높여도 체감 지연이 눈에 띄게 늘어났다.

인프라의의 복잡도도 무시하기 어렵다.
ESP32-CAM은 필요할 때 전원 케이블만 꽂으면 곧바로 스트림이 살아난다. 반면 이 구조에서는 라즈베리파이가 항상 켜져 있어야 하고, RTSP 서버와 FFmpeg 변환 프로세스도 정상적으로 실행되고 있어야 한다. 부팅 순서가 꼬이거나 FFmpeg 프로세스가 비정상 종료되면 스트림이 올라오지 않는 경우도 생긴다. 배보다 배꼽이 더 큰 상황이다.

 

결과적으로 장비가 하나 더 늘어난다는 점도 부담이다.
전력 소모나 비용 문제도 있지만, 무엇보다 “간단함”이라는 ESP32-CAM의 장점을 스스로 깎아 먹는 느낌이 들었다. 단순히 카메라 하나 추가하려고 스트림 트랜스코딩 서버까지 관리해야 하는 구조가 과연 옳은 선택인지 의문이 들기 시작했다.

 

그래서 현재는 구조를 더 단순하게 가져가는 방향을 고민하고 있다.
ESP32-CAM 자체에서 RTSP 스트림을 직접 제공하는 방식이나, Surveillance Station이 MJPEG 스트림을 보다 안정적으로 처리할 수 있는 방법이 없는지를 중심으로 실험을 진행 중이다.

좋은 의견 있으시면 댓글 부탁드려요~~

티스토리툴바