I found that the default value is not set for onfail option. I see that there is an attempt to set this value by default inside parse_slave_failure_policy_option. But look at the CONSUME_OPTION macro. If av_dict_get cannot find this option, then this function is not even called.
This is an extension to WAVEFORMATEX used for some AAC streams, defined in the
Windows SDK.
Fixes issue #20887.
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit 7b18eafabd.
That commit added tests that don't work on Windows, and which
also fail in setups with cross/remote testing (with --target-exec
and --target-path).
See https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20876 for more
discussions about issues with that commit.
Fixes: out of array access
No testcase
Found-by: Joshua Rogers <joshua@joshua.hu> with ZeroPath
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The one in dashenc was added in
fe5e6e34c0, while the one in hlsenc
was added later in 0afa171f25. Both
have had various additions on top; merge both implementations
into one shared. (Notable additions in
060e74e2a9,
1cf2f040e3,
a2b1dd0ce3 and
797f0b27c175022d896e46db4ac2873e3e0a70af.)
For H264/avc1, use the implementation from hlsenc (which doesn't
use temporary allocations). For most other codecs, use the
only implementation from whichever had one.
The original dashenc implementation tried to be generic based
on RFC 6381, looking up codec tags in ff_codec_movvideo_tags
or ff_codec_movaudio_tags, and doing specific extra additions
for "mp4a" and "mp4v". In practice, only AV_CODEC_ID_AAC
and AV_CODEC_ID_MPEG4 ever mapped to these; simplify this to
a more straightforward codec id based handling, and merge
with the AAC profile based code from hlsenc.
There's a slight behaviour difference from the old one in
dashenc; if there's no code for a specific codec ID, we previously
just output what we matched from the mov tag tables, but now
we won't output anything. But most commonly used codecs in
DASH should be covered here.
Fixes: out of array access
Fixes: zeropath/off-by-one-one-byte
Found-by: Joshua Rogers <joshua@joshua.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Pico VR adds a '\0' after projection_type (a real C string than
a fourcc). It's not strictly correct, but doesn't affect parsing.
[prji: Projection Information Box]
position = 149574743
size = 17
version = 0
flags = 0x000000
projection_type = rect
Co-Authored-by: Keven Ma
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This makes the final file truly hybrid: Externally the file
is a regular, non-fragmented file, but internally, the fragmented
form also exists un-overwritten.
To make any use of that, first, the fragments need to be muxed in
a position independent form, i.e. with empty_moov+default_base_moof
(or the dash or cmaf meta-flags).
Making use of the fragmented form when the file is finalized is
not entirely obvious though. One can dump the contents of the
single mdat box, and get the fragmented form. (This is a neat
trick, but not something that anybody really is expected to
want to do.)
The main expected use case is accessing fragments in the form of
byte range segments, for e.g. HLS.
Previously, the start of the file would look like this:
- ftyp
- free
- moov
- (moov contents)
After finalizing the file, it would look like this:
- ftyp
- free
- mdat (previously moov)
- (moov contents)
In this form, the size and type of the original moov box were
overwritten, and the original moov contents is just leftover
as unused data in the mdat box.
To avoid this issue, the start of the file now looks like this:
- ftyp
- free
- free
- ftyp
- moov
- (moov contents)
The second, hidden ftyp box inside mdat, would normally never be
seen.
After finalizing, the difference is that the mdat box now is
extended to cover the ftyp and the whole moov including its header
(and all the following fragments).
I.e., the start of the file looks like this:
- ftyp
- free
- mdat
- ftyp
- moov
- (moov contents)
This allows accessing the "ftyp+moov" pair sequentially as such,
with a byte range - this range is untouched when finalizing,
producing the same ftyp+moov pair both while writing, when the
file is fragmented, and after finalizing, when the file is
transformed to non-fragmented externally.
Note; the sequential two "free+free" boxes may look slightly
silly; it could be tempting to make the second one an mdat
from the get-go. However, some players of fragmented mp4 (in
particular, Apple's HLS player) bail out if the initialization
segment contains an mdat box - therefore, use a free box.
It could also be possible to use just one single free box with
8 bytes of padding at the start - but that would require more
changes to the finalization logic.
For a segmenting user of the muxer, the only unclarity is how
to determine the right byte range for the internal ftyp+moov
pair. Currently, this requires parsing the muxer output and skip
past anything up to the start of the non-empty free box.
In the QTFF documentation for udta/"user data atoms", "name" is a
valid entry for "name of object" however it is currently skipped
leading to some missing metadata when copying for some files. This
isn't classified the same as "(C)nam" which is "Title of content"
so they aren't necessarily the same.
The parser API doesn't work with packets, only raw data, so in order for it to
be made aware of new extradata propagated through packet side data we need to
pass it in some other form, namely, replacing the main extradata and ensuring
it will be parsed by restarting the parser.
Signed-off-by: James Almer <jamrial@gmail.com>
Fix the AV1 RTP depacketizer for instances where the OBU elements
did not have their OBU size fields removed according to the
recommendation (SHOULD) of the AV1 RTP specification.
Roger Hardiman courteously reported that the depacketizer doesn't
work correctly for fragmented OBU elements with their OBU size
fields still present and will incorrectly state that the
continuation of such a fragment was unexpected, because the
frag_obu_size field was used as a state and only incremented
when the size field needed to be updated on OBU size field
restoration. This patch solves the slip.
Change-Id: I95af8cc89862e8ecf79aabcf029dd95a20dfd7ad
There seem to be samples with no Video element on video tracks in the wild,
which even if not spec compliant, can be demuxed fine after lavf probes the
stream with a decoder/parser.
Relax the check to allow tracks with no dimensions to work, and also add a
check for strict spec compliance to maintain the current behavior if desired.
Fixes issue #20649.
Signed-off-by: James Almer <jamrial@gmail.com>
The code that attempted to extract origin (4B.02) was put in the wrong
metadata handler and was also read as the wrong integer type. According
ST 377-1 Origin is of type "Position" (Int64) in the Timeline Track, not
a 8 bit unsigned integer in the Sequence.
This is how images encoded with specific transfer function should be
viewed. Image viewers that doesn't support named trc metadata, will
fallback to simple gAMA value and both of those cases should produce the
same image apperance for the viewer.
Fixes: https://github.com/mpv-player/mpv/issues/13438
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add dtls_active flag to specify the dtls role.
Properly set the send key and recv key depends on DTLS role:
As DTLS server, the recv key is client master key plus salt,
the send key is server master key plus salt.
As DTLS client, the recv key is server master key plus salt,
the send key is client master key plus salt.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
If using the delay_moov flag in combination with hybrid_fragment
(which is a potentially problematic combination otherwise - the
ftyp box does end up hidden in the end), then we need to flush
twice to get both the moov box and the first fragment, if the
file is finished before the first fragment is completed.
If samples were available when the moov was written, chunking
for those samples has been done already, which has to be reset
here.
This is the case when not using empty_moov, when the moov box
describes the first fragment - this case was accounted for already.
But if using the delay_moov flag, then those samples also were
available when writing the moov, so chunking for them has already
been done in this case as well.
Therefore, always reset chunking here (it should be harmless to
always do it), and update the comment to clarify the cases
involved here.
Write the moov tag at the end first, before overwriting the mdat size
at the start of the file.
In case writing the final moov box fails (e.g. due to being out
of disk), we haven't broken the initial moov box yet.
Thus if writing stops between these steps, we could end up with
a file with two moov boxes - which arguably is more feasible to
recover from, than from a file with no moov boxes at all.
This reverts commit 301141b576.
cluster[0].dts, pts and frag_info[0].time are already in presentation
timeline, so they shouldn't be shift by start_pts.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
