FFmpeg में WebRTC (WHIP) ultra-low-latency streaming support मर्ज

• FFmpeg में WHIP (WebRTC-HTTP Ingestion Protocol) muxer आधिकारिक रूप से जोड़ा गया है, जिससे सीधे 1 सेकंड से कम ultra-low-latency streaming का समर्थन मिलता है
• इस कमिट में WHIP muxer की naming और structure को पुनर्गठित किया गया है, और SSL/DTLS/RTC error messages और logs को बेहतर बनाया गया है
• DTLS curves/profiles, RTP payload, ICE STUN जैसे प्रमुख protocol parameters को Chrome definitions के अनुरूप अपडेट किया गया है, और magic numbers को macros और functions में निकाला गया है
• DTLS handshake और ICE processing को एक function में एकीकृत और optimize किया गया है, जिससे performance और stability में बड़ा सुधार हुआ है
• audio, video transcoding (h264_mp4toannexb, OPUS timestamp, marker setting आदि) से जुड़े bugs ठीक किए गए हैं, जिससे standard WebRTC environments के साथ compatibility बढ़ी है
• OpenSSL dependency को स्पष्ट किया गया है, ताकि DTLS support होने पर ही WHIP build हो
• केवल FFmpeg के साथ WebRTC-आधारित broadcasting और real-time stream environment बनाना आसान हो गया है, और existing RTMP जैसे legacy protocols की तुलना में ultra-low-latency characteristics का लाभ उठाया जा सकता है

---

avformat/whip: FFmpeg WHIP muxer support जोड़ा गया

मुख्य बदलावों का सार

• WHIP Version 3 आधारित muxer का आधिकारिक समावेश, internal naming और structure को व्यवस्थित किया गया
• SSL, DTLS, RTC के log context और error messages अब अधिक स्पष्ट हैं
• hardcoded magic numbers को macros और अलग functions में निकालकर maintainability बढ़ाई गई
• DTLS curve list, SRTP profile names आदि को FFmpeg और OpenSSL standards के अनुरूप संशोधित किया गया
• ICE STUN magic numbers, RTP payload types को Chrome browser standard के अनुरूप अपडेट किया गया
• audio frame size, H.264 MP4→AnnexB conversion, OPUS timestamp जैसे media processing issues का समाधान किया गया
• DTLS handshake और ICE processing logic को एक single function में integrate किया गया, जिससे management आसान हुआ
• OpenSSL-आधारित DTLS support की conditions स्पष्ट होने से build errors और compatibility में सुधार हुआ
• SRTP, BIO callbacks, CA key/certificate initialization सहित TLS/DTLS internal structure integration किया गया
• whip.c फ़ाइल के नए जुड़ने सहित कुल 13 files में बदलाव और नए additions किए गए

पृष्ठभूमि और महत्व

• WHIP WebRTC-आधारित stream publishing के लिए HTTP-आधारित standard protocol है, और ultra-low-latency live broadcasting के लिए महत्वपूर्ण है
• अब तक FFmpeg में WebRTC encoding और publishing के लिए अलग tools या जटिल relay setup की जरूरत पड़ती थी, लेकिन इस merge के बाद FFmpeg के एक single command से WHIP publishing संभव हो गई है
• real-time broadcasting, live commerce, video conferencing जैसे कई क्षेत्रों में नवीनतम WebRTC ecosystem के साथ direct integration के लिए यह एक महत्वपूर्ण तकनीकी मोड़ है

[GN⁺]

Hacker News टिप्पणियाँ

• WebRTC ब्रॉडकास्टिंग को लेकर मैं बहुत उत्साहित हूँ; Broadcast Box README और OBS PR लिंक में मैंने इसके कारणों का सार दिया है। अब GStreamer, OBS और FFmpeg — तीनों WHIP को सपोर्ट करते हैं, इसलिए हम सभी प्लेटफ़ॉर्म पर लागू होने वाला एक सार्वभौमिक वीडियो ब्रॉडकास्ट प्रोटोकॉल पाने के करीब हैं। कई वर्षों के open source + WebRTC ब्रॉडकास्टिंग अनुभव के बाद, यह उपलब्धि एक बड़ा मील का पत्थर लगती है.
  • मैं पहले फ़ोन पर VNC से remote dosbox गेम खेलता था, लेकिन अब खुद का input handler web app बनाकर इस तकनीक+OBS के साथ अनंत समय बर्बाद करने वाली नई चुनौती लेने का मन है.
  • सवाल: क्या mobile streaming unit में कई 5G modem जोड़कर multipath/failover-bonding फ़ीचर (जैसे SRT को मॉडिफ़ाई करके H.265 को कई links पर भेजना) जोड़ने की कोई योजना है?
  • लोकप्रिय broadcasting software, mobile, web, embedded आदि कई प्लेटफ़ॉर्म पर इसे सीधे इस्तेमाल करने के बाद, broadcast-box और उसके development contributions वाकई चौंकाने वाले लगे.
  • यह देखकर खुशी होती है कि मेरी webrtc library कई projects में उपयोगी रही है और उसने इतने व्यापक technical spectrum पर प्रभाव डाला है.
• WebRTC-HTTP Ingestion Protocol (WHIP) implementation की सूचना — यह SCTP को सीधे हैंडल करने के बारे में नहीं है, बल्कि WebRTC इस्तेमाल करने वाले peers के लिए HTTP के माध्यम से gateway की भूमिका निभाने वाला WHIP IDF दस्तावेज़ है (लिंक)। उम्मीद है कि किसी दिन SCTP की जगह QUIC या WebTransport आधारित p2p protocol अपनाया जाएगा। Media-over-Quic(MoQ) में रुचि है, लेकिन browser support और प्रगति कई वर्षों से धीमी पड़ी है; संबंधित लिंक: quic.video और MoQ IETF introduction
  • सवाल: आप SCTP वाले हिस्से को किस तरह उपयोग या expose करना चाहते हैं? WHIP IETF draft में इस पर कोई स्पष्ट उल्लेख या proposal नहीं दिखता, इसलिए बात थोड़ी अस्पष्ट है। ज़्यादातर 'WHIP Provider' DataChannel सपोर्ट करते हैं, लेकिन यह standardized नहीं है.
• सवाल: क्या FFmpeg और वेबसाइट के सीधे कनेक्शन से तुरंत audio/video stream receive की जा सकती है? अधिक जानकारी Phoronix पेज पर उपलब्ध है (लिंक)
  • सार: FFmpeg library, खासकर libavformat, का उपयोग करने वाले प्रोग्राम अब सीधे WebRTC streams लेकर उनका उपयोग कर सकेंगे.
• उम्मीद है कि इस बदलाव से self-hosted streams/streaming CDN बनाना काफी आसान हो जाएगा; ffmpeg की independence और plug-and-play क्षमता यहाँ खास है.
  • Simulcast के साथ मिलकर यह लागत और entry barrier दोनों को नाटकीय रूप से घटा सकता है; broadcast-box बनाने की एक वजह self-hosting+WebRTC की entry barrier कम करना भी थी.
  • LLM की मदद से ffmpeg से जुड़े हर तरह के video task के लिए one-liner command तक निकाली जा सकती है; AI उपयोग अनुभव की ज़ोरदार प्रशंसा.
  • ffmpeg की versatility देखते ही मुझे हमेशा xkcd 2347 वाला comic याद आता है.
• Anubis graphic को ffmpeg और gnu जैसी जगहों पर अप्रत्याशित रूप से देखना काफ़ी प्रभावशाली लगा.
• चिंता: क्या WHIP फ़ीचर जुड़ने से सिस्टम पर ffmpeg बनाए रखना और जोखिमभरा हो जाएगा? मुझे लगता है कि WebRTC security vulnerabilities वास्तविक compromises का अक्सर कारण रही हैं, और पहले browser install करने के बाद मैं इन्हें हमेशा disable कर देता था.
  • सवाल: कौन-सी security vulnerabilities? यह implementation बहुत छोटी है, और इस बात पर काफ़ी भरोसा जताया गया है कि यह users को बेहतरीन result देगी.
  • सवाल: क्या --without-whip जैसा विकल्प होगा ताकि जो लोग नहीं चाहते वे build से इसे पूरी तरह हटा सकें? ऐसा हो तो सबसे अच्छा होगा.
  • ffmpeg का security issues का इतिहास लंबा रहा है, इसलिए user input process करने के मामले में isolated environment इस्तेमाल करना हमेशा सबसे अच्छा है। उदाहरण के लिए, केवल ffmpeg और उसकी dependencies वाला Docker image हर job के लिए नया चलाएँ; या अगर thumbnails/document processing चाहिए तो ClamAV, OpenOffice, ImageMagick आदि भी जोड़ें। साथ ही, user-generated files हैंडल करने वाले servers को यथासंभव अलग VLAN में रखें, या AWS में हों तो केवल security group के अंदर ही ऑपरेट करें। यह किसी project की आलोचना नहीं, बल्कि binary formats की अंतर्निहित कठिनाई और proactive safety measures के महत्व पर ज़ोर है। 4chan का मामला भी देखें। ffmpeg security page यहाँ है.
• सवाल: ffmpeg की security audit गतिविधि कैसी है? आधिकारिक साइट देखकर थोड़ा reactive approach जैसा लगता है.
• सवाल: क्या अब ffmpeg से Jitsi video conference की audio stream रिकॉर्ड की जा सकती है?
• क्या किसी ने FFmpeg source build में whip support सफलतापूर्वक सक्षम किया है? सही ./configure options ढूँढना कठिन लग रहा है.
  • आवश्यक options हैं --enable-muxer=whip और --enable-openssl.
• मैं उस दिन का इंतज़ार कर रहा हूँ जब यह फ़ीचर Jellyfin में पहुँचेगा.
  • जवाब में सवाल: इससे Jellyfin को कार्यात्मक रूप से क्या लाभ होगा?