From: Wenbin Chen
Signed-off-by: Wenbin Chen
---
libavfilter/dnn/dnn_backend_tf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index b521de7fbe..e1e8cef0d2 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
From: Wenbin Chen
Dnn models has different data preprocess requirements. Scale and mean
parameters are added to preprocess input data.
Signed-off-by: Wenbin Chen
---
libavfilter/dnn/dnn_backend_openvino.c | 43 --
libavfilter/dnn/dnn_io_proc.c | 82
From: Wenbin Chen
Dnn models have different input layout (NCHW or NHWC), so a
"layout" option is added
Use openvino's API to do layout conversion for input data. Use swscale
to do layout conversion for output data as openvino doesn't have
similiar C API for output.
Signed-off-by: Wenbin Chen
On Di, 2023-09-19 at 20:38 -0400, Neal Gompa wrote:
> On Tue, Sep 19, 2023 at 5:58 PM Lynne wrote:
> >
> > Sep 19, 2023, 21:16 by mich...@niedermayer.cc:
> >
> > > On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> > >
> > > > On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer
On Di, 2023-09-19 at 20:40 -0400, Neal Gompa wrote:
> On Mon, Sep 11, 2023 at 3:52 AM wrote:
> >
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/av1.h | 7 +++
> > libavcodec/cbs_av1_syntax_template.c | 4 ++--
> > 2 files changed, 9
On Mon, Sep 11, 2023 at 3:54 AM wrote:
>
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/tests/.gitignore | 1 +
> libavcodec/tests/av1_levels.c | 126 ++
> tests/fate/libavcodec.mak | 5 ++
> 3 files changed, 132 insertions(+)
>
On Mon, Sep 11, 2023 at 3:53 AM wrote:
>
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> Update:
> 1. use AV_PROFILE* instead of deprecated FF_PROFILE*.
>
> Changelog | 1 +
> configure | 3 +
> doc/encoders.texi | 14 +
>
On Mon, Sep 11, 2023 at 3:54 AM wrote:
>
> From: Fei Wang
>
> To support more reference frames from different directions.
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_encode.c | 112 +---
> libavcodec/vaapi_encode.h | 15 +++--
>
On Mon, Sep 11, 2023 at 3:53 AM wrote:
>
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_encode.c | 65 +++
> 1 file changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>
On Mon, Sep 11, 2023 at 3:53 AM wrote:
>
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_encode.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 0316fe5c18..5ae63c9f25 100644
> ---
On Tue, Sep 19, 2023 at 8:40 PM Neal Gompa wrote:
>
> On Mon, Sep 11, 2023 at 3:52 AM wrote:
> >
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/av1.h | 7 +++
> > libavcodec/cbs_av1_syntax_template.c | 4 ++--
> > 2 files changed, 9
On Mon, Sep 11, 2023 at 3:53 AM wrote:
>
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/cbs_av1.c | 30 +-
> libavcodec/cbs_av1.h | 1 +
> 2 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/cbs_av1.c
On Mon, Sep 11, 2023 at 3:53 AM wrote:
>
> From: Mark Thompson
>
> Turn tracing into callbacks for each syntax element, with default
> callbacks to match current trace_headers behaviour for debug. Move
> the construction of bit strings into the trace callback, which
> simplifies all of the read
On Mon, Sep 11, 2023 at 3:52 AM wrote:
>
> From: Fei Wang
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/av1.h | 7 +++
> libavcodec/cbs_av1_syntax_template.c | 4 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/av1.h
On Tue, Sep 19, 2023 at 5:58 PM Lynne wrote:
>
> Sep 19, 2023, 21:16 by mich...@niedermayer.cc:
>
> > On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> >
> >> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer
> >> wrote:
> >> > Hi all
> >> >
> >> > There was the request to
Fixes: leak
Fixes:
62164/clusterfuzz-testcase-minimized-ffmpeg_dem_AVS_fuzzer-6738814988320768
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/avs.c | 4
1 file changed, 4 insertions(+)
Fixes: leak
Fixes:
62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_fuzzer-6449246523752448
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vlc.c | 1 +
1 file changed, 1
Fixes: mem leak
Fixes:
62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_fuzzer-804266926080
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/utvideodec.c | 8
1
Fixes: signed integer overflow: 4 * 2307917133220067266 cannot be represented
in type 'long'
Fixes:
62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-6307690022043648
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: signed integer overflow: 538976288 - -9223372036854775808 cannot be
represented in type 'long'
Fixes:
62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-6275845531238400
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Sep 19, 2023, 21:16 by mich...@niedermayer.cc:
> On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
>
>> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer
>> wrote:
>> > Hi all
>> >
>> > There was the request to make a 6.1 before end of April
>> > Is that still so ?
>> >
>> >
Avoids implicit av_frame_ref() and therefore allocations
and error checks. It also avoids explicitly allocating
the AVFrames (done implicitly when getting the buffer).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ffv1.c| 1 -
libavcodec/ffv1.h| 4 +--
libavcodec/ffv1dec.c | 83
Avoids implicit av_frame_ref() and therefore allocations
and error checks. It also avoids explicitly allocating
the AVFrames (done implicitly when getting the buffer).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pngdec.c | 64 +++--
1 file changed,
Avoids implicit av_frame_ref() and therefore allocations
and error checks. It also avoids explicitly allocating
the AVFrames (done implicitly when getting the buffer).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_filter.c | 8
libavcodec/hevc_mvs.c| 6 +++---
Only the collocated_ref of the current frame (i.e. HEVCContext.ref)
is ever used*, so move it to HEVCContext directly after ref.
*: This goes so far that collocated_ref was not even synced across
threads in case of frame-threading.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_mvs.c |
Before commit f025b8e110b36c1cdb4fb56c4cd57aeca1767b5b,
every frame-threaded decoder used ThreadFrames, even when
they did not have any inter-frame dependencies at all.
In order to distinguish those decoders that need the AVBuffer
for progress communication from those that do not (to avoid
the
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp8.c | 90 +++
libavcodec/vp8.h | 5 +--
libavcodec/webp.c | 3 +-
3 files changed, 33 insertions(+), 65 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 4a51c551b8..30d22016f5
It is more natural given that WavPack doesn't need the data of
the previous frame at all; it just needs the DSD context.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wavpack.c | 100 +++
1 file changed, 44 insertions(+), 56 deletions(-)
diff --git
The API is very similar by the ProgressFrame API, with the exception
that it no longer has an included AVFrame. Instead one can wait
on anything via a ThreadProgress. One just has to ensure that
the lifetime of the object containing the ThreadProgress is long
enough (the corresponding problem for
This part of the code is not slice-threaded and they are
semantically an initialization, so use atomic_init()
instead of the potentially expensive atomic_store()
(which uses sequentially consistent memory ordering).
Also remove the initial initialization directly after
allocating this array.
ff_thread_progress_replace() can handle a blank ProgressFrame
as src (in which case it simply unreferences dst), but not
a NULL one. So add a blank frame to be used as source for
this case, so that we can use the replace functions
to simplify vp9_frame_replace().
Signed-off-by: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 79c4ae0205..87c507bb36 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1564,14 +1564,15 @@ static int
When outputting a show-existing frame, the VP9 decoder simply
created a reference to said frame and returned it immediately to
the caller, without waiting for it to have finished decoding.
In case of frame-threading it is possible for the frame to
only be decoded while it was waiting to be output.
This already fixes a race in the vp9-encparams test. In this test,
side data is added to the current frame after having been decoded
(and therefore after ff_thread_finish_setup() has been called).
Yet the update_thread_context callback called ff_thread_ref_frame()
and therefore av_frame_ref() with
Avoids implicit av_frame_ref() and therefore allocations
and error checks. It also avoids explicitly allocating
the AVFrames (done implicitly when getting the buffer)
and it also allows to reuse the flushing code for freeing
the ProgressFrames.
Signed-off-by: Andreas Rheinhardt
---
Avoids implicit av_frame_ref() and therefore allocations
and error checks.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mimic.c | 60 --
1 file changed, 21 insertions(+), 39 deletions(-)
diff --git a/libavcodec/mimic.c b/libavcodec/mimic.c
index
Frame-threaded decoders with inter-frame dependencies
use the ThreadFrame API for syncing. It works as follows:
During init each thread allocates an AVFrame for every
ThreadFrame.
Thread A reads the header of its packet and allocates
a buffer for an AVFrame with ff_thread_get_ext_buffer()
(which
This is in preparation for a new ThreadFrame-API
based around RefStruct to allow to pass the AVCodecContext*
to ff_thread_release_buffer().
Signed-off-by: Andreas Rheinhardt
---
Now that thread-unsafe callbacks are no more, one could
also just use av_frame_unref() instead of
Up until now each thread had its own buffer pool for extradata
buffers when using frame-threading. Each thread can have at most
three references to extradata and in the long run, each thread's
bufferpool seems to fill up with three entries. But given
that at any given time there can be at most 2 +
To do this, make FFRefStructPool itself refcounted according
to the RefStruct API.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/refstruct.c | 29 -
libavcodec/refstruct.h | 5 -
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git
Up until now, the VAAPI encoder uses fake data with the
AVBuffer-API: The data pointer does not point to real memory,
but is instead just a VABufferID converted to a pointer.
This has probably been copied from the VAAPI-hwcontext-API
(which presumably does it to avoid allocations).
This commit
It avoids allocations and corresponding error checks.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c | 24 +---
libavcodec/vp9dec.h| 3 +--
libavcodec/vp9shared.h | 2 +-
3 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/libavcodec/vp9.c
This is in preparation for the following commit.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/refstruct.c | 10 ++
libavcodec/refstruct.h | 8
2 files changed, 18 insertions(+)
diff --git a/libavcodec/refstruct.c b/libavcodec/refstruct.c
index 7539b7942e..f8d040874d
It involves less allocations, in particular no allocations
after the entry has been created. Therefore creating a new
reference from an existing one can't fail and therefore
need not be checked. It also avoids indirections and casts.
Also note that nvdec_decoder_frame_init() (the callback
to
It involves less allocations and therefore has the nice property
that deriving a reference from a reference can't fail,
simplifying hevc_ref_frame().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_refs.c | 16 ++--
libavcodec/hevcdec.c | 25 ++---
It involves less allocations and therefore has the nice property
that deriving a reference from a reference can't fail.
This allows for considerable simplifications in
ff_h264_(ref|replace)_picture().
Switching to the RefStruct API also allows to make H264Picture
smaller, because some AVBufferRef*
Very similar to the AVBufferPool API, but with some differences:
1. Reusing an already existing entry does not incur an allocation
at all any more (the AVBufferPool API needs to allocate an AVBufferRef).
2. The tasks done while holding the lock are smaller; e.g.
allocating new entries is now
Avoids allocations and error checks as well as the boilerplate
code for creating an AVBuffer with a custom free callback.
Also increases type safety.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/nvdec.c | 50 ++
libavcodec/nvdec.h | 4 ++--
2
Avoids allocations and error checks and allows to remove
cleanup code for earlier allocations. Also avoids casts
and indirections.
Signed-off-by: Andreas Rheinhardt
---
I actually intend to remove the ThreadFrame API in the not-so
long-term.
libavcodec/h264_mb.c | 4 ++--
Given that the RefStruct API relies on the user to know
the size of the objects and does not provide a way to get it,
we need to store the number of elements allocated ourselves;
but this is actually better than deriving it from the size
in bytes.
Signed-off-by: Andreas Rheinhardt
---
Avoids allocations, error checks and indirections.
Also increases type-safety.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vulkan_av1.c| 2 +-
libavcodec/vulkan_decode.c | 49 --
libavcodec/vulkan_decode.h | 2 +-
libavcodec/vulkan_h264.c | 2 +-
Avoids allocations and therefore error checks: Syncing
hwaccel_picture_private across threads can't fail any more.
Also gets rid of an unnecessary pointer in structures and
in the parameter list of ff_hwaccel_frame_priv_alloc().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/av1dec.c
The SEI message code uses the AVBuffer API for its SEI messages
and contained buffers (like the extension buffer for HEVC
or the user data (un)registered payload buffers).
Contrary to the ordinary CBS code (where some of these
contained buffer references are actually references
to the provided
This avoids allocations and error checks etc. as well
as duplicate pointer lists in the CodedBitstreamFooContexts.
It also avoids casting const away for use as opaque,
as the RefStruct API supports const opaques.
The fact that some of the units are not refcounted
(i.e. they are sometimes part of
This is the analog of av_buffer_is_writable();
it will be used in the next commit.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/refstruct.c | 14 ++
libavcodec/refstruct.h | 9 +
2 files changed, 23 insertions(+)
diff --git a/libavcodec/refstruct.c
It avoids allocations and the corresponding error checks.
Also avoids casts and indirections.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dovi_rpu.c | 54 ++-
libavcodec/dovi_rpu.h | 4 ++--
libavcodec/hevcdec.c | 4 +---
3 files changed, 26
It avoids allocations and the corresponding error checks.
It also avoids indirections and casts.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wavpack.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
Avoids allocations and error checks when syncing the buffers.
Also avoids indirections.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp8.c | 23 +--
libavcodec/vp8.h | 2 +-
2 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/libavcodec/vp8.c
Avoids allocations and error checks for these allocations;
e.g. syncing buffers across threads can't fail any more
and needn't be checked. It also gets rid of casts and
indirections.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_parser.c | 8 ++--
libavcodec/hevc_ps.c | 80
Avoids allocations and error checks for these allocations;
e.g. syncing buffers across threads can't fail any more
and needn't be checked. It also avoids having to keep
H264ParamSets.pps and H264ParamSets.pps_ref and PPS.sps
and PPS.sps_ref in sync and gets rid of casts and indirections.
(The
Avoids allocations and frees and error checks for said allocations;
also avoids a few indirections and casts.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 3 ++-
libavcodec/get_buffer.c| 44 ++
libavcodec/internal.h | 2 +-
For now, this API is supposed to replace all the internal uses
of reference counted objects in libavcodec; "internal" here
means that the object is created in libavcodec and is never
put directly in the hands of anyone outside of it.
It is intended to be made public eventually, but for now
I
>From the documentation of GNU awk [1]:
"In most awk implementations, including gawk, rand() starts generating
numbers from the same starting number, or seed, each time you run awk.45
Thus, a program generates the same results each time you run it. The
numbers are random within one awk run but
This patchset initially grew out of my dissatisfaction with the fact
that the AVBuffer API contains implicit allocations in av_buffer_ref()
that need to be checked. Later this combined with my dissatisfaction
with the current ThreadFrame API (which contains an implicit
av_frame_ref()) which
---
fftools/ffmpeg.c | 26 --
fftools/ffmpeg.h | 8 --
fftools/ffmpeg_mux.c | 184 --
fftools/ffmpeg_mux.h | 14 ++-
fftools/ffmpeg_mux_init.c | 33 +++
fftools/ffmpeg_opt.c | 6 +-
6 files changed, 80
---
fftools/ffmpeg.c | 237 ++-
fftools/ffmpeg.h | 6 --
2 files changed, 10 insertions(+), 233 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e82d88b3e0..f3e150e453 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -137,6
---
fftools/ffmpeg.h| 22 --
fftools/ffmpeg_filter.c | 533
2 files changed, 152 insertions(+), 403 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 841f8d0d68..eb4e8e27a9 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@
---
fftools/ffmpeg.c | 1 -
fftools/ffmpeg.h | 4 +-
fftools/ffmpeg_dec.c | 1 +
fftools/ffmpeg_enc.c | 231 ++
fftools/ffmpeg_mux_init.c | 43 ++-
5 files changed, 45 insertions(+), 235 deletions(-)
diff --git
---
fftools/ffmpeg.c | 9 +--
fftools/ffmpeg.h | 11 ---
fftools/ffmpeg_dec.c | 189 +--
3 files changed, 42 insertions(+), 167 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 00e57c4382..a09a9e1200 100644
---
---
fftools/ffmpeg.c | 2 +-
fftools/ffmpeg.h | 12
fftools/ffmpeg_demux.c | 131 +++--
3 files changed, 60 insertions(+), 85 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 995424ca93..00e57c4382 100644
---
See the comment block at the top of fftools/ffmpeg_sched.h for more
details on what this scheduler is for.
This commit adds the scheduling code itself, along with minimal
integration with the rest of the program:
* allocating and freeing the scheduler
* passing it throughout the call stack in
As for the analogous decoding change, this is only a preparatory step to
a fully threaded architecture and does not yet make encoding truly
parallel. The main thread will currently submit a frame and wait until
it has been fully processed by the encoder before moving on. That will
change in future
It conflicts with threading work.
---
fftools/ffmpeg_enc.c | 2 ++
.../fate/matroska-mastering-display-metadata | 24 ++-
tests/ref/lavf/mpg| 6 ++--
tests/ref/seek/lavf-mpg | 30 +--
4 files
It conflicts with threading work.
---
fftools/ffmpeg.h | 6 +++---
fftools/ffmpeg_dec.c | 4
fftools/ffmpeg_demux.c | 8 +++-
tests/fate/ffmpeg.mak | 12 ++--
4 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index
* the code is made shorter and simpler
* avoids constantly allocating and freeing AVPackets, thanks to
ThreadQueue integration with ObjPool
* is consistent with decoding/filtering/muxing
* reduces the diff in the future switch to thread-aware scheduling
This makes ifile_get_packet() always
It conflicts with threading work.
---
fftools/ffmpeg.c | 2 ++
tests/fate/ffmpeg.mak | 24
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 7d6972f689..e084318864 100644
--- a/fftools/ffmpeg.c
+++
As previously for decoding, this is merely "scaffolding" for moving to a
fully threaded architecture and does not yet make filtering truly
parallel - the main thread will currently wait for the filtering thread
to finish its work before continuing. That will change in future commits
after encoders
To be used for data that never needs to be visible outside of the muxer
thread. Start by moving the muxed AVPacket in there.
---
fftools/ffmpeg_mux.c | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_mux.c
These should be considered serious errors - don't just print a log
message and continue as if nothing happened.
---
fftools/ffmpeg_filter.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index
---
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_enc.c | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 15790d3e0c..0983d026cd 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -817,7 +817,7 @@ int dec_packet(InputStream
Its function is analogous to that of the fps filter, so filtering is a
more appropriate place for this.
The main practical reason for this move is that it places the encoding
sync queue right at the boundary between filters and encoders. This will
be important when switching to threaded
Makes it more clear what state is specific to framerate conversion,
which will be useful in the following commit.
---
fftools/ffmpeg_enc.c | 65
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
Always use the functionality of the latter, which makes more sense as it
avoids losing keyframes due to vsync code dropping frames.
Deprecate the 'source_no_drop' value, as it is now redundant.
---
doc/ffmpeg.texi | 5 -
fftools/ffmpeg.h
That field is used by the framerate code to track whether any output has
been generated for the last input frame(*). Its use in the last
invocation of print_report() is meant to meant to account (in the number
of dropped frames printed in the log) for the very last filtered frame
being dropped.
---
tests/fate/ffmpeg.mak | 20 +
tests/ref/fate/force_key_frames-source | 397 +
tests/ref/fate/force_key_frames-source-drop | 22 +
tests/ref/fate/force_key_frames-source-dup | 617
4 files changed, 1056 insertions(+)
create mode
Unlike the 'source' mode, which preserves source keyframe-marking as-is,
the 'source_no_drop' mode attempts to keep track of keyframes dropped by
framerate conversion and mark the next output frame as key in such
cases. However,
* c75be061487 broke this functionality entirely, and made it
ifilter_send_eof() will fail if the input has no real or fallback
parameters, so there is no need to handle the case of some inputs being
in EOF state yet having no parameters.
---
fftools/ffmpeg.c| 2 +-
fftools/ffmpeg.h| 2 --
fftools/ffmpeg_filter.c | 10 +-
3 files
It does not need an OutputFile and an OutputStream, only the target
timebase and the timestamp offset.
---
fftools/ffmpeg_enc.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 420fe96c97..df79eaff59
That is a more appropriate place for this.
---
fftools/ffmpeg_enc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 9b8b3e0226..9aa00f682c 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -965,12
Hi,
as some of you might know, I have been working on multithreading for the
ffmpeg CLI (as opposed to the libraries) for quite a while now. That
work is now finally entering the vicinity of being usable, so I've
decided to air it on the ML for comments on the big picture.
Do note that many
>From ffmpeg_enc to ffmpeg_filter, which is a more appropriate
place for it.
fate-lavf-gxf* no longer spuriously duplicate the first video frame, due
to different rounding.
---
fftools/ffmpeg_enc.c| 9 +
fftools/ffmpeg_filter.c | 6 +-
tests/ref/lavf/gxf | 2 +-
---
fftools/ffmpeg_enc.c | 46 +++-
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 9aa00f682c..420fe96c97 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -1048,6 +1048,30 @@
On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer
> wrote:
> > Hi all
> >
> > There was the request to make a 6.1 before end of April
> > Is that still so ?
> >
> > Assuming it is, its time to make that branch and release soon
On Mon, Sep 18, 2023 at 08:30:58PM -0300, James Almer wrote:
> On 9/18/2023 7:35 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/decode.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> >
Explain how to pass options to filters.
---
doc/ffmpeg.texi | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index d2864ff37e..cf47eb68d1 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1893,9 +1893,18 @@ ffmpeg -i inurl
---
tests/fate/ffmpeg.mak | 4 ++--
tests/fate/filter-video.mak | 2 +-
tests/fate/gif.mak| 2 +-
tests/fate/hevc.mak | 2 +-
tests/fate/lossless-video.mak | 6 +++---
tests/fate/mov.mak| 4 ++--
tests/fate/mpeg4.mak | 2 +-
---
tests/fate/ffmpeg.mak | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 04500d53a0..b5c26788c0 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -217,11 +217,11 @@ fate-h264_mp4toannexb_ticket5927_2:
On Mon, Sep 18, 2023 at 08:24:25PM -0300, James Almer wrote:
> On 9/18/2023 7:35 PM, Michael Niedermayer wrote:
> > Fixes: out of array access
> > Fixes:
> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DCA_fuzzer-6041088751960064
> >
> > Found-by: continuous fuzzing process
> >
On Tue, Sep 19, 2023 at 11:28:20PM +0800, Nuo Mi wrote:
> On Tue, Sep 19, 2023 at 11:26 PM Nuo Mi wrote:
>
> > from the specification:
> > For each OLS, there shall be at least one layer that is an output layer.
> > In other words, for any value of i in the range of 0
> > to TotalNumOlss − 1,
On Tue, Sep 19, 2023 at 07:44:03AM +0200, Michael Koch wrote:
> Ticket / Comment
> 2104 / 14
> 2776 / 6
> 3720 / 9
The ticket comment 14 on ticket #2104 has been deleted.
The ticket comment 6 on ticket #2776 has been deleted.
The ticket comment 9 on ticket #3720 has been deleted.
[...]
--
1 - 100 of 117 matches
Mail list logo
