# FFmpeg, WebRTC(WHIP) 초저지연 스트리밍 지원 머지

> Clean Markdown view of GeekNews topic #21288. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=21288](https://news.hada.io/topic?id=21288)
- GeekNews Markdown: [https://news.hada.io/topic/21288.md](https://news.hada.io/topic/21288.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-06-05T09:56:36+09:00
- Updated: 2025-06-05T09:56:36+09:00
- Original source: [git.ffmpeg.org](https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/167e343bbe75515a80db8ee72ffa0c607c944a00)
- Points: 3
- Comments: 1

## Topic Body

- **FFmpeg**에 **WHIP(WebRTC-HTTP Ingestion Protocol) muxer**가 정식 추가되어 **1초 미만 초저지연 스트리밍**을 직접 지원함  
- 이번 커밋에서 **WHIP muxer**의 네이밍 및 구조가 개편되고, **SSL/DTLS/RTC 오류 메시지와 로그**가 개선됨  
- **DTLS 곡선/프로파일, RTP payload, ICE STUN 등** 주요 프로토콜 파라미터가 크롬 정의에 맞게 업데이트되고, **매직 넘버**가 매크로 및 함수로 추출됨  
- **DTLS 핸드셰이크와 ICE 처리**가 하나의 함수로 통합 및 최적화되어 **성능과 안정성**이 크게 향상됨  
- **오디오, 비디오 트랜스코딩**(h264_mp4toannexb, OPUS timestamp, 마커 설정 등) 버그가 해결되어 표준 WebRTC 환경과 호환성 증가  
- **OpenSSL** 의존성을 명확히 하여, DTLS 지원 시에만 WHIP가 빌드됨  
- FFmpeg만으로 **WebRTC 기반 방송·실시간 스트림** 환경 구축이 쉬워지고, 기존 RTMP 등 레거시 프로토콜 대비 초저지연 특성을 활용할 수 있게 됨  
  
---  
  
### avformat/whip: FFmpeg WHIP muxer 지원 추가  
  
#### 주요 변경점 요약  
  
- **WHIP Version 3** 기반 muxer 정식 도입, 내부 명칭 및 구조 정비  
- SSL, DTLS, RTC의 **로그 컨텍스트와 에러 메시지**가 한층 명확해짐  
- 하드코딩된 **매직 넘버**를 매크로와 별도 함수로 추출해 유지보수성 강화  
- DTLS 곡선 리스트, SRTP 프로파일명 등 **FFmpeg와 OpenSSL 표준**에 맞춰 수정  
- **ICE STUN 매직 넘버, RTP 페이로드 타입**이 크롬 브라우저 표준과 일치하도록 업데이트  
- 오디오 프레임 크기, H.264 MP4→AnnexB 변환, OPUS 타임스탬프 등 **미디어 처리 이슈** 해결  
- DTLS 핸드셰이크와 ICE 처리 로직이 **단일 함수로 통합**되어 관리 용이  
- OpenSSL 기반 DTLS 지원 조건이 명확해져, **빌드 오류 및 호환성** 개선  
- SRTP, BIO 콜백, CA 키/인증서 초기화 등 **TLS/DTLS 내부 구조 통합**  
- whip.c 파일 신설 등 **총 13개 파일** 변경 및 신규 추가  
  
#### 배경 및 의미  
  
- **WHIP**는 WebRTC 기반 스트림 송출을 위한 HTTP 기반 표준 프로토콜로, 초저지연 라이브 방송에 필수적임  
- 그동안 FFmpeg에서 WebRTC 인코딩·송출은 별도 툴이나 복잡한 중계가 필요했으나, 이번 머지로 **FFmpeg 단일 명령어로 WHIP 송출**이 가능해짐  
- 실시간 방송, 라이브 커머스, 화상회의 등 다양한 분야에서 **최신 WebRTC 생태계와 직접 연동**할 수 있는 기술적 전환점

## Comments



### Comment 39758

- Author: neo
- Created: 2025-06-05T09:56:40+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=44182186) 
* WebRTC 방송에 엄청 설레는 감정 느끼는 중, Broadcast Box [README](https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#what-is-broadcast-box)와 OBS PR [링크](https://github.com/obsproject/obs-studio/pull/7926)에서 내가 정리한 이유 소개, 이제 GStreamer, OBS, FFmpeg 모두가 WHIP 지원하게 되어 모든 플랫폼에 적용 가능한 범용 비디오 방송 프로토콜 도달, 수년간 오픈소스 + WebRTC 방송 작업 경험으로 이번 성과가 큰 이정표라는 생각
  * 원격 dosbox 게임을 폰에서 VNC로 했었는데, 이제 input handler 웹앱 직접 만들고 이 기술+OBS 조합으로 무한히 시간 소비하는 새로운 도전 의욕
  * 모바일 스트리밍 유닛에서 여러 개의 5G 모뎀을 연결해 multipath/failover-bonding 기능 (예: SRT 개조로 H.265를 여러 링크로 송신) 추가 예정 있는지 질문
  * 인기있는 방송 소프트웨어, 모바일, 웹, 임베디드 등 다양한 플랫폼에서 직접 활용 경험 후 broadcast-box와 개발 기여에 놀라움
  * 나의 webrtc 라이브러리를 여러 프로젝트에서 유용하게 써주고 넓은 기술 스펙트럼에 영향 준 점 보며 기쁨 표출
* WebRTC-HTTP Ingestion Protocol (WHIP) 구현을 알림—SCTP 자체를 다루는 게 아니라, WebRTC를 사용하는 피어들과 HTTP를 통해 게이트웨이 역할 WHIP IDF 문서([링크](https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html)) 참고, 언젠가 SCTP 대신 QUIC이나 WebTransport 기반 p2p 프로토콜로 넘어가길 희망, Media-over-Quic(MoQ)에 관심 있지만 브라우저 지원이나 발전이 몇 년째 느려진 점 공유, 관련 링크는 [quic.video](https://quic.video/)와 [MoQ IETF introduction](https://datatracker.ietf.org/group/moq/about/)
  * SCTP 부분을 어떤 식으로 활용/노출하고 싶은지 묻는 질문, WHIP IETF 초안에 관련 언급이나 제안이 없어 애매함, 대부분의 'WHIP Provider'가 DataChannel을 지원하지만 표준화되지 않은 상황
* FFmpeg과 웹사이트의 직접 연결로 바로 오디오/비디오 스트림 수신이 가능한지 질문, 더 자세한 내용은 Phoronix 페이지 ([링크](https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer))에서 확인 가능
  * FFmpeg 라이브러리(특히 libavformat)를 사용하는 프로그램들이 WebRTC 스트림을 직접 받아 활용 가능하다는 요약 설명
* 이번 변화로 셀프 호스팅 스트림/스트리밍 CDN 구축이 훨씬 쉬워질 거라는 기대, ffmpeg의 독립성과 플러그 앤 플레이 성능 강조
  * Simulcast와 결합해 비용이나 진입장벽이 획기적으로 낮아질 전망, [broadcast-box](https://github.com/Glimesh/broadcast-box)를 만든 계기도 셀프호스팅+WebRTC의 진입장벽을 낮추기 위함
  * LLM 활용으로 ffmpeg 관련 모든 비디오 작업에 one-liner 명령까지 도출 가능, AI 사용 경험 극찬
  * ffmpeg의 다재다능함을 한눈에 보여주는 만화 [xkcd 2347](https://xkcd.com/2347/) 항상 떠오름
* Anubis 그래픽을 ffmpeg와 gnu 등에서 예상치 않게 만난 경험이 인상 깊음
* WHIP 기능 추가로 인해 시스템에 ffmpeg 유지하는 게 더 위험해지지 않을지 우려, WebRTC 보안 취약점이 실제로 많은 침해 원인이라고 느끼고 과거에도 브라우저 설치 후 항상 비활성 처리 경험
  * 어떤 보안 취약점이 있는지 질문, 이번 구현이 매우 작고, 사용자에게 최고의 결과물을 제공한다는 강한 확신 언급
  * --without-whip 같이 원치 않으면 빌드에서 아예 빼는 옵션 선택 가능한지 질문, 그렇게 되면 최상일 것이라고 의견
  * ffmpeg가 과거 보안 문제 경험이 많아 사용자 입력 처리에 있어선 항상 격리 환경 사용이 최선, 예를 들면 ffmpeg와 의존성만 포함된 도커 이미지를 매 작업마다 새로 띄워서 활용 또는 썸네일이나 문서 처리 필요하면 ClamAV, OpenOffice, ImageMagick 등 추가 장착 권장, 또 사용자 생성 파일을 다루는 서버는 최대한 분리된 VLAN 또는 AWS라면 보안그룹 내에서만 운용하는 방식 추천, 각 프로젝트에 비판 뜻 아니고 이진 포맷 자체의 어려움과 선제적 안전 대책의 중요성 강조, 4chan 사례도 참고, ffmpeg 보안 페이지는 [여기](https://ffmpeg.org/security.html)
* ffmpeg의 보안 감사 활동이 어떤지 질문, 공식 사이트에서 다소 사후 대응적으로 보인다는 느낌 공유
* ffmpeg로 이제 Jitsi 화상회의의 오디오 스트림 녹음이 가능한지 확인 질문
* whip 지원을 FFmpeg 소스 빌드에서 성공적으로 적용한 경험 있는지, 올바른 ./configure 옵션 찾기 어려움 토로
  * 필요한 옵션은 --enable-muxer=whip와 --enable-openssl이라는 안내
* Jellyfin에서 이번 기능이 적용될 날을 손꼽아 기다리는 중
  * 이에 대해 Jellyfin에 어떤 기능적 도움이 있을지 묻는 질문