the init.mp4 can be expanded with strftime the same way as
hls_segment_filename.
Signed-off-by: Nikola Pajkovsky <nikola@pajkovsky.cz>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
fix ticket: 8989
This is is due to the following behavior in the current code:
1. The initial_prog_date_time gets set to the current local time
2. The existing playlist (.m3u8) file gets parsed and the segments
present are added to the variant stream
3. The new segment is created and added
4. The existing segments and the new segment are written to the
playlist file. The initial_prog_date_time from point 1 is used
for calculating "#EXT-X-PROGRAM-DATE-TIME" for the segments,
which results in incorrect "#EXT-X-PROGRAM-DATE-TIME" values
for existing segments
The following approach fixes this bug:
1. Add a new variable "discont_program_date_time" of type double
to HLSSegment struct
2. Store the "EXT-X-PROGRAM-DATE-TIME" value from the existing
segments in this variable
3. When writing to playlist file if "discont_program_date_time"
is set, then use that value for "EXT-X-PROGRAM-DATE-TIME" else
use the value present in vs->initial_prog_date_time
Signed-off-by: Vignesh Ravichandran <vignesh.ravichandran02@gmail.com>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
Create a local one instead from a byte buffer input argument.
This prevents skipping bytes that may belong to another SEI message.
Signed-off-by: James Almer <jamrial@gmail.com>
As this is a meta muxer and the same flag is set with the fifo
meta muxer, there is really no reason not to have this set here
as well.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
The nvidia hardware explicitly supports decoding monochrome content,
presumably for the AVIF alpha channel. Supporting this requires an
adjustment in av1dec and explicit monochrome detection in nvdec.
I'm not sure why the monochrome path in av1dec did what it did - it
seems non-functional - YUV440P doesn't seem a logical pix_fmt for
monochrome and conditioning on chroma sub-sampling doesn't make sense.
So I changed it.
I've tested 8bit content, but I haven't found a way to create a 10bit
sample, so that path is untested for now.
Fixes: signed integer overflow: -2105540608 - 2105540608 cannot be represented in type 'int'
Fixes: 26870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5656647567147008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 175 + 2147483571 cannot be represented in type 'int'
Fixes: 26833/clusterfuzz-testcase-minimized-ffmpeg_dem_IMAGE2_fuzzer-5969501214212096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 46671062 * 100 cannot be represented in type 'int'
Fixes: 26826/clusterfuzz-testcase-minimized-ffmpeg_dem_REALTEXT_fuzzer-5644062910316544
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
By using the frame counter (and the video time base) for audio pts we lose some
timestamp precision but we ensure that video and audio coming from the same DV
frame are always in sync.
This patch also makes timestamps after seek consistent and it should also fix
the timestamps when the audio clock is unlocked and have a completely
indpendent clock source. (E.g. runs on fixed 48009 Hz which should have been
exact 48000 Hz)
Fixes out of sync timestamps in ticket #8762.
Signed-off-by: Marton Balint <cus@passwd.hu>
./ffmpeg -list_devices true -f decklink -i dummy
[Blackmagic DeckLink indev @ 0x2f96d00] The "list_devices" option is deprecated: list available devices
[decklink @ 0x2f96400] The -list_devices option is deprecated and will be removed. Please use ffmpeg -sources decklink instead.
->
[Blackmagic DeckLink indev @ 0x306ed00] The "list_devices" option is deprecated: use ffmpeg -sources decklink instead
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
A reference to an AV1RawFrameHeader and consequently the
AV1RawFrameHeader itself and everything it has a reference to leak
if the hardware has no AV1 decoding capabilities or if some other error
happens. It happens e.g. in the cbs-av1-av1-1-b8-02-allintra FATE-test;
it has just been masked because the return value of ffmpeg (which
indicates failure when using Valgrind or ASAN) is ignored when doing
tests of type md5.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 18 + 9223372036854775799 cannot be represented in type 'long'
Fixes: 26731/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5696846019952640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The image center wasn't preserved, the output image was mirror reversed,
and rotations were made around wrong axes.
I did also remove the vector normalization, because it's sure that the vector
is already normalized if it's calculated from sin() and cos() terms.
This function existed to enable codecs with non-threadsafe init functions
to initialize other codecs despite the fact that normally no two codecs
with non-threadsafe init functions can be initialized at the same time
(there is a mutex guarding this). Yet there are no users of this
function any more as all users have been made thread-safe (switching
away from ff_codec_open2_recursive() was required for this as said
function requires the caller to hold the lock to the mutex guarding the
initializations and this is only true for codecs with the
FF_CODEC_CAP_INIT_THREADSAFE flag unset); so remove it.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the TIFF decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This will allow to make the TIFF decoder's init function thread-safe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the SMV JPEG decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the Cintel RAW decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Normally no two codecs with FF_CODEC_CAP_INIT_THREADSAFE unset
can be initialized at the same time: a mutex in avcodec_open2()
ensures this. This implies that one cannot simply open a codec
with a non-threadsafe init-function from the init function of
a codec whose own init function is not threadsafe either as the child
codec couldn't acquire the lock.
ff_codec_open2_recursive() exists to get around this limitation:
If the init function of the child codec to be initialized is not
thread-safe, the mutex is unlocked, the child is initialized and
the mutex is locked again. This of course has as a prerequisite that
the parent AVCodecContext actually holds the lock, i.e. that the
parent codec's init function is not thread-safe. If it is, then one
can (and has to) just use avcodec_open2() directly (if the child's
init function is not thread-safe, then avcodec_open2() will have to
acquire the mutex itself (and potentially wait for it), so that it is
perfectly fine for an otherwise thread-safe init function to open
a codec with a potentially non-thread-safe init function via
avcodec_open2()).
Yet several of the users of ff_codec_open2_recursive() have the
FF_CODEC_CAP_INIT_THREADSAFE flag set; this only worked because
all the child codecs' init functions were thread-safe themselves
so that ff_codec_open2_recursive() didn't touch the mutex at all.
But of course the real solution to this is to directly use
avcodec_open2().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Nikola Pajkovsky
Vignesh Ravichandran
Paul B Mahol
James Almer
Jan Ekström
Philip Langdale
Michael Niedermayer
Marton Balint
Peter Ross
Lynne
Mohammad Izadi
Thierry Foucu
Limin Wang
Andreas Rheinhardt
Michael Koch