The tag comes from samples/ffmpeg/mov/unrecognized/bartjones.mov
really looks like some random data. Now the random tag matched
another file, which isn't a mov.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Animated JPEG XL files requires a separate demuxer than image2, because
the timebase information is set by the demuxer. Should the timebase of
an animated JPEG XL file be incompatible with the timebase set by the
image2pipe demuxer (usually 1/25 unless set otherwise), rescaling will
fail. Adding a separate demuxer for animated JPEG XL files allows the
timebase to be set correctly.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Fixes: signed integer overflow: 9079256848778919936 - -288230376151711746 cannot be represented in type 'long'
Fixes: 58248/clusterfuzz-testcase-minimized-ffmpeg_dem_OGG_fuzzer-6326851353313280
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check init_get_bits' result for NULL, to avoid dereferencing a NULL
pointer later (CWE-476).
Without this, a segfault happens when trying to decode a handcrafted
ogg-flac file with an absurdly long (e.g. 268435455 bytes) ogg header.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul Arzelier <paul.arzelier@free.fr>
Fixes: signed integer overflow: -9223372036854775808 - 2082844800 cannot be represented in type 'long'
Fixes: 58384/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6428383700713472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should be a few nano seconds faster (not measureable)
But Collectively the whole humankind watching hls will safe a minute
Found-by: Leo Izen
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The demuxer exports rawvideo, so there's no reason for the muxer to only
work with wrapped_avframe.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
H.264 and mpeg12 parsers need to be adjusted at the same time to stop
using the value of AVCodecContext.ticks_per_frame, because it is not set
correctly unless the codec has been opened. Previously this would result
in both the parser and lavf seeing the same incorrect value, which would
cancel out.
Updating lavf and not the parsers would result in correct value in lavf,
but the wrong one in parsers, which would break some tests.
This should fix the regression since 6b1f68ccb04d791f0250e05687c346a99ff47ea1
Should fix Ticket10353 (please test and report cases that still fail)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch simply recognizes the AAC audio track during
decode -- it does not add functionality to encode AAC in
MXF.
Signed-off-by: Ammon Riley <ammon.riley@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Its unexpected that a .avi or other "standard" file turns into a playlist.
The goal of this patch is to avoid this unexpected behavior and possible
privacy or security differences.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
One that is fine enough to represent all DV audio sample rates. Audio
packet durations are now sample-accurate.
This largely undoes commit 76fbb0052df471075858c1cb82b04c8be7adba8d. To
avoid breaking the issue fixed by that commit, resync audio timestamps
against video if they get more than one frame apart. The sample from
issue #8762 still works correctly after this commit.
Slightly changes the results of the lavf-dv seektest, due to the audio
timebase being more granular.
Current code will call avpriv_set_pts_info() for each video frame,
possibly setting a different timebase if the stream framerate changes.
This violates API conventions, as the timebase is supposed to stay
constant after stream creation.
Change the demuxer to set a single timebase that is fine enough to
handle all supported DV framerates.
The seek tests change slightly because the new timebase is more
granular.
This was a bug/mistake in dae3679a9bfa421829ef9049ae2167089a2fdef7.
use_mfra_for by defintion only has an effect on fragmented MP4 files,
making the check not only redundant, but also broken if a user used
the option globally (i.e. set on non-fragmented MP4s).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Also make duration check for mvhd more consistent with the others, write
version 1 of mvhd if duration is at least INT32_MAX instead of UINT32_MAX.
Signed-off-by: Marton Balint <cus@passwd.hu>
