Add WebRTC-HTTP ingestion protocol (WHIP) muxer & WebRTC-HTTP egress protocol (WHEP) demuxer#1
Open
MichiiR wants to merge 6 commits intorelease/6.1from
Open
Add WebRTC-HTTP ingestion protocol (WHIP) muxer & WebRTC-HTTP egress protocol (WHEP) demuxer#1MichiiR wants to merge 6 commits intorelease/6.1from
MichiiR wants to merge 6 commits intorelease/6.1from
Conversation
MichiiR
force-pushed
the
webrtc
branch
8 times, most recently
from
fb8d035 to
fe03611
Compare
|
Now have FFmpeg compiled with this PR and I also have Decklink enabled, could you share the FFmpeg commands you used to mux and demux using SRS with FFmpeg to get this kind of RTT latency results? |
This is needed for (de)muxers which need to access the Location header as transmitted when no redirection happend. Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
Whitespaces after semicolon breaks some servers Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
MichiiR
force-pushed
the
webrtc
branch
2 times, most recently
from
f92aa89 to
1b2d9f0
Compare
MichiiR
pushed a commit
that referenced
this pull request
Jan 17, 2024
In close_output(), a dummy frame is created with format NONE passed to enc_open(), which isn't prepared for it. The NULL pointer dereference happened at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth. When fgt.graph is NULL, skip fg_output_frame() since there is nothing to output. frame #0: 0x0000005555bc34a4 ffmpeg_g`enc_open(opaque=0xb400007efe2db690, frame=0xb400007efe2d9f70) at ffmpeg_enc.c:235:44 frame #1: 0x0000005555bef250 ffmpeg_g`enc_open(sch=0xb400007dde2d4090, enc=0xb400007e4e2daad0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:1462:11 frame FFmpeg#2: 0x0000005555bee094 ffmpeg_g`send_to_enc(sch=0xb400007dde2d4090, enc=0xb400007e4e2daad0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:1571:19 frame FFmpeg#3: 0x0000005555bee01c ffmpeg_g`sch_filter_send(sch=0xb400007dde2d4090, fg_idx=0, out_idx=0, frame=0xb400007efe2d9f70) at ffmpeg_sched.c:2154:12 frame FFmpeg#4: 0x0000005555bcf124 ffmpeg_g`close_output(ofp=0xb400007e4e2d85b0, fgt=0x0000007d1790eb08) at ffmpeg_filter.c:2225:15 frame FFmpeg#5: 0x0000005555bcb000 ffmpeg_g`fg_output_frame(ofp=0xb400007e4e2d85b0, fgt=0x0000007d1790eb08, frame=0x0000000000000000) at ffmpeg_filter.c:2317:16 frame FFmpeg#6: 0x0000005555bc7e48 ffmpeg_g`filter_thread(arg=0xb400007eae2ce7a0) at ffmpeg_filter.c:2836:15 frame FFmpeg#7: 0x0000005555bee568 ffmpeg_g`task_wrapper(arg=0xb400007d8e2db478) at ffmpeg_sched.c:2200:21 Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com>
|
The creation of a decoder should be based on the information of responsive_sdp, not on offer_stp |
MartinEesmaa
added a commit
to MartinEesmaa/FFmpeg-VVC
that referenced
this pull request
May 24, 2025
libdatachannel is for WHIP muxing and WHEP demuxing for WebRTC use. Special thanks, Michael Riedhl! (@MichiiR) Taken from pull request: nativewaves#1 - Martin Eesmaa
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch series adds support for WHIP and WHEP (WebRTC-HTTP ingestion protocol
and WebRTC-HTTP egress protocol). It supersedes the previous patch series for
WHIP.
The WHIP and WHEP are defined in the following draft RFCs:
The implementation builds on FFmpeg's existing RTP, HTTP and SDP support as well
as libdatachannel for the rest. This library is much more lightweight than other
libraries (e.g. libwebrtc). At the same time, using this library avoids
reimplementing parts of WebRTC in FFmpeg.
This patch series was tested with WebRTC servers Dolby.io (formerly Millicast)
and SRS (https://github.com/ossrs/srs). Using a local server, an end-to-end
latency of 3 frames (50 ms at 60 fps) was measured with video-only output, and
12 frames (200 ms at 60 fps) with audio and video output.
Using a DeckLink input device, an end-to-end latency of about 4 frames (70 ms at
60 fps) was measured with both, video-only and audio and video output.
Using a remote server, only the RTT is added to the end-to-end latency. For
example, using a server in Amsterdam (The Netherlands) from a location in
Salzburg (Austria), with RTT=18ms, an end-to-end latency of 50+18=68 ms was
measured for video-only output.