Up until now, the HLS muxer uses av_strtok() to split an input string
controlling parameters of the VariantStreams and then duplicates
parts of this string containing parameters such as the language or the
name of the VariantStream. But these parts are proper zero-terminated
strings of their own that are never modified lateron, so one can simply
use the substring as-is without creating a copy. This commit implements
this.
The same also happened for the string controlling the closed caption
groups.
Furthermore, add const to indicate that the pointers to these substrings
are not used to modify them and also to indicate that these strings are
not allocated on their own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the HLS muxer duplicated a string for every VariantStream,
although neither the original nor the copies are ever modified. So use
the original directly and stop copying.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The parsing process of the AVOpt-enabled string controlling the mapping
of input streams to variant streams is roughly as follows: Space and tab
separate variant stream group maps while the entries in each variant
stream group map are separated by ','.
The parsing process of each variant stream group proceeded as follows:
At first the number of occurences of "a:", "v:" and "s:" in each variant
stream group is calculated so that one can can allocate an array of
streams with this number of entries. Then the string is split along ','
and each substring is parsed. If such a substring starts with "a:", "s:"
or "v:" it is treated as stream specifier and (if there is a correct
number after ':') a stream of the variant stream is mapped to one of the
actual input streams.
Nothing actually guarantees that the number of streams allocated initially
equals the number of streams that are mapped to an actual input stream.
These numbers can differ if e.g. the name, the sgroup, agroup or ccgroup
of the variant stream contain "a:", "s:" or "v:".
The problem hereby is that the rest of the code presumes these numbers
to be equal and segfaults if it isn't (because the corresponding input
stream is NULL).
This commit fixes this by modifying the initial counting process to only
count occurences of "a:", "s:" or "v:" that are at the beginning or that
immediately follow a ','.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For every variantstream vs, vs->packets_written is set to one, only to be
set to zero a few lines below. Given that the relevant structure has
been zeroed during the allocation, this commit removes both assignments.
A redundant initialization for vs->init_range_length has been removed as
well a few lines below. Given that the relevant structure has been
zeroed during the allocation, this commit removes both assignments. A
redundant initialization for vs->init_range_length has been removed as
well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Mainly includes reindentation and returning directly (i.e. without
a goto fail when possible).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
hls_init() would at first allocate the vtt_basename string, then
allocate the vtt_m3u8_name string followed by several operations that
may fail and then open the subtitles' output context. Yet upon freeing,
these strings were only freed when the subtitles' output context
existed, ensuring that they leak if something goes wrong between their
allocation and the opening of the subtitles' output context. So drop the
check for whether this output context exists.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This fixes memleaks in instances such as:
a) When an allocation fails at one of the two places in hls_init() where
the error is returned immediately without goto fail first.
b) When an error happens when writing the header.
c) When an allocation fails at one of the three places in
hls_write_trailer() where the error is returned immediately without goto
fail first.
d) When one decides not to write the trailer at all (e.g. because of
errors when writing packets).
Furthermore, it removes code duplication and allows to return
immediately, without goto fail first.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several variables which are only used when the HLS_SINGLE_FILE flag is
unset have been set even when this flag is set. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat_alloc_output_context2() already sets the oformat member, so
that there is no reason to overwrite it again with the value it already
has.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mapping of streams to the various variant streams to be created by
the HLS muxer is roughly as follows: Space and tab separate variant
stream group maps while the entries in each variant stream group map are
separated by ','.
The parsing process of each variant stream group proceeded as follows:
At first the number of occurences of "a:", "v:" and "s:" in each variant
stream group is calculated so that one can can allocate an array of
streams with this number of entries. Then each entry is checked and the
check for stream numbers was deficient: It did check that there is a
number beginning after the ":", but it did not check that the number
extends until the next "," (or until the end).
This means that an invalid variant stream group like v:0_v:1 will not be
rejected; the problem is that the variant stream in this example is
supposed to have two streams associated with it (because it contains two
"v:"), yet only one stream is actually associated with it (because there
is no ',' to start a second stream specifier). This discrepancy led to
segfaults (null pointer dereferencing) in the rest of the code (when the
nonexistent second stream associated to the variant stream was inspected).
Furthermore, this commit also removes an instance of using atoi() whose
behaviour on a range error is undefined.
Fixes ticket #8652.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
fix ticket: 8651
because the init fragment mp4 file name is without base url name,
so just modify it use the full url which splice after init function.
Tested-by: matclayton
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
This patch adds possibility to use 'periodic-rekey' option with
multi-variant streams to hlsenc muxer. All streams variants
use parameters from the same key_info_file.
There are 2 sets of encryption options that kind of overlaps and add
complexity, so I tried to do the thing without changing too much code.
There is a little duplication of the key_file, key_uri, iv_string, etc
in the VariantStream since we copy it from hls to each variant stream,
but generally all the code remains the same to minimise appearing
of unexpected bugs. Refactoring could be done as a separate patch then as needed.
Signed-off-by: Yaroslav Pogrebnyak <yyyaroslav@gmail.com>
segment duration is using vs duration which compute by frame per second,
that can not fix problem of VFR video stream, so compute the duration
when split the segment, set the segment target duration use
current packet pts minus the prev segment end pts..
Reported-by: Zhao Jun <barryjzhao@tencent.com>
Reviewed-by: Zhao Jun <barryjzhao@tencent.com>
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
Sequence numbers of segments should be unique, if an encoder is using shorter
than 1 second segments and it is restarted, then future segments will be using
already used sequence numbers if initial sequence number is based on the number
of seconds since epoch and not microseconds.
Signed-off-by: Marton Balint <cus@passwd.hu>
if the directory name of the segments contains "%v".
This memleak is caused by masking the pointer that will eventually
be freed by a variable of the same name in a smaller scope.
Therefore the pointer that gets freed is always NULL when it is
freed and the allocated data leaks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This patch fixes Bug #8469
If x264 baseline profile is used with other profiles,
start_pts will be initialized to audio stream's first pts,
while the duration is calculated based on video stream's pts.
In this patch the start_pts is initialized with the correct stream's first pts.
Signed-off-by: Hongcheng Zhong <sj.hc_Zhong@sjtu.edu.cn>
Reviewed-by: Steven Liu <liuqi05@kuaishou.com>
The default is not to write SDT and PAT periodically, only in the beginning of
every segment. After this patch the user might override this if needed.
Signed-off-by: Marton Balint <cus@passwd.hu>
Currently when hls_enc is active and there are multiple variant stream
outputs, default key file url construction does not work, because it is
based on the FormatContext' url field. But in case of multiple variant
streams, it contains the variant m3u8 output playlist url that contains
the %v placeholder. So the result key file url will hold the %v
placeholder causing run time error message about "could not write the
key file".
This patch correct this behaviour, and use the master playlist url for
constructing the output key file url when master playlist is vailable.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
When program_date_time flag is present, in m3u8 playlist file each
segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The intial
program-date-time value is the actual current time at init and
each new segment increments this value by its duration. When append_list
flags is also present, existing playlist parsing by hls_append_segment
treats existing segments as new segments regarding the program-date-time
calculation. But it should not do that, because this way all real the
new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously
by the sum duration of existing segments. Instead it should have
decremented the initial program-date-time value by its duration. This
would ensure that
the first new segment's program-date-time value had the current time as
it is expected.
This patch corrects this behaviour and prevent existing segments to
increment the value of initial_prog_date_time variable but decrements
it.
Reviewed-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
fix ticket: 8461
there is no problem before commit 75aea52a10
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
When a parameter like e.g. language is contained more than once in the
part of var_stream_map pertaining to a single VariantStream, the later
one just overwrites the pointer to the earlier one, leading to a
memleak. This commit changes this by handling the situation gracefully:
The earlier string is silently freed first, so that the last one wins.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
"If an error is detected, localtime_r() shall return a null pointer
and set errno to indicate the error." Yet in case this happened in
hls_init(), AVERROR(ENOMEM) has been returned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
The hls muxer allocates an array of VariantStreams, a structure that
contains pointers to objects that need to be freed on their own. This
means that the number of allocated VariantStreams needs to be correct
when they are freed; yet the number of VariantStreams is set in
update_variant_stream_info() resp. parse_variant_stream_mapstring()
before the allocation has been checked for success, so that upon error
an attempt would be made to free the objects whose pointers are
positioned at position NULL (the location of VariantStreams) +
offsetof(VariantStream, the corresponding pointer).
Furthermore d1fe1344 added another possibility for the first function
to leave an inconsistent state behind: If an allocation of one of the
objects referenced by the VariantStream fails, the VariantStream will be
freed, but the number of allocated VariantStreams isn't reset, leading
to the same problem as above. (This was done in the mistaken belief that
the VariantStreams array would leak otherwise.)
Essentially the same also happens for the number of cc-streams. It has
been fixed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
Under certain circumstances hls_write_packet() would add options to an
AVDictionary. Said dictionary was never explicitly freed, instead it was
presumed that these options would be consumed when opening a new
IO-context. This left several possibilities for memleaks:
a) When no new IO-context would be opened at all. This is possible when
using both the flags temp_file and single_file together with a file
output.
b) When an error happens before one actually tries to open the new
IO-context.
c) When the new IO-context does not consume all options.
All three have been fixed; furthermore, the AVDictionary has been put
into a smaller scope (namely the only part of hls_write_packet() where
it is actually used).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
hls_mux_init() currently leaks an AVDictionary if opening a dynamic
buffer fails or if avformat_init_output fails. This has been fixed by
moving the initialization resp. the freeing of the dictionary around:
In the former case to a place after opening the dynamic buffer, in the
latter to a place before the check for initialization failure so that it
is done unconditionally.
Furthermore, the dictionary is now only copied and freed if the options
in it are actually used (namely when in SEGMENT_TYPE_FMP4 mode).
Finally, a similar situation in hls_start() has been fixed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
hls_init() would allocate a buffer, although it is only needed in one of
two branches that follow. This commit moves the allocation to the branch
that actually needs the buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
