@availabilityStartTime specifies the anchor for the computation of the earliest
availability time (in UTC) for any Segment in the Media Presentation.
As per this requirement, the @AvailabilityStartTime should be set to the
wallclock time at which the first frame of the first segment begins encoding.
But, it was getting set only when the first segment was completely ready. Making
the required correction in this patch. This correction is mainly needed to reduce
the latency in live streaming use cases.
Calling 'write_manifest' from 'write_header' was causing creation of
first MPD with invalid values. Ex: zero @duration param value. Also,
the manifest files (MPD or M3U8s) should be created when at-least
one media frame is ready for consumption.
When use_template is enabled and use_timeline is disabled, typically
it is required to generate the segments at the configured segment duration
rate on an average. This commit is particularly needed to handle the
segmentation when video frame rates are fractional like 29.97 or 59.94 fps.
There are use cases where average segment duration needs to be configured
and muxer is expected to maintain the average segment duration. So, using
the name 'min_seg_duration' will be misleading. So, changing the parameter
name to 'seg_duration', where it can be minimum segment duration or average
segment duration based on the use-case. The additional updates needed for
this functinality are made the sub-sequent patches of this patch series.
The HLSContext struct contains fields which duplicate the data stored in the
avio_opts field. This change removes those fields in favor of avio_opts, and
updates the code accordingly.
The original patch caused the buffer pointed to by new_cookies in open_url to be
leaked. The only thing that buffer is used for is to store the value until it
can be passed to av_dict_set. To fix the leak, v2 of the patch simply calls
av_dict_set with the AV_DICT_DONT_STRDUP_VAL flag, so that the dictionary takes
ownership of the memory instead of copying it again.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Richard Shaffer <rshaffer@tunein.com>
The rw_timeout option is currently not applied when opening media playlist,
segment, or encryption key URLs. This can cause the HLS demuxer to block
indefinitely, even when the rw_timeout option has been specified. This change
simply enables carrying over the rw_timeout option when the demuxer opens these
URLs.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Richard Shaffer <rshaffer@tunein.com>
The rw_timeout option is currently not applied when opening media playlist,
segment, or encryption key URLs. This can cause the HLS demuxer to block
indefinitely, even when the rw_timeout option has been specified. This change
simply enables carrying over the rw_timeout option when the demuxer opens these
URLs.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Richard Shaffer <rshaffer@tunein.com>
This prevents creating potentially broken files, as both the AV1 and
the AV1 in ISOMBFF specs are unfinished.
Signed-off-by: James Almer <jamrial@gmail.com>
and refine the warning message when use both hls_key_info_file and hls_enc
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
If the parser returns full frames, then the output pointer retured by
av_parser_parse2() is guaranteed to point to data contained in the
input packet's buffer.
Create a new reference to said buffer in that case, to avoid
unnecessary data copy when queueing the packet later in the function.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: runtime error: signed integer overflow: 18133149658382192 - -9223090561878065151 cannot be represented in type 'long long'
Fixes: crbug 831552
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: crbug 829153
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In some cases, mainly working with multiprogram mpeg-ts containers as
input, it would be handy to select sub stream of a specific program by
their metadata.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream metadata.
Examples:
p:601:m:language:hun will select all sub streams of program with id 601
where sub streams have metadata key named 'language' with value 'hun'.
p:602:m:guide will select all sub streams of program with id 602 where
sub streams have metadata key named 'guide'.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When using hls_list_size with hls_flags delete_segments, currently
hls_list_size * 2 +- segments remain on disk. With this new option,
the amount of disk space used can be controlled by the user.
fix ticket: #7131
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Fixes: crbug 822705
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently when specifying the program id you can only decide to select
all stream of the specified program (e.g. p:103 will select all streams
of program 103) or narrow the selection to a specific stream sub index
(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
specify like all audio streams of program 145 or 3rd video stream of
program 311.
In some case, mainly working with multiprogram mpeg-ts containers as
input, this feature would be handy.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream type and optionally its
index. Handled types: a, v, s, d.
Examples: p:601:a will select all audio streams of program 601,
p:603:a:1 will select 2nd audio streams of program 603,
p:604:v:0 will select first video stream of program 604.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some ADTS streams can have multiple ID3 tags between frames. This
change parses all of them, rather than just the first one.
Signed-off-by: Mattias Amnefelt <mattiasa@avm.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Such streams are found on Blu-ray, and identified as EAC3 type in
avformat, while the bitstream of the core stream is actually a pure AC3
frame.
Adjust the parsing accordingly, since AC3 frames always hold 6 blocks
and the numblkscod syntax element is not present.
When var_stream_map option is used, %v must appear either in segment
name template or in the directory path. This latter case currently is
not handled and delete_segments flag of hls_flags is broken now. This
patch fix this. The root cause of the bug was that HLSSegment struct
only stores the final filename part, but not the final directory path.
Most of the cases, final path info is unneded, It only necessary when
you want to delete old segments (e.g in case of live streaming).
Without variant streams it was unnecessary to store the final directory
path, because all segment were stored into the same directory. But
introducing %v in directory names either require to store the final
directory path into HLSSegment or associate segments with their variant
streams to be able deleting them later. I have choosen the second
solution and introduced a variant index data member into the segment
struct.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@onvideo.cn>
Support for writing copyright metadata was added in commit bed4fc54c9
for 3GP, MOV and iTunes metadata. 3GP and MOV cases are formally
specified. However, iTunes format does not have specification, and
it seems to have been assumed that it would use the same atom as
MOV (both being Apple formats).
However, Apple uses 'cprt' atom for iTunes metadata (do note that
the iTunes 'cprt' encoding is generic iTunes ItemList atom, not
the 3GP 'cprt' encoding. These are also inside different parent
atoms).
Most references trying to document iTunes atoms mention only
the 'cprt' tag. See:
- http://atomicparsley.sourceforge.net/mpeg-4files.html
- http://mutagen.readthedocs.io/en/latest/api/mp4.html
Same applies to other software supporting this tag. Most of them
encode and decode only the 'cprt' atom.
ffmpeg mov demuxer supports both atoms in this context. There are
few pieces of other software that support similarly both 'cprt' and
the incorrect '\251cpy' atom in this context. I believe they do it in
order to read the ffmpeg encoded incorrect copyright atom.
In light of the above this changes the copyright atom to 'cprt' as
it seems to be supported univerally and is the correct atom to use.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Newly allocated data buffers (wavpack, prores, compressed buffers)
are padded to meet the requirements of AVPacket.
About 10x speed up in matroska_parse_frame().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Simplifies code in matroska_parse_frame(). This is in preparation for
the following patch.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Data in EbmlBin objects is never changed after being read from the
input file (save for two specific cases with encoded CodePrivate), so
using AVBufferRef we can prevent unnecessary copy of data by instead
creating new references to said constant data.
Signed-off-by: James Almer <jamrial@gmail.com>
This is shared test and this simplifies code a bit. Follow up
commit will have additional tests for this function.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Vishwanath Dixit
Richard Shaffer
sanilraut
Steven Liu
James Almer
Rodger Combs
Michael Niedermayer
Bela Bodecs
Jun Zhao
Mattias Amnefelt
Hendrik Leppkes
Timo Teräs
Misty De Meo
Carl Eugen Hoyos
Jacob Trimble