Assemble it already in caf_write_packet(). This has the advantage
of reducing the amount of buffers used; it also allows to avoid
a seek when writing the trailer and avoids function call overhead
(for the avio_w8(); it also reduces codesize).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array read
Fixes: VULN-6/poc.raw
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access if a filter-graph is used the injects changing dimensions
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reset `sc->stsd_count` before parsing entries. This number doesn't get
reset, which means that multiple parse passes can increment it past the
`sc->extradata` array end and cause OOB writes.
Abort earlier if subblock durations are inconsistent with their containing block,
and ensure each subblock duration is at least 1.
Signed-off-by: James Almer <jamrial@gmail.com>
Abort earlier if subblock durations are inconsistent with their containing block,
and ensure each subblock duration is at least 1.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: use of uninitialized memory
Fixes: 471771529/clusterfuzz-testcase-minimized-ffmpeg_dem_SCD_fuzzer-5328203515494400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sometimes, HTTP sources require a lot of seeking during probing / header
parsing (especially for formats like MXF). Currently, we need to completely
tear down and re-establish the connection most times this happens, which puts
a lot of stress on the network stack and also results in transmission of
possibly many unnecessary bytes.
This patch adds an option to allow FFmpeg to request partial ranges during
the initialization stage. This is done until the initial request size is fully
read, after which we fall back to the normal behavior (i.e. infinite streaming
via an unbounded request).
The usefulness of this is limited without also specifying -multiple_requests 1,
since otherwise there is little point to requesting partial ranges to begin
with. (However, it is semantically independent, so we keep it that way.)
When the previous reply was a partial response (e.g. due to a seek to the
end of the file), and the remaining data from that partial response is
below the short seek size threshold, we can serve this seek by just draining
that data and re-using the existing connection.
This can currently only happen when using keep-alive connections
(-multiple_requests 1) and seeking from the end of the file to somewhere
else, in which case the file's tail can be drained and the connection re-used.
Under other circumstances, however, we still need to force a reconnection,
because we do not yet send partial range requests. (This will be changed in the
following commit)
We need to take special care not to regress the existing fallback logic
for when `http_open_cnx` fails, so here is a quick case analysis:
non-drain path:
- identical to the current
soft drain fails: (ffurl_read error path)
- s->hd = old_hd = NULL
- http_open_cnx() always opens a new connection
- on failure, old buffer is restored and s->hd remains NULL
soft drain succeeds, http_open_cnx() fails:
- s->hd is set to NULL by http_open_cnx() failure path
- old_hd was never set, so remains NULL
- old buffer is restored, s->hd remains NULL
In either case, the outcome that any (previously valid) buffer is left as-is,
the offset is unchanged, and the connection ends up closed (s->hd == NULL).
This is okay to do after the previous change to http_buf_read, which allows
it to internally re-open the connection if needed.
If the Content-Range indicates a smaller range than what we expected,
we should send a new request for the remainder before attempting to read
more.
Again, this commit is theoretically non-functional on its own, since any
conforming HTTP server should give us the entire range we asked for in the
first place, but it is semantically independent from and prepares us for the
following changes.
This could conceivably happen currently if the user tries reading more
bytes after the last chunk has already been received. In this case,
we currently segfault - but simply returning AVERROR(EIO) seems more
reasonable and lets the higher end retry the connection in this case.
In the event that the range returned is smaller than the true filesize, we
should only expect to receive that many bytes - not the entire rest of the
file.
This commit is theoretically non-functional on its own, since any conforming
HTTP server will always return us the full file range, but I wanted to split
it off from the subsequent changes in order to make review easier.
This fails to consider the case of whence == SEEK_END and the resulting
offset happening to exactly match the current position.
Reorder the check to compute the target position first, then compare.
This avoids avpriv functions from lavc/opus/parse.c
(which parse way more than we need, necessitating
parsing the extradata).
It furthermore makes the output of the muxer consistent,
i.e. no longer depending upon whether the Opus parser
or decoder are enabled (the avpriv functions would just
return AVERROR(ENOSYS)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch, the last packet in the affected fate test would be written
without a BlockDuration element despite the packet's duration being shorter
than the Opus frame size.
Signed-off-by: James Almer <jamrial@gmail.com>
Following up on b613eebe78, if a demuxer that exports complete frames sets a
duration, don't overwrite it from the output of the parser.
Signed-off-by: James Almer <jamrial@gmail.com>
We did check video codecs but not audio
Fixes: Assertion failure (on codec_id) in parser.c
Fixes: 472097507/clusterfuzz-testcase-minimized-ffmpeg_dem_LIVE_FLV_fuzzer-6016386662203392
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Was inadvertently broken in the switch to ffio_read_size().
Fixes: 6dd83fab44
PR: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21650
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Fix#20712
When print_sdp() fails during rtp streaming, sch_start()
returns error code without calling wirte_trailer, causing
a memory leak.
The avformat_free_context() will call the mux->deinit, so
we should add a rtp_deinit() to free all internal allocations.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
(This also fixes a symbol name collision with libssh,
which has a nonstatic function called md5.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We're not writing a kuki chunk because its contents for Opus are currently
unknown, so it's best if we don't allow the creation of non spec compliant
files.
Signed-off-by: James Almer <jamrial@gmail.com>
Given the contents of the Opus kuki are not fully clear, generate it
using know values from the desc and pakt chunks.
Signed-off-by: James Almer <jamrial@gmail.com>
caf_write_deinit() would segfault if the CAFStreamContext
couldn't be allocated. Fix this by moving everything from
CAFStreamContext to the ordinary CAFContext; the separation
doesn't make sense for a format with only one stream anyway
and removing it also avoids an indirection.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If a codec has fixed block_align and frame_size but a given sample has either
priming or remainder frames, a pakt chunk can be written declaring zero packets
and no table, reporting only the samples to be discarded.
Signed-off-by: James Almer <jamrial@gmail.com>
