FFmpeg tích hợp hỗ trợ streaming độ trễ cực thấp qua WebRTC (WHIP)

 (git.ffmpeg.org)
3 điểm bởi GN⁺ 2025-06-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • WHIP muxer đã được đưa vào avformat/whip của FFmpeg, cho phép xử lý streaming độ trễ dưới 1 giây dựa trên WebRTC ngay trong FFmpeg
  • Thay đổi dựa trên WHIP Version 3; ngoài tên muxer và phần triển khai, các ngữ cảnh log và thông báo lỗi cho SSL·DTLS·RTC cũng được sắp xếp lại
  • Các magic number bên trong phần triển khai được thay bằng macro và hàm; việc xử lý danh sách DTLS curve, SRTP profile, magic number ICE STUN và RTP payload type cũng được tinh chỉnh
  • Ở đường dẫn media, thay vì kích thước frame cố định, nay dùng rtc->audio_par->frame_size, và sử dụng h264_mp4toannexb để chuyển đổi Annex B cho đầu vào MP4/ISOM
  • Cấu hình build được đổi để whip chỉ bật khi DTLS được kích hoạt, và hiện phạm vi hỗ trợ được giới hạn ở OpenSSL

Bổ sung WHIP muxer và nối vào hệ thống build

Sắp xếp lại xử lý DTLS·ICE·RTP

  • WHIP muxer được tinh chỉnh phần triển khai cùng với việc đổi tên, đồng thời cải thiện thông báo lỗi và ngữ cảnh log cho SSL·DTLS·RTC
  • Magic number được thay bằng macro, và một phần logic được tách ra thành hàm
    • Mức log cũng được điều chỉnh rõ ràng hơn
  • Trên đường dẫn DTLS, nhiều thay đổi liên quan đến tương thích và hiệu năng được đưa vào
    • Danh sách DTLS curve được cập nhật
    • Tên SRTP profile cho FFmpeg và OpenSSL được tinh chỉnh
    • DTLS handshake và xử lý ICE được tối ưu hóa để cải thiện hiệu năng
    • Dùng một handshake timeout duy nhất và server role để tránh ARQ
  • Xử lý ICE được sắp xếp theo hướng hợp nhất request/response và DTLS handshake vào một hàm duy nhất
    • Magic number ICE STUN được tinh chỉnh
  • RTP payload type được cập nhật dựa trên định nghĩa của Chrome

Xử lý media và ràng buộc OpenSSL

  • Kích thước frame cố định ở phía audio được đổi sang dùng rtc->audio_par->frame_size
  • h264_mp4toannexb được dùng để chuyển đổi đầu vào MP4/ISOM sang Annex B
  • Vấn đề OPUS timestamp và thiết lập marker sau khi dùng BSF cũng được sửa cùng lúc
  • Triển khai TLS và DTLS được hợp nhất vào một cấu trúc chung
    • BIO callback, read, write, print_ssl_error, openssl_init_ca_key_cert, init_bio_method được dùng chung
    • Sử dụng cùng một cấu trúc dữ liệu
  • Lỗi build OpenSSL được sửa để hoạt động phù hợp với Pion
  • configure được thay đổi để chỉ bật whip khi dtls được kích hoạt
    • Hiện đối tượng được hỗ trợ là OpenSSL

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-06-05
Ý kiến trên Hacker News

  • Mình thật sự rất mong chờ phát sóng WebRTC. Mình đã tóm tắt lý do trong README của Broadcast Box và PR của OBS
    Giờ đây GStreamer, OBS và FFmpeg đều hỗ trợ WHIP, xem như chúng ta đã có một giao thức phát video phổ quát có thể dùng trên mọi nền tảng như di động, web, nhúng, phần mềm phát sóng, v.v.
    Mình đã làm việc trong mảng mã nguồn mở và phát sóng WebRTC suốt vài năm qua, và xem đây là một cột mốc lớn
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • Từ góc nhìn của người làm trong lĩnh vực phát sóng sự kiện, thay đổi này có thể biến OBS thành một lựa chọn thay thế thực tế cho các phần mềm chuyên nghiệp như vMix. Đặc biệt, hỗ trợ P2P và khả năng phát nhiều cảnh có vẻ rất giá trị
    • Mình tò mò liệu có trình phát video nào có thể phát stream WebRTC không. Lần cuối mình kiểm tra thì VLC hay các công cụ phổ biến khác vẫn chưa hỗ trợ

  • Không phải phần SCTP. Thực ra đây là triển khai WebRTC-HTTP Ingestion Protocol, tức WHIP, một giao thức HTTP độ trễ thấp để kết nối tới gateway giao tiếp với peer bằng giao thức dựa trên SCTP của WebRTC
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    Hy vọng một ngày nào đó có thể chuyển sang giao thức P2P dựa trên QUIC hoặc WebTransport thay cho SCTP. QUIC xử lý tốt những gì SCTP làm trên UDP hiện có, mà không làm tăng mạnh độ phức tạp hay khác biệt giữa các triển khai
    Một ứng viên là Media-over-QUIC(MoQ), nhưng trình duyệt không có P2P QUIC và tiến độ ở hướng đó cũng đã đình trệ từ vài năm trước
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • Mình tò mò nên phơi bày và dùng phần SCTP như thế nào. Bản nháp WHIP của IETF có vẻ không đề cập hay đề xuất gì về chuyện đó
      Hầu hết nhà cung cấp WHIP cũng hỗ trợ DataChannel, nhưng nó vẫn chưa được chuẩn hóa

  • Mình thắc mắc điều này có nghĩa là gì. Có phải website có thể kết nối trực tiếp tới một phiên bản FFmpeg để nhận stream âm thanh hoặc video không?
    Phoronix giải thích chi tiết hơn một chút: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • Có vẻ nghĩa là các chương trình dùng thư viện FFmpeg, đặc biệt là libavformat, sẽ có thể nhận stream WebRTC

  • Như vậy có lẽ sẽ dễ hơn nhiều để tạo stream tự host hoặc CDN streaming
    FFmpeg, nếu biết cách dùng, đúng là một phần mềm media độc lập, plug-and-play rất đáng kinh ngạc

    • Thật sự đáng mong chờ. Đặc biệt nếu có cả Simulcast thì có thể giúp mọi người làm việc này rất rẻ và dễ
      Mình đã tạo https://github.com/Glimesh/broadcast-box vì muốn việc tự host và WebRTC trở nên dễ hơn nhiều
    • LLM hiểu cách dùng FFmpeg thật sự rất tốt. Gần như bất kỳ tác vụ liên quan đến video nào bạn hỏi, chúng đều tạo được một lệnh ffmpeg một dòng phù hợp
    • Đúng vậy, và mình luôn nhớ tới truyện tranh này: https://xkcd.com/2347/

  • Gajim, một client XMPP, đã chờ điều này từ lâu. Tính năng gọi âm thanh/video gần như bị bỏ mặc, và họ đã kiên nhẫn chờ FFmpeg giúp việc thêm lại tính năng này trở nên dễ hơn

    • Mình tò mò liệu Gajim và XMPP vẫn còn được dùng không. Nhớ thời dùng pidgin cho các ứng dụng chat như trước đây
      Giờ thì tất cả đã thành các khu vườn đóng hoặc dịch vụ riêng theo từng app

  • Thấy đồ họa Anubis một cách bất ngờ thì cũng vui. Đến giờ mình đã thấy nó ở ffmpeg và gnu, v.v.

    • Mình cũng thích, nhưng lần này nó không cho mình vào

  • Hy vọng điều này không khiến việc có ffmpeg trong hệ thống trở nên nguy hiểm hơn. Lỗ hổng bảo mật WebRTC là nguyên nhân của nhiều vụ xâm nhập, và đây là một trong những tính năng mình tắt đầu tiên khi cài trình duyệt

    • Mình tò mò bạn đang nói tới lỗ hổng bảo mật nào
      Triển khai này rất nhỏ, và mình chắc chắn 100% rằng nó cung cấp cho người dùng thứ tốt nhất có thể
    • ffmpeg là mã hiệu năng cao xử lý các codec và định dạng nhị phân khó hiểu bằng C, nên có vẻ không cần chỉ lo riêng WebRTC
    • Nếu không muốn hoặc không cần, mình tò mò có thể loại nó khỏi bản build bằng tham số kiểu --without-whip không. Như vậy có vẻ lý tưởng
    • ffmpeg trước đây cũng từng có nhiều vấn đề bảo mật [1], nên khi xử lý đầu vào từ người dùng thì dù sao cách làm tốt nhất vẫn là cô lập kỹ
      Nên tạo một Docker image chỉ gồm ffmpeg và các phụ thuộc, rồi chạy docker run cho từng tác vụ chuyển đổi. Nếu cũng cần tạo ảnh hoặc thumbnail tài liệu thì có thể đưa thêm ClamAV, OpenOffice, ImageMagick vào
      Cá nhân mình cho rằng các server vượt quá mức chỉ nhận và phục vụ file do người dùng tạo, tức có xử lý chúng, nên được đặt trong một VLAN riêng được khóa chặt; nếu trên AWS thì trong Security Group
      Đây không phải là lời chê bai thiếu hiểu biết nhắm vào các dự án được nhắc tới. Bảo mật rất khó, đặc biệt khi xử lý các định dạng nhị phân tích lũy lâu năm và đôi khi được reverse engineer theo những cách đáng ngờ. Thừa nhận điều này trước khi bị như 4chan là điều khôn ngoan
      [1] https://ffmpeg.org/security.html

  • Rất hay. Mình đang làm một hệ thống điều khiển từ xa nền web, và nếu có thể biến ffmpeg gdigrab thành stream WebRTC để client tiêu thụ trực tiếp mà không cần cách làm vòng qua ExpressJS như hiện tại, thì sẽ rất hài lòng

  • Thú vị là mình cứ bị chặn bởi bot detection trên iOS Safari. Cả WiFi công ty lẫn dữ liệu di động đều bị vậy
    Mong Anubis cho mình qua

    • Mình tò mò liệu bạn thấy trang "access denied", hay thử thách cứ lặp vô hạn
    • Không biết có phải bạn đang dùng mạng dual-stack không

  • Anubis không cho mình qua ;(