Make sure the WHIP protocol performs the SDP offer/answer
exchange with the WebRTC peer over HTTP.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: Jack Lau <jacklau1222@qq.com>
h264_annexb_insert_sps_pps (called after write_packet)
reorganizes PPS, SPS, and IDR packets in H.264 streams.
Since write_packet already validates pkt,
redundant null checks in h264_annexb_insert_sps_pps can be removed.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
Since 155508c6e9 specifying multiple
bsfs for different streams was broken:
"[bsfs/a=h264_metadata:bsfs/v=h264_metadata]out.mp4|..."
This incorrectly only parsed the first bsfs specification. The reason
for this is that the dictionary is modified in the iterator, hence
invalidating the iterator. The simplest fix for this is to simply
iterate from the beginning in each loop given that the previous entry
is removed.
The way streams are coded in an IAMF struct follows a scalable model where the
channel layouts for each layer may not match the channel order our API can
represent in a Native order layout.
For example, an audio element may have six coded streams in the form of two
stereo streams, followed by two mono streams, and then by another two stereo
streams, for a total of 10 channels, and define for them four scalable layers
with loudspeaker_layout values "Stereo", "5.1ch", "5.1.2ch", and "5.1.4ch".
The first layer references the first stream, and each following layer will
reference all previous streams plus extra ones.
In this case, the "5.1ch" layer will reference four streams (the first two
stereo and the two mono) to encompass six channels, which does not match out
native layout 5.1(side) given that FC and LFE come after FL+FR but before
SL+SR, and here, they are at the end.
For this reason, we need to build Custom order layouts that properly represent
what we're exporting.
----
Before:
Stream group #0:0[0x12c]: IAMF Audio Element:
Layer 0: stereo
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Layer 1: 5.1(side)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Layer 2: 5.1.2
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Layer 3: 5.1.4
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:5[0x5]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
----
AFter:
Stream group #0:0[0x12c]: IAMF Audio Element:
Layer 0: stereo
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Layer 1: 6 channels (FL+FR+SL+SR+FC+LFE)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Layer 2: 8 channels (FL+FR+SL+SR+FC+LFE+TFL+TFR)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Layer 3: 10 channels (FL+FR+SL+SR+FC+LFE+TFL+TFR+TBL+TBR)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:5[0x5]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Signed-off-by: James Almer <jamrial@gmail.com>
In most cases, the channel ids will match the standard Ambisonic Order, saving us the
need to use a custom order layout.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: division by 0
Fixes: 418396712/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-6104388018176000
Fixes: 418478219/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-4569544410857472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the apperture window is bigger than the canvas, then the clap box is invalid
and there's no point calculating cropping values.
Fixes: libavformat/mov.c:1295:14: runtime error: -256 is outside the range of representable values of type 'unsigned long'
Signed-off-by: James Almer <jamrial@gmail.com>
This patch doesn't effect WHIP usage via command, as WHIP always
needs to be explicitly specified
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
In higher versions (openssl 1.0.2 and higher),
the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
so passing a const string doesn't cause an warnings.
However, in lower versions of OpenSSL,
the function signature becomes BIO *BIO_new_mem_buf(void *buf, int len),
which leads to warnings.
OpenSSL guarantees that it will not modify the string,
so it's safe to cast the pem_str to (void *) to avoid this warning.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In sbg_read_header(), if avformat_new_stream() failed, it returns
without cleanup, which may cause memory leaks. Replace return statement
with goto so that we would first clean up then return.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>
The segment_duration must not be set to zero when writing the moov
atom for the second time. This is related to edit lists in standard
MP4 files.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In libavformat/rtmpproto.c:gen_connect(), if check on string length
or check on codec fourcc failed, ff_rtmp_packet_create() allocated
data in pkt would leak. Add ff_rtmp_packet_destory before return error
code.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When seeking on multi-angle titles, libdvdnav does not lock on
to the correct sectors initially as it seeks to find the right NAV packet.
This manifests itself as two bugs:
(1) When seeking on the first angle in a multi-angle segment,
frames from another angle will appear (for example in intro
or credits scenes). This issue is present in VLC also.
(2) When seeking during a segment on angle n+1, the demuxer
cannot deduce the right position from dvdnav and does not allow
seeking within the segment (due to it maintaining a strict state).
Correct the issue by switching to angle 1 before doing the seek
operation, and skipping 3 VOBUs (NAV packet led segments) ahead
where dvdnav will have positioned itself correctly.
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Marth64 <marth64@proxyid.net>
Just applying some UX polish.
This is to match the lowercase trend of attributes in
the dump string (and similar to chapters).
Signed-off-by: Marth64 <marth64@proxyid.net>
Change delta_timestamp to int32_t and add explicit cast to handle
RTP timestamp wraparound correctly. This fixes implementation-defined
behavior when computing negative timestamp differences due to 32-bit
wraparound.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rtp_set_prft() function incorrectly calculates the timestamp delta
when RTP timestamps wrap around the 32-bit boundary. The current code:
delta_timestamp = (int64_t)timestamp - (int64_t)s->last_rtcp_timestamp;
treats both timestamps as large positive values, causing wraparound to
produce a large negative delta instead of the correct small positive delta.
For example, with a 90kHz video clock:
- last_rtcp_timestamp = 0xFFFFFF00 (near wraparound)
- timestamp = 0x00000100 (after wraparound)
- Current result: delta ≈ -4.3 billion ticks ≈ -47,721 seconds
- Expected result: delta ≈ +512 ticks ≈ +0.006 seconds
This causes prft->wallclock to jump backward by approximately:
- 90kHz video: ~47,721 seconds (~13.25 hours)
- 48kHz audio: ~89,478 seconds (~24.9 hours)
- 8kHz audio: ~536,871 seconds (~6.2 days)
Fix by casting the subtraction result to int32_t, which correctly
handles wraparound through modular arithmetic:
delta_timestamp = (int32_t)(timestamp - s->last_rtcp_timestamp);
This ensures the delta is always in the range [-2^31, 2^31-1], making
wraparound produce the correct small positive values.
Fixes timing jumps in applications that rely on Producer Reference Time
for media synchronization.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows detecting changes and regressions in side data related code, same as what
framecrc does for before already for packet data itself.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Code like FFMIN(MAX_DURATION_BUFFER_SIZE, avio_size(s->pb)) is not safe
as FFMIN() is a macro and avio_size() is thus evaluated multiple
times
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
add the missing data structure pkey in the tls_context
properly set this pkey and free it
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
