FFmpeg hợp nhất hỗ trợ streaming siêu độ trễ thấp với WebRTC (WHIP)

• FFmpeg đã chính thức bổ sung muxer WHIP (WebRTC-HTTP Ingestion Protocol), trực tiếp hỗ trợ streaming siêu độ trễ thấp dưới 1 giây
• Ở commit lần này, phần đặt tên và cấu trúc của WHIP muxer được cải tổ, đồng thời thông báo lỗi và log SSL/DTLS/RTC được cải thiện
• Các tham số giao thức chính như đường cong/hồ sơ DTLS, RTP payload, ICE STUN đã được cập nhật để khớp với định nghĩa của Chrome, và magic number được tách ra thành macro và hàm
• Bắt tay DTLS và xử lý ICE được hợp nhất và tối ưu vào một hàm duy nhất, giúp hiệu năng và độ ổn định cải thiện đáng kể
• Các lỗi liên quan đến transcoding âm thanh, video (h264_mp4toannexb, timestamp OPUS, thiết lập marker, v.v.) đã được sửa, tăng khả năng tương thích với môi trường WebRTC chuẩn
• Làm rõ phụ thuộc vào OpenSSL, để WHIP chỉ được build khi có hỗ trợ DTLS
• Chỉ với FFmpeg, việc xây dựng môi trường phát sóng và luồng thời gian thực dựa trên WebRTC trở nên dễ dàng hơn, đồng thời có thể tận dụng đặc tính siêu độ trễ thấp so với các giao thức legacy như RTMP

---

avformat/whip: Thêm hỗ trợ FFmpeg WHIP muxer

Tóm tắt các thay đổi chính

• Chính thức đưa vào muxer dựa trên WHIP Version 3, đồng thời chỉnh lý tên gọi và cấu trúc nội bộ
• Ngữ cảnh log và thông báo lỗi của SSL, DTLS, RTC trở nên rõ ràng hơn đáng kể
• Tách các magic number hardcode thành macro và hàm riêng để tăng khả năng bảo trì
• Chỉnh sửa danh sách đường cong DTLS, tên hồ sơ SRTP để phù hợp với chuẩn của FFmpeg và OpenSSL
• Cập nhật ICE STUN magic number, RTP payload type để khớp với tiêu chuẩn của trình duyệt Chrome
• Giải quyết các vấn đề xử lý media như kích thước khung âm thanh, chuyển đổi H.264 MP4→AnnexB, timestamp OPUS
• Logic bắt tay DTLS và xử lý ICE được hợp nhất vào một hàm duy nhất, giúp dễ quản lý hơn
• Điều kiện hỗ trợ DTLS dựa trên OpenSSL được làm rõ, cải thiện lỗi build và khả năng tương thích
• Hợp nhất cấu trúc nội bộ TLS/DTLS như SRTP, callback BIO, khởi tạo khóa/chứng chỉ CA
• Thay đổi và bổ sung mới tổng cộng 13 tệp, bao gồm cả tệp whip.c

Bối cảnh và ý nghĩa

• WHIP là giao thức chuẩn dựa trên HTTP để phát luồng bằng WebRTC, rất quan trọng với phát sóng trực tiếp siêu độ trễ thấp
• Trước đây, việc mã hóa và phát WebRTC trong FFmpeg cần công cụ riêng hoặc hệ thống relay phức tạp, nhưng với lần hợp nhất này, có thể phát WHIP bằng một lệnh FFmpeg duy nhất
• Đây là bước ngoặt kỹ thuật giúp kết nối trực tiếp với hệ sinh thái WebRTC hiện đại trong nhiều lĩnh vực như phát sóng thời gian thực, live commerce, hội nghị truyền hình

[GN⁺]

Ý kiến trên Hacker News

• Tôi đang cực kỳ hào hứng với phát sóng qua WebRTC; trong README của Broadcast Box và PR OBS này có giải thích lý do tôi tổng hợp lại. Giờ đây GStreamer, OBS và FFmpeg đều hỗ trợ WHIP, nghĩa là đã tiến tới một giao thức phát video phổ dụng có thể áp dụng trên mọi nền tảng. Với nhiều năm làm việc về phát sóng mã nguồn mở + WebRTC, tôi xem đây là một cột mốc lớn
  • Trước đây tôi từng chơi game dosbox từ xa trên điện thoại qua VNC, còn giờ thì muốn tự làm một webapp input handler và kết hợp công nghệ này với OBS để bước vào một thử thách mới có thể ngốn vô hạn thời gian
  • Có kế hoạch bổ sung tính năng multipath/failover-bonding trên thiết bị streaming di động bằng cách gắn nhiều modem 5G không, ví dụ sửa SRT để truyền H.265 qua nhiều liên kết?
  • Thật ấn tượng khi thấy broadcast-box và các đóng góp phát triển sau khi đã trực tiếp dùng trên nhiều nền tảng khác nhau như phần mềm phát sóng phổ biến, di động, web, embedded
  • Tôi rất vui khi thư viện webrtc của mình được dùng hữu ích trong nhiều dự án và tạo ảnh hưởng trên một phổ kỹ thuật rộng như vậy
• Thông báo đã triển khai WebRTC-HTTP Ingestion Protocol (WHIP) — đây không phải là tự xử lý SCTP, mà là WHIP đóng vai trò gateway qua HTTP với các peer dùng WebRTC; tham khảo tài liệu IETF IDF (liên kết). Hy vọng một ngày nào đó sẽ chuyển từ SCTP sang giao thức p2p dựa trên QUIC hoặc WebTransport. Tôi có quan tâm đến Media-over-Quic (MoQ), nhưng việc hỗ trợ trên trình duyệt và tiến triển chung đã chững lại suốt nhiều năm; liên kết liên quan là quic.video và MoQ IETF introduction
  • Câu hỏi là muốn tận dụng/phơi bày phần SCTP theo cách nào, vì trong bản nháp IETF của WHIP không thấy đề cập hay đề xuất liên quan nên khá mơ hồ; đa số “WHIP Provider” có hỗ trợ DataChannel nhưng chưa được chuẩn hóa
• Có thể kết nối trực tiếp FFmpeg với website để nhận luồng audio/video ngay lập tức không? Có thể xem chi tiết hơn trên trang Phoronix (liên kết)
  • Tóm lại là các chương trình dùng thư viện FFmpeg, đặc biệt là libavformat, có thể trực tiếp nhận và sử dụng luồng WebRTC
• Kỳ vọng thay đổi này sẽ giúp việc tự dựng stream/self-hosting hoặc xây dựng CDN streaming dễ hơn rất nhiều; nhấn mạnh tính độc lập và khả năng plug-and-play của ffmpeg
  • Khi kết hợp với Simulcast, chi phí và rào cản gia nhập có thể giảm mạnh; broadcast-box cũng được tạo ra chính để hạ thấp rào cản của self-hosting + WebRTC
  • Nhờ LLM có thể rút ra cả những lệnh one-liner cho mọi tác vụ video liên quan đến ffmpeg; hết lời khen trải nghiệm dùng AI
  • Tôi luôn nhớ đến truyện tranh xkcd 2347 vì nó cho thấy sự đa năng của ffmpeg chỉ trong một cái nhìn
• Trải nghiệm bắt gặp đồ họa Anubis ở những nơi không ngờ tới như ffmpeg và gnu để lại ấn tượng mạnh
• Lo ngại rằng việc thêm WHIP sẽ khiến việc giữ ffmpeg trong hệ thống trở nên rủi ro hơn; cảm giác rằng các lỗ hổng bảo mật WebRTC thực tế là nguyên nhân của nhiều vụ xâm nhập, và trước đây sau khi cài trình duyệt tôi luôn vô hiệu hóa nó
  • Hỏi cụ thể là có những lỗ hổng bảo mật nào; nhấn mạnh rằng phần triển khai lần này rất nhỏ và có niềm tin mạnh mẽ rằng nó mang lại kết quả tốt nhất cho người dùng
  • Hỏi liệu có thể có tùy chọn kiểu --without-whip để loại hẳn khỏi bản build nếu không muốn dùng, như vậy sẽ là tốt nhất
  • ffmpeg trước đây từng có nhiều vấn đề bảo mật, nên khi xử lý đầu vào từ người dùng thì tốt nhất luôn dùng môi trường cô lập; ví dụ tạo mới một Docker image chỉ chứa ffmpeg và các phụ thuộc cho mỗi tác vụ, hoặc nếu cần xử lý thumbnail hay tài liệu thì nên bổ sung ClamAV, OpenOffice, ImageMagick..., đồng thời máy chủ xử lý file do người dùng tạo nên được tách tối đa vào VLAN riêng hoặc nếu dùng AWS thì chỉ vận hành trong security group nội bộ. Đây không phải chỉ trích từng dự án cụ thể, mà là nhấn mạnh độ khó vốn có của định dạng nhị phân và tầm quan trọng của biện pháp an toàn chủ động; có thể tham khảo cả trường hợp của 4chan. Trang bảo mật của ffmpeg ở đây
• Hỏi về hoạt động audit bảo mật của ffmpeg; chia sẻ cảm giác rằng trên trang chính thức mọi thứ có vẻ hơi mang tính phản ứng sau sự cố
• Hỏi liệu giờ có thể dùng ffmpeg để ghi lại luồng âm thanh từ cuộc họp video Jitsi không
• Có ai đã áp dụng thành công hỗ trợ whip khi tự build FFmpeg từ mã nguồn chưa, vì rất khó tìm đúng tùy chọn ./configure
  • Tùy chọn cần thiết là --enable-muxer=whip và --enable-openssl
• Đang đếm từng ngày chờ tính năng này được áp dụng trong Jellyfin
  • Nhân đó có câu hỏi là tính năng này sẽ giúp ích cụ thể gì cho Jellyfin về mặt chức năng