▲

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

 (git.ffmpeg.org)
3P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 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 생태계와 직접 연동할 수 있는 기술적 전환점
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • WebRTC 방송에 엄청 설레는 감정 느끼는 중, Broadcast Box README와 OBS PR 링크에서 내가 정리한 이유 소개, 이제 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 문서(링크) 참고, 언젠가 SCTP 대신 QUIC이나 WebTransport 기반 p2p 프로토콜로 넘어가길 희망, Media-over-Quic(MoQ)에 관심 있지만 브라우저 지원이나 발전이 몇 년째 느려진 점 공유, 관련 링크는 quic.video와 MoQ IETF introduction
    • SCTP 부분을 어떤 식으로 활용/노출하고 싶은지 묻는 질문, WHIP IETF 초안에 관련 언급이나 제안이 없어 애매함, 대부분의 'WHIP Provider'가 DataChannel을 지원하지만 표준화되지 않은 상황
  • FFmpeg과 웹사이트의 직접 연결로 바로 오디오/비디오 스트림 수신이 가능한지 질문, 더 자세한 내용은 Phoronix 페이지 (링크)에서 확인 가능
    • FFmpeg 라이브러리(특히 libavformat)를 사용하는 프로그램들이 WebRTC 스트림을 직접 받아 활용 가능하다는 요약 설명
  • 이번 변화로 셀프 호스팅 스트림/스트리밍 CDN 구축이 훨씬 쉬워질 거라는 기대, ffmpeg의 독립성과 플러그 앤 플레이 성능 강조
    • Simulcast와 결합해 비용이나 진입장벽이 획기적으로 낮아질 전망, broadcast-box를 만든 계기도 셀프호스팅+WebRTC의 진입장벽을 낮추기 위함
    • LLM 활용으로 ffmpeg 관련 모든 비디오 작업에 one-liner 명령까지 도출 가능, AI 사용 경험 극찬
    • ffmpeg의 다재다능함을 한눈에 보여주는 만화 xkcd 2347 항상 떠오름
  • Anubis 그래픽을 ffmpeg와 gnu 등에서 예상치 않게 만난 경험이 인상 깊음
  • WHIP 기능 추가로 인해 시스템에 ffmpeg 유지하는 게 더 위험해지지 않을지 우려, WebRTC 보안 취약점이 실제로 많은 침해 원인이라고 느끼고 과거에도 브라우저 설치 후 항상 비활성 처리 경험
    • 어떤 보안 취약점이 있는지 질문, 이번 구현이 매우 작고, 사용자에게 최고의 결과물을 제공한다는 강한 확신 언급
    • --without-whip 같이 원치 않으면 빌드에서 아예 빼는 옵션 선택 가능한지 질문, 그렇게 되면 최상일 것이라고 의견
    • ffmpeg가 과거 보안 문제 경험이 많아 사용자 입력 처리에 있어선 항상 격리 환경 사용이 최선, 예를 들면 ffmpeg와 의존성만 포함된 도커 이미지를 매 작업마다 새로 띄워서 활용 또는 썸네일이나 문서 처리 필요하면 ClamAV, OpenOffice, ImageMagick 등 추가 장착 권장, 또 사용자 생성 파일을 다루는 서버는 최대한 분리된 VLAN 또는 AWS라면 보안그룹 내에서만 운용하는 방식 추천, 각 프로젝트에 비판 뜻 아니고 이진 포맷 자체의 어려움과 선제적 안전 대책의 중요성 강조, 4chan 사례도 참고, ffmpeg 보안 페이지는 여기
  • ffmpeg의 보안 감사 활동이 어떤지 질문, 공식 사이트에서 다소 사후 대응적으로 보인다는 느낌 공유
  • ffmpeg로 이제 Jitsi 화상회의의 오디오 스트림 녹음이 가능한지 확인 질문
  • whip 지원을 FFmpeg 소스 빌드에서 성공적으로 적용한 경험 있는지, 올바른 ./configure 옵션 찾기 어려움 토로
    • 필요한 옵션은 --enable-muxer=whip와 --enable-openssl이라는 안내
  • Jellyfin에서 이번 기능이 적용될 날을 손꼽아 기다리는 중
    • 이에 대해 Jellyfin에 어떤 기능적 도움이 있을지 묻는 질문
답변달기