It is not entirely clear what would prevent such overflow so even if it is
not possible, it is better to use 64bit
Fixes: CID1491898 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's meant to override any codec specific (but still container level)
information, but its position is not guaranteed, so apply the values after the
entire trak structure has been parsed.
Also, replace the ugly roundabout int -> double -> int method to set SAR from
existing dimensions while at it.
Signed-off-by: James Almer <jamrial@gmail.com>
And av_stream_get_codec_timebase().
They were both added for ffmpeg CLI, which no longer calls either of
them. Furthermore the notion of "internal stream timing info" that needs
to be transferred with a special magic API function is fundamentally
flawed and should be removed.
Use the already available AVCodecParameters pointer instead.
Shortens lines.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The check "left >= INT_MAX - right" is supposed to check for
whether left + right does not overflow/wraparound, but given that
left and top are uint32_t INT_MAX - right can already wraparound
for big values of right (and ordinary 32-bit ints):
If right == UINT32_MAX, INT_MAX - right is INT_MAX + 1;
for left in 0..par->width both checks will be passed.
Fix this and simplify the check by using 64-bit types,
where the addition is guaranteed not to overflow.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: CID1551679 Data race condition
Fixes: CID1551687 Data race condition
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found while reviewing CID1452449 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It seems reply1 is initialized by ff_rtsp_send_cmd() in most cases but there
are code paths like "continue" which look like they could skip it but even if not
writing this so a complex loop after several layers of calls initialized a local
variable through a pointer is just bad design.
This patch simply initialized the variable.
Fixes: CID1473532 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found while reviewing CID1473532 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This lets us detect when a container has flagged a stream as multilayer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Previously, the bitrate advertised in the master playlist would only
be based on the nominal values in either AVCodecParameters bit_rate,
or via AVCPBProperties max_bitrate. On top of this, a
fudge factor of 10% is added, to account for container overhead.
Neither of these bitrates may be known, and if the encoder is
running in VBR mode, there is no such value to be known. And
the container overhead may be more or less than the given
constant factor of 10%.
Instead, calculate the maximum bitrate per segment based on
what actually gets output from the muxer, and average bitrate
across all segments.
When muxing of the file finishes, update the master playlist
with these values, exposing both the maximum (which previously
was a guesstimate based on the nominal values) via
EXT-X-STREAM-INF BANDWIDTH, and the average via
EXT-X-STREAM-INF AVERAGE-BANDWIDTH.
This makes it possible to use the hlsenc muxer with VBR
encodes, for VOD style muxing.
Signed-off-by: Martin Storsjö <martin@martin.st>
This matches what is done in the corresponding case for
HLS_SINGLE_FILE.
Normally, vs->size is already initialized correctly - but when
writing the initial segment, with mp4 files, vs->size has been set
to the size of the init segment, while range_length contains the
real size of the first segment.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, vs->start_pos was never 0 here, unless using the
-hls_segment_size option, which wasn't allowed for SEGMENT_TYPE_FMP4.
Therefore, this if statement was practically always taken anyway.
Remove this bogus if statement, to allow changing vs->start_pos
to reflect the right value when not using the -hls_segment_size
option.
Signed-off-by: Martin Storsjö <martin@martin.st>
When not using HLS_SINGLE_FILE or hls_segment_size, we're writing
each segment into a separate file. In that case, the file start pos for
each segment will be zero.
This matches the case in (hls->max_seg_size > 0) above, where we
decide to switch to a new file.
This fixes the calculation of "vs->size = new_start_pos - vs->start_pos"
at the start of hls_write_packet; previously, start_pos would
refer to the byte size of the previous segment file, giving
vs->size entirely bogus values here.
Signed-off-by: Martin Storsjö <martin@martin.st>
Both the read_byte variable (which is accumulated into
append_single_file) and the return value are int64_t;
give the ret variable the right corresponding type too.
Signed-off-by: Martin Storsjö <martin@martin.st>
I am not sure the case described by coverity is possible
but its more robust checking the argument first
Fixes: CID1598441 Improper use of negative value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Michael Niedermayer
James Almer
Anton Khirnov
Andreas Rheinhardt
Derek Buitenhuis
Marth64
Martin Storsjö