It is highly unsafe, as AVCodecContext contains many allocated fields.
Everything needed by worked threads should be covered by
* routing through AVCodecParameters
* av_opt_copy()
* copying quantisation matrices manually
avcodec_free_context() can now be used for per-thread contexts.
---
Quoting Andreas Rheinhardt (2024-03-23 14:15:06)
> Anton Khirnov:
> > Skip those side data types that do not make sense as global side data.
> > ---
> > fftools/ffmpeg_enc.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/fftools/ffmpeg
Skip those side data types that do not make sense as global side data.
---
fftools/ffmpeg_enc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index f01be1c22f..6a91fd0398 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -247,6
They allow exporting extended information about side data types.
---
doc/APIchanges | 4 +++
libavutil/frame.c | 70 ++---
libavutil/frame.h | 27 +
libavutil/version.h | 2 +-
4 files changed, 72 insertions(+), 31 deletions(-)
Nothing about this code is video-specific.
---
fftools/ffmpeg_enc.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 6a91fd0398..61310c67f1 100644
--- a/fftools/ffmpeg_enc.c
+++
There is no need to free the already-added items, they will be freed
alongside the codec context. There is also little point in an error
message, as the only reason this can fail is malloc failure.
---
fftools/ffmpeg_enc.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
Quoting James Almer (2024-03-23 03:33:13)
> Why does this test change? And is it just the order or side data in the
> output frame?
Yes, just the order. And the test is being removed, so it doesn't matter
either way.
--
Anton Khirnov
___
ffmpeg
Quoting James Almer (2024-03-23 03:53:26)
> On 3/22/2024 5:28 PM, Anton Khirnov wrote:
> > lavfi does not require aligned buffers, so we can safely apply top/left
> > cropping by any amount, without passing any special flags to lavc.
> > Longer term, an even better solution w
Quoting James Almer (2024-03-22 20:38:38)
> On 3/22/2024 6:52 AM, Anton Khirnov wrote:
> > I objected to this indiscriminate copying in a previous review.
> >
> > There is no reason to expect side data to apply to the whole stream just
> > because it happens to apply t
It will be shared with encoding code.
---
libavcodec/avcodec.c | 14 ++
libavcodec/avcodec_internal.h | 16 +++-
libavcodec/decode.c | 33 +
3 files changed, 38 insertions(+), 25 deletions(-)
diff --git
Fixes fate-ffmpeg-loopback-decoding with THREADS=random*
---
tests/fate/ffmpeg.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 9cf05ead68..3c549b265e 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@
lavfi does not require aligned buffers, so we can safely apply top/left
cropping by any amount, without passing any special flags to lavc.
Longer term, an even better solution would probably be auto-inserting
the crop filter (or its hwaccel versions) as needed.
Multiple FATE tests no longer need
This way it can be automagically propagated through the encoder to
muxing.
---
libavcodec/encode.c | 23 +++
tests/ref/fate/libx265-hdr10 | 24
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/libavcodec/encode.c
It is no longer accessed outside of ffmpeg_demux.
---
fftools/ffmpeg.h | 2 --
fftools/ffmpeg_demux.c | 8 +---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 1437b36b0d..84475434f3 100644
--- a/fftools/ffmpeg.h
+++
All side data should be propagated through the trancoding pipeline.
---
fftools/ffmpeg_enc.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index f01be1c22f..138044da24 100644
--- a/fftools/ffmpeg_enc.c
+++
There is only a single caller of filter_codec_opts() that passes
a NULL codec to it, which is streamcopy in ffmpeg CLI. In that case we
only want generic AVCodecContext options, not private options of any
specific encoder.
---
fftools/cmdutils.c | 4
1 file changed, 4 deletions(-)
diff
It is highly unsafe, as AVCodecContext contains many allocated fields.
Copying information via AVCodecParameters and with av_opt_copy() should
handle everything needed by thread workers.
---
libavcodec/frame_thread_encoder.c | 26 --
1 file changed, 20 insertions(+), 6
---
fftools/ffmpeg_filter.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 3d88482d07..9aa499a89e 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -143,6 +143,7 @@ typedef struct InputFilterPriv {
Avoids abusing AV_DICT_MULTIKEY and relying on undocumented AVDictionary
ordering behaviour.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_dec.c | 2 ++
fftools/ffmpeg_demux.c | 11 +--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpeg.h
Do not pass an options dictionary to avcodec_open2().
This should be equivalent to current behaviour, but will allow
overriding caller-supplied options in a cleaner and more robust manner.
We can now set the COPY_OPAQUE flag directly rather going through
dec_opts.
---
fftools/ffmpeg_dec.c | 21
It is pointless otherwise, as decoder options will not be used.
---
fftools/ffmpeg_demux.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 47312c9fe1..73b0eb0da1 100644
--- a/fftools/ffmpeg_demux.c
+++
within FFmpeg.
I suggested some time ago we should mark x265 as experimental. It didn't
receive much enthusiasm, and some probably considered it a joke, but I
was mostly serious. It has major memory safety issues that have been
ignored for years.
--
Anton Khirnov
on the voters who have to
carefully read and compare all the options.
Beyond that, I am planning to start the vote on Monday 2024-03-25.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Quoting Stefano Sabatini (2024-03-19 15:58:03)
> On date Thursday 2024-03-14 11:12:31 +0100, Anton Khirnov wrote:
> > ---
> > doc/ffmpeg.texi | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/ffmpeg.texi b/doc
> Subject: Re: [FFmpeg-devel] [PATCH v6] avcodec/libx264: fix extradata when
> config annexb=0
This could really use more explanation on what exactly is broken.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
wo ints, or two uint8_t's
if you really need to save space, though that also seems unncessary as
this struct is allocated rarely and usually does not live long.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://f
is the appropriate
response. If the user does not want us to do arbitrarily large
allocation, they have the appropriate OS-level mechanisms (e.g. ulimit,
cgroups on Linux) or av_max_alloc().
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Quoting Niklas Haas (2024-03-18 17:54:17)
> +const AVFilmGrainParams *av_film_grain_params_select(const AVFrame *frame);
Could this benefit from a flags parameter for future extensions?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-de
pply to the first frame. For many side data types
it does not even make sense, as they are fundamentally per-frame.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Quoting Niklas Haas (2024-03-21 13:11:32)
> On Thu, 21 Mar 2024 11:16:57 +0100 Anton Khirnov wrote:
> > Quoting Niklas Haas (2024-03-19 20:16:39)
> > > From: Niklas Haas
> > >
> > > AV1 streams don't use configuration records, so delete them when
>
Quoting Gyan Doshi (2024-03-15 05:12:41)
>
>
> On 2024-03-14 03:46 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2024-03-13 08:49:52)
> >
> >> Are there any limitations to loopback decoding e.g. would a vpx w/alpha
> >> encode be decoded back to a alpha
peg CLI. It
implies that every single caller must now be aware of this
(undocumented?) interaction of this specific side data with this
specific codec ID.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Quoting Gyan Doshi (2024-03-13 08:49:52)
>
>
> On 2024-03-13 12:57 pm, Anton Khirnov wrote:
> > ffmpeg | branch: master | Anton Khirnov | Mon Feb 19
> > 10:27:44 2024 +0100| [a9193f7b7d65aafa326e25571c6672636a8ee3d2] |
> > committer: Anton Khirnov
> >
> >
---
doc/ffmpeg.texi | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a38ef834e1..801c083705 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -229,12 +229,16 @@ successive integers starting at zero. These indices
Quoting Andreas Rheinhardt (2024-03-12 10:21:52)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-03-12 09:56:46)
> >> Anton Khirnov:
> >>> Otherwise it might conflict with caller-defined identifiers.
> >>>
> >>> ff bec
Quoting Andreas Rheinhardt (2024-03-12 09:56:46)
> Anton Khirnov:
> > Otherwise it might conflict with caller-defined identifiers.
> >
> > ff because it is not supposed to be used by external callers.
> > ---
>
> This is public, so it should be av_attribute_d
Otherwise it might conflict with caller-defined identifiers.
ff because it is not supposed to be used by external callers.
---
doc/developer.texi | 2 +-
doc/print_options.c| 4 ++--
libavcodec/avcodec.h | 4 ++--
libavcodec/avfft.h
Quoting Martin Storsjö via ffmpeg-devel (2024-03-11 15:03:15)
> On Mon, 11 Mar 2024, Anton Khirnov wrote:
>
> >> I think the point is, that one can't just dismiss that anybody would want
> >> to encode mpeg4 video any longer, even if it is obsolete. I also would
>
Quoting Martin Storsjö (2024-03-11 13:29:15)
> On Mon, 11 Mar 2024, Anton Khirnov wrote:
>
> > Quoting Tobias Rapp (2024-03-11 11:12:38)
> >> On 10/03/2024 23:49, Anton Khirnov wrote:
> >>
> >>> Quoting James Almer (2024-03-10 23:29:27)
> &
Quoting Tobias Rapp (2024-03-11 11:12:38)
> On 10/03/2024 23:49, Anton Khirnov wrote:
>
> > Quoting James Almer (2024-03-10 23:29:27)
> >> On 3/10/2024 7:24 PM, Anton Khirnov wrote:
> >>> Quoting Michael Niedermayer (2024-03-10 20:21:47)
> >>>>
st needs your video to be CFR, with a list of supported
> > framerates; dvenc should probably read AVCodecContext.framerate
> > instead of time_base
> >
> > But most importantly, is there an actual current use case for either of
> > those encoders? They have both bee
Quoting James Almer (2024-03-10 23:29:27)
> On 3/10/2024 7:24 PM, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-10 20:21:47)
> >> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote:
> >>> Quoting Michael Niedermayer (2024-03-10 04:36:29)
>
Quoting Michael Niedermayer (2024-03-10 20:21:47)
> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-10 04:36:29)
> > > On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote:
> > > > Quoting Michael Ni
Quoting Michael Niedermayer (2024-03-10 04:36:29)
> On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-07 21:37:39)
> > > On Wed, Mar 06, 2024 at 12:03:03PM +0100, Anton Khirnov wrote:
> > > > Treat it analogo
Will push tomorrow if nobody has further comments.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org
It has no reason to exist.
---
fftools/ffmpeg_filter.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 7cd5415341..a87bed6ec7 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@
The caller does not need or expect it, and it can lead to terminating
filtering prematurely in case there is more than one output.
---
fftools/ffmpeg_filter.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index
ORDER_UNSPEC,
> AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS);
It might be useful to have an av_channel_layout_retype() flag (something
like AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICALISE) that converts to the
simplest possible representation (not saying you need to add it right
now, it's just a note for future considerati
Quoting Andreas Rheinhardt (2024-03-08 11:44:12)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-03-08 11:19:59)
> >> Anton Khirnov:
> >>> Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
> >>>> Anton Khirnov:
> >>>
Quoting Andreas Rheinhardt (2024-03-08 11:19:59)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
> >> Anton Khirnov:
> >>> ff_thread_get_buffer() has exactly the same semantics as
> >>> ff_get_buffer(), except it is supposed to be us
Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
> Anton Khirnov:
> > ff_thread_get_buffer() has exactly the same semantics as
> > ff_get_buffer(), except it is supposed to be used in frame-threaded
> > decoders. Since the decoder instance knows whether frame th
---
libavcodec/thread.h | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/libavcodec/thread.h b/libavcodec/thread.h
index 5a00b32619..111010b27f 100644
--- a/libavcodec/thread.h
+++ b/libavcodec/thread.h
@@ -27,11 +27,9 @@
#ifndef AVCODEC_THREAD_H
ff_thread_get_buffer() has exactly the same semantics as
ff_get_buffer(), except it is supposed to be used in frame-threaded
decoders. Since the decoder instance knows whether frame threading is in
use, there is no point in forcing decoder implementations to use a
different function merely because
thread.h currently contains both API for decoder use and functions
internal to lavc generic layer. Move the latter to avcodec_internal.h,
which is a more appropriate place for them.
---
libavcodec/avcodec_internal.h | 24
libavcodec/pthread.c | 1 +
Quoting Michael Niedermayer (2024-03-07 21:37:39)
> On Wed, Mar 06, 2024 at 12:03:03PM +0100, Anton Khirnov wrote:
> > Treat it analogously to stream parameters like format/dimensions/etc.
> > This is functionally different from previous code in 2 ways:
> > * for non-CFR vide
---
doc/APIchanges| 3 +
libavutil/opt.c | 360 +-
libavutil/opt.h | 56 ++-
libavutil/tests/opt.c | 49 ++
tests/ref/fate/opt| 35 +++-
5 files changed, 458 insertions(+), 45 deletions(-)
diff --git a/doc/APIchanges
This allows to send an encoder's output back to decoding and feed the
result into a complex filtergraph.
---
Now using [dec:X] instead of [decX] in filtergraph link labels, as
suggested by Marvin on IRC.
---
Changelog | 1 +
doc/ffmpeg.texi | 49 ++--
Apparently it can happen that avfilter_graph_request_oldest() returns
EAGAIN, yet av_buffersrc_get_nb_failed_requests() returns 0 for every
input.
Fixes #10795
---
fftools/ffmpeg_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c
sed.
> And the name in this case is very specific and self explanatory in how
> it's different from the alternative.
>From decoder POV it's not different at all, it does exactly the same
thing.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-deve
Quoting Andreas Rheinhardt (2024-03-07 12:19:28)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-03-04 14:36:09)
> >> Anton Khirnov:
> >>> From: Niklas Haas
> >>>
> >>> For consistency, even though this cannot be overriden at the packe
r/demuxer and eventually find a way to properly tag
> the colorspace.
Is there any reason ever to export YUV palette? Should this even be an
option?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/l
Will push the set tomorrow if nobody has further objections.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ
This and the following commits fix #10857
---
Renamed the option to 'side_data_prefer_packet', as preferred by James
and Derek on IRC.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 31 +++
libavcodec/decode.c| 36
Rename dec_open to dec_init(), as it is more descriptive of its new
purpose.
Will be useful in following commits, which will add a new path for
opening decoders.
---
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_dec.c | 61 ++
fftools/ffmpeg_demux.c |
Perform it right after we figure out what the type is.
---
fftools/ffmpeg_filter.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 7425e3d2ed..eb8d0aee78 100644
--- a/fftools/ffmpeg_filter.c
+++
These functions used to be much longer, but now they are only a couple
lines each, some of them duplicated between audio and video.
---
fftools/ffmpeg_enc.c | 65 +++-
1 file changed, 22 insertions(+), 43 deletions(-)
diff --git a/fftools/ffmpeg_enc.c
This allows to send an encoder's output back to decoding and feed the
result into a complex filtergraph.
---
Changelog | 1 +
doc/ffmpeg.texi | 49 ++--
fftools/cmdutils.c | 2 +-
fftools/cmdutils.h | 7 +-
fftools/ffmpeg.c| 26 +++
This allows using WRAPPED_AVFRAME encoders with loopback decoders in
order to connect multiple filtergraphs together.
Clear the flag in muxers, since lavf does not need it for anything and
it would change the results of framecrc FATE tests.
---
fftools/ffmpeg_enc.c | 2 ++
fftools/ffmpeg_mux.c |
Will be useful in following commits.
---
fftools/ffmpeg.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2f01a01e2d..ffd25f4c5b 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@
---
fftools/ffmpeg_sched.c | 212 ++---
fftools/ffmpeg_sched.h | 8 +-
2 files changed, 181 insertions(+), 39 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 5f8ef04680..d1fb942c34 100644
--- a/fftools/ffmpeg_sched.c
+++
These functions used to be passed directly to pthread_create(), which
required them to return void*. This is no longer the case, so they can
return a plain int.
---
fftools/ffmpeg.h| 4 ++--
fftools/ffmpeg_dec.c| 6 +++---
fftools/ffmpeg_demux.c | 4 ++--
fftools/ffmpeg_enc.c| 4
Will be useful in following commits.
---
fftools/ffmpeg_sched.c | 151 +
1 file changed, 91 insertions(+), 60 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index e5435dd866..5f8ef04680 100644
--- a/fftools/ffmpeg_sched.c
+++
---
fftools/ffmpeg_filter.c | 8
1 file changed, 8 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index eb8d0aee78..7aa9305c88 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1142,6 +1142,10 @@ static int
Will become useful in following commits.
---
fftools/ffmpeg_sched.c | 117 ++---
1 file changed, 98 insertions(+), 19 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index cf9b0c836e..e5435dd866 100644
--- a/fftools/ffmpeg_sched.c
+++
The first of these binds inputs of complex filtergraphs to demuxer
streams (with a misleading comment claiming it *creates* complex
filtergraphs).
The second ensures that all filtergraph outputs are connected to an
encoder.
Merge them into a single function, which simplifies the ffmpeg_filter
Treat it analogously to stream parameters like format/dimensions/etc.
This is functionally different from previous code in 2 ways:
* for non-CFR video, the frame timebase (set by the decoder) is used
rather than the demuxer timebase
* for sub2video, AV_TIME_BASE_Q is used, which is hardcoded by
Current callstack looks like this:
* ifilter_bind_ist() (filter) calls ist_filter_add() (demuxer);
* ist_filter_add() opens the decoder, and then calls
dec_add_filter() (decoder);
* dec_add_filter() calls ifilter_parameters_from_dec() (i.e. back into
the filtering code) in order to give
Encoder timebase is equal to the frame timebase, so does not need to be
passed separately.
Also, rename in_picture to frame, which is shorter and more accurate -
it always contains a frame, never a field.
---
fftools/ffmpeg_enc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
---
fftools/cmdutils.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 008949a39d..8efec942bd 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -793,7 +793,7 @@ int split_commandline(OptionParseContext *octx, int
Outside of ifilter_bind_ist(), there are no longer any assumptions about
about filter inputs being fed by an InputStream.
---
fftools/ffmpeg_filter.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index
Will be useful in following commits where we will want to create a
decoder before having enough information to open it.
---
fftools/ffmpeg_dec.c | 51 +++-
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/fftools/ffmpeg_dec.c
---
libavformat/matroskadec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 5d3d18a146..6d6a60c552 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2036,7 +2036,7 @@ static int
hat's what would be
reasonable, but I can definitely imagine a situation where you'd want
the reverse. But I do agree that it's not something lavc needs to
handle.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
tes read from input in order to determine stream
> durations
> + * when using estimate_timings_from_pts in avformat_find_stream_info().
> + *
> + * - encoding: unused
> + * - decoding: set by user
> + */
>
Quoting James Almer (2024-03-05 15:35:02)
> On 3/5/2024 11:29 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-03-05 13:30:58)
> >>> +{"dynamic_hdr10_plus", .default_val.i64 =
> >>> AV_PKT_DATA_DYNAMIC_HDR10_PLUS, .type = AV
el only, not global.
It is in sd_global_map
> Is this option meant to also choose which one of those to use?
???
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscrib
IDE_DATA_SET_FLAG_NO_DUPLICATES);
I'm not sure this makes sense in general.
The side data in AVCodecContext is supposed to be 'static', i.e.
applying to the whole stream. Many side data types do not make sense as
global side data (e.g. closed captions). Or it could be that the side
data is not actually
Quoting James Almer (2024-03-01 21:42:28)
> On 3/1/2024 3:19 PM, Anton Khirnov wrote:
> > Quoting Jan Ekström (2024-02-29 17:42:54)
> >> diff --git a/libavutil/frame.h b/libavutil/frame.h
> >> index 47d0096bc4..908fd4a90d 100644
> >> --- a/libavutil/
ntly been submitted, with no public
announcement that it even happened, much less what was in it.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
Quoting Michael Niedermayer (2024-03-05 03:36:14)
> On Mon, Mar 04, 2024 at 10:15:31PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-04 00:36:21)
> > > [words words]
> >
> > Again - why do you personally need so many choices? Just one should
Quoting Andreas Rheinhardt (2024-03-04 14:36:09)
> Anton Khirnov:
> > From: Niklas Haas
> >
> > For consistency, even though this cannot be overriden at the packet
> > level.
> > ---
> > libavcodec/mpeg12dec.c | 18 ++
> >
Quoting Derek Buitenhuis (2024-03-04 15:05:29)
> On 3/4/2024 1:06 PM, Anton Khirnov wrote:
> > +/**
> > + * Decoding only. May be set by the caller before avcodec_open2() to an
> > + * av_malloc()'ed array (or via AVOptions). Owned and freed by the
> > dec
V_OPT_TYPE_FLAG_ARRAY options. May be NULL.
>
> This contradicts with the documentation of AVOptionArrayDef above, because
> there you write that default_val MUST be set.
Changed 'must' to 'may' locally. It is optional, and one of the test
entries does not set it.
--
Anton Khirnov
_
Quoting Marton Balint (2024-03-04 23:39:19)
> On Mon, 4 Mar 2024, Anton Khirnov wrote:
> > Native access is from the code that declared the options, foreign access
> > is from code that is using the options. Forbid foreign access to
> > AVOption.offset/default_val, for w
Quoting Michael Niedermayer (2024-03-04 00:36:21)
> [words words]
Again - why do you personally need so many choices? Just one should be
enough. If someone else wants some other choice on the ballot, they
should ask for it.
--
Anton Khirnov
___
ffm
Quoting Andreas Rheinhardt (2024-03-04 14:29:59)
> Anton Khirnov:
> > ---
> > doc/APIchanges| 3 +
> > libavutil/opt.c | 362 +-
> > libavutil/opt.h | 62 +++-
> > libavutil/tests/opt.c |
It never makes sense for this function to be called by users.
---
libavfilter/avfilter.c | 11 +--
libavfilter/avfilter.h | 5 -
libavfilter/version_major.h | 1 +
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavfilter/avfilter.c
It never makes sense for this function to be called by users.
---
libavfilter/avfilter.c | 8 ++--
libavfilter/avfilter.h | 8 +++-
libavfilter/avfiltergraph.c | 2 +-
libavfilter/f_streamselect.c | 2 +-
libavfilter/internal.h | 8
5 files changed, 19
These fields are documented to be non-public and are only used in
decode.c
---
libavcodec/avcodec.h | 10 --
libavcodec/decode.c | 37 ++---
2 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index
Cf. #10857
---
tests/fate/matroska.mak | 6 +
tests/ref/fate/matroska-side-data-pref-codec | 255 ++
tests/ref/fate/matroska-side-data-pref-global | 255 ++
3 files changed, 516 insertions(+)
create mode 100644
201 - 300 of 4242 matches
Mail list logo
