This adds the ability to have a stored reply, needed for the
SET_PARAMETERS command feature to reliably report the reply even
while intermediate packets are read.
Fixes the behavior when calling ff_rtsp_read_reply again after it
was called at another place with return_on_interleaved_data set to
true. Before, it would result in completely corrupting the internal
state as the $ interleaved packet marker would have already been read
which the next run of ff_rtsp_read_reply would look for but never find
it, trying to read packet data as RTSP message.
This new API adds the ability to send commands to the demuxer and also
receive replies to these commands.
It is useful in cases like the RTSP demuxer, where it might be desirable
for the API user to send commands like SET_PARAMETER or PLAY and PAUSE.
Sending and receiving are decoupled, as to not require waiting for a
reply when sending, as with some demuxers and depending on the command
it could be necessary to process further packets in the meantime
before requesting a reply.
Loading CA certificate is supported.
Remove unrelated comments.
The underlying socket can be tcp or udp.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
This function just calculate and copy the fingerprint
to the provided buf, will not allocate memory.
It fails when the input (such as cert) is invalid.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
Fixes: negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long'); cast to an unsigned type to negate this value to itself
Fixes: 471604230/clusterfuzz-testcase-minimized-ffmpeg_dem_LRC_fuzzer-5474264750030848
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AlphaMode should indicate whether the BlockAdditional Element with BlockAddID
of "1" contains Alpha data, as defined by to the Codec Mapping for the `CodecID`.
Only VP8 and VP9 Codec Mappings define this, so writing it for all codecs with
a pixel format of YUVA420P, or for codecs other than VP8/VP9 (if the alpha_mode
metadata entry was set) was wrong.
Signed-off-by: Marton Balint <cus@passwd.hu>
Don't just export initial_padding, but also take it into account for timestamps
by adjusting the stream's start_time. Also, export the padding samples in a way
that's actually supported, as currently trailing_padding is unused so no user
will look at it.
For the sake of not reducing coverage and because the lossy tests have reference
files that contain the priming samples, add the skip_manual flags2 to the tests
so we still output them. A new ffprobe call will ensure the demuxer behavior is
tested too.
Signed-off-by: James Almer <jamrial@gmail.com>
Sockets of type SOCK_DGRAM don't support listen(), so it was
impossible to read from "unixgram" sockets in ffmpeg.
Signed-off-by: Rost Kurylo <rost.kurylo@netint.ca>
Add support for decoding 42ni and 23ni in mov/mp4.
Note that in24/in32 can be either LE or BE thanks to enda atom,
so this patch leaves the muxer unchanged.
Fixes#21445.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
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>
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>
