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의 독립성과 플러그 앤 플레이 성능 강조
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이라는 안내
Hacker News 의견