Quoting Andrew Sayers (2024-04-23 11:51:00)
> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > lavu/opt: Clarify that AVOptions is not indended for general use
> >
> > They _are_ intended for general use though.
>
> In that case I'm confused...
&
> lavu/opt: Clarify that AVOptions is not indended for general use
They _are_ intended for general use though.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscr
data key 'id'
>
> This allows using -map_metadata and -metadata to copy/set streamids (PIDs).
I dislike this patch, metadata is the wrong place for such information.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
Hi all,
I am hereby resigning from my position as a CC member, since I do not
want to be associated with the CC's utter lack of initiative and
meaningful action.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Reduces sizeof(HEVCSPS) by 96 bytes.
Also improve flag names: drop redundant suffixes and prefixes, and
consistently use disabled/enabled.
---
libavcodec/dxva2_hevc.c| 24 -
libavcodec/hevc_cabac.c| 36 ++---
libavcodec/hevc_filter.c | 8 +--
Do not use larger fields than needed, use size-1 bitfields for flags.
Reduces sizeof(HEVCSPS) by 1280 bytes.
---
libavcodec/hevc_ps.c | 6 +++---
libavcodec/hevc_ps.h | 19 +++
libavcodec/vulkan_hevc.c | 2 +-
3 files changed, 15 insertions(+), 12 deletions(-)
diff
It is currently an array of 32 uint8_t, each storing a single flag. A
single uint32_t is sufficient.
Reduces sizeof(HEVCSPS) by 1792 bytes.
---
libavcodec/hevc_ps.c | 33 +++--
libavcodec/hevc_ps.h | 2 +-
libavcodec/hevc_refs.c | 6 +++---
They are only used in vulkan_hevc and are not actually needed, as they
can be computed from delta_poc.
Reduces sizeof(HEVCSPS) by 16kB.
---
libavcodec/hevc_ps.c | 4 ++--
libavcodec/hevc_ps.h | 2 --
libavcodec/vulkan_hevc.c | 7 +--
3 files changed, 7 insertions(+), 6 deletions(-)
It is actually supposed to go negative in the loop over num_negative
pics, but underflow does not break anything as the result is then
assigned to a signed int.
---
libavcodec/hevc_ps.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_ps.c
It is currently an array of 32 uint8_t, each storing a single flag. A
single uint32_t is sufficient.
---
libavcodec/hevc_ps.c | 4 +++-
libavcodec/hevc_ps.h | 2 +-
libavcodec/hevcdec.c | 2 +-
libavcodec/vulkan_hevc.c | 3 +--
4 files changed, 6 insertions(+), 5 deletions(-)
diff
It is more efficient and easier to manage.
---
libavcodec/hevcdec.c | 57 +---
libavcodec/hevcdec.h | 2 +-
2 files changed, 33 insertions(+), 26 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 55f72af972..47226ef0ab 100644
---
---
libavcodec/hevcdec.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 47226ef0ab..6b2c0b75ee 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2526,9 +2526,8 @@ static void
The latter can be lowered while decoding, which would lead to memleaks.
---
libavcodec/hevcdec.c | 7 +--
libavcodec/hevcdec.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index c70937a756..55f72af972 100644
---
It is more consistent with our naming conventions.
---
libavcodec/hevcdec.c | 30 +++---
libavcodec/hevcdec.h | 2 +-
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index d3b668af00..c70937a756 100644
---
Quoting Andreas Rheinhardt (2024-04-10 10:02:55)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-04-10 09:09:00)
> >> Anton Khirnov:
> >>> Quoting Andreas Rheinhardt (2024-04-08 22:13:40)
> >>>> diff --git a/libavcodec/pthread_frame.c b/libav
Quoting Andreas Rheinhardt (2024-04-10 09:09:00)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-04-08 22:13:40)
> >> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> >> index fd356bd190..6b2c4312e0 100644
> >> --- a/libavcodec/p
ng-frame.webm
> from the FATE-suite.
>
> Fix this by actually waiting for the frame to be output.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/vp9.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
LGTM, though it'd be nice of som
hread to have its own reference.
Looks good otherwise.
--
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".
adProgress will be initialized so that
> + * to be in no-op mode as described above. Otherwise
Seems like something missing here.
LGTM otherwise.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
ext step? I do not have commit access.
>
> Applied it, thanks.
WTF?
Please revert immediately.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
less private.
--
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".
n
> ff_encode_preinit?
We should.
--
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 Nuo Mi (2024-04-07 14:13:58)
> On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov wrote:
>
> > Quoting Frank Plowman (2024-04-06 15:46:09)
> > > Key line from the spec is:
> > >
> > > "All SPS NAL units with a particular value of sps_seq_paramet
+
> > libavcodec/version.h| 4 +--
> > 6 files changed, 121 insertions(+), 6 deletions(-)
>
> If the API is changed, it should be to an API that allows externally
> maintained codecs.
> (it would result in more developers working on codecs)
This seems like a
Quoting Andreas Rheinhardt (2024-04-06 13:25:49)
> See https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320849.html
> Additionally I do not agree that sorting options by name is the best
> way; it should be sorted by what are (believed to be) the most commonly
> used options.
+
what H264/HEVC do, which is
replace the SPS, invalidate the PPSes that depend on the old one, and
start a new CVS.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To un
Quoting James Almer (2024-04-05 19:16:21)
> v2.0.0 is already four years old and available on stable distro releases.
> With this we stop setting codec capabilities during static data
> initialization.
Sounds reasonable to me.
--
Anto
out* mapping the stream twice?
What's the issue with mapping a stream twice?
> A complex filtergraph could have a stream mapped, split and then passed to
> a copy codec operation, for example, without needing the double re-map
> implied above.
Filter
This allows one complex filtergraph's output to be sent as input to
another one, which is useful in certain situations (one is described in
the docs).
Chaining filtergraphs was already effectively possible by using a
wrapped_avframe encoder connected to a loopback decoder, but it is ugly,
Instead pass the encoder through a newly-added output options struct,
analogous to previously added input options.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 11 +--
fftools/ffmpeg_filter.c | 36 +++-
Reduces the need to access OutputFile, which will allow decoupling
filtering from encoding in future commits.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_filter.c | 3 +--
fftools/ffmpeg_mux_init.c | 2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.h
fg_finalise_bindings() already checks that all filtergraph outputs are
connected.
---
fftools/ffmpeg_filter.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index ceab58da19..41d96267bc 100644
--- a/fftools/ffmpeg_filter.c
+++
It is no longer used outside of the muxing code (where we can access the
muxer directly).
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_mux.c | 15 +--
fftools/ffmpeg_mux_init.c | 1 -
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg.h
Do not construct it from OutputStream manually.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 3 +++
fftools/ffmpeg_filter.c | 36 +++-
fftools/ffmpeg_mux_init.c | 4
3 files changed, 26 insertions(+), 17
---
doc/ffmpeg.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 9bd548ce4e..e996ab945f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -2143,7 +2143,8 @@ Define a complex filtergraph, i.e. one with arbitrary
number of inputs
Store simple filtergraphs in the stream they feed. Keeping the two
separate will be useful in following commits.
---
fftools/ffmpeg.c| 5 +
fftools/ffmpeg.h| 3 +++
fftools/ffmpeg_filter.c | 16 +---
fftools/ffmpeg_mux.c| 1 +
4 files changed, 22
Do not read them from OutputStream directly.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_filter.c | 11 +++
fftools/ffmpeg_mux_init.c | 2 ++
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git
Do not read it from OutputStream directly.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_filter.c | 9 +---
fftools/ffmpeg_mux.c | 2 +-
fftools/ffmpeg_mux.h | 3 +++
fftools/ffmpeg_mux_init.c | 45
Do not read it from OutputStream directly.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_filter.c | 2 +-
fftools/ffmpeg_mux_init.c | 7 ---
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git
It is no longer needed outside of of_open() and its children.
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_mux_init.c | 17 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 26b42a3fcd..1d32009f90 100644
---
All remaining code accessing it only needs to know whether this
filtergraph output has been bound or not.
---
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_filter.c | 6 +++---
fftools/ffmpeg_mux_init.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.h
The decision whether -apad actually does anything is made based on muxer
properties, and so more properly belongs there. Filtering code only
receives the result.
---
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_filter.c | 16 +++-
fftools/ffmpeg_mux.c | 1 -
Stop digging through encoder options manually.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_filter.c | 20 ++--
fftools/ffmpeg_mux_init.c | 5 +
3 files changed, 21 insertions(+), 6 deletions(-)
It is used in a single place in the filtering code, so it is better to
inline it there.
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_filter.c | 2 +-
fftools/ffmpeg_mux_init.c | 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index
Will be useful for filtergraph chaining that will be added in following
commits.
---
fftools/ffmpeg_sched.c | 94 ++
fftools/ffmpeg_sched.h | 6 ++-
2 files changed, 63 insertions(+), 37 deletions(-)
diff --git a/fftools/ffmpeg_sched.c
---
fftools/ffmpeg_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 41d96267bc..ffbc13eb70 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1472,7 +1472,7 @@ fail:
static int
First bind all inputs in all filtergraphs, only then check that all
outputs are bound.
Needed by the following commit.
---
fftools/ffmpeg.h| 2 +-
fftools/ffmpeg_filter.c | 33 ++---
fftools/ffmpeg_opt.c| 10 --
3 files changed, 31 insertions(+),
Do not read them from OutputStream directly.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 7 +--
fftools/ffmpeg_filter.c | 27 ++-
fftools/ffmpeg_mux.c | 3 ---
fftools/ffmpeg_mux_init.c | 11 ---
4
Reduces the need to access OutputStream, which will allow decoupling
filtering from encoding in future commits.
---
fftools/ffmpeg.h | 7 +--
fftools/ffmpeg_filter.c | 2 +-
fftools/ffmpeg_mux_init.c | 4 +++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git
Can do it as soon as that option is parsed, no need to postpone it until
opening the encoder.
---
fftools/ffmpeg_enc.c | 3 ---
fftools/ffmpeg_mux_init.c | 6 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index
OutputFilter.type contains the same information.
---
fftools/ffmpeg_filter.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 840502bd62..d2fd26af7e 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@
That, if anywhere, is a more appropriate place for it.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_filter.c | 29 +++--
fftools/ffmpeg_mux_init.c | 24
3 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/fftools/ffmpeg.h
Use it for logging where appropriate, avoid logging to OutputStream as
we do not own it.
This is a step towards decoupling filtering from encoding.
---
fftools/ffmpeg.h| 2 ++
fftools/ffmpeg_filter.c | 68 +
2 files changed, 51 insertions(+), 19
Pass all the necessary value through OutputFilterOptions.
Will allow decoupling filtering from encoding in future commits.
---
fftools/ffmpeg.h | 7 +++
fftools/ffmpeg_filter.c | 22 +++---
fftools/ffmpeg_mux_init.c | 6 ++
3 files changed, 24 insertions(+),
Reduces the need to access OutputStream, which will allow decoupling
filtering from encoding in future commits.
---
fftools/ffmpeg.h | 9 +++--
fftools/ffmpeg_filter.c | 8 +---
fftools/ffmpeg_mux_init.c | 9 +
3 files changed, 17 insertions(+), 9 deletions(-)
diff
It only needs a list of allowed layouts and the requested layout.
---
fftools/ffmpeg_filter.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 2308abf82a..ba6c6c7673 100644
---
---
libavfilter/vf_scale.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index fc0e3802db..1c07daeddf 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -998,8 +998,8 @@ static const AVOption
Analogous to the same constant in avfiltergraph and avcodec.
Cf. f599ae88c25.
---
libavfilter/avfilter.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 7f94e71fbc..049e4f62ca 100644
--- a/libavfilter/avfilter.c
+++
For simple filtergraphs. For complex filtergraphs they always match.
---
fftools/ffmpeg_filter.c | 8
1 file changed, 8 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 0d359303f7..a59c61b312 100644
--- a/fftools/ffmpeg_filter.c
+++
re overly eager to mark everything as 'blocking'. Not every
bug and not every regression should be blocking, otherwise nothing ever
gets finished.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listin
Quoting Jean-Baptiste Kempf (2024-04-03 23:18:27)
> +- DV profile 10 support in av1
DV is Digital Video.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vi
Quoting James Almer (2024-04-03 16:46:14)
> On 4/3/2024 5:35 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-04-02 21:28:28)
> >> On 4/2/2024 4:25 PM, Andreas Rheinhardt wrote:
> >>> James Almer:
> >>>> As it's the main file declaring the
parsed with the new SPS.
The latter would be far more complex and AFAIK is not actually needed
for anything.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visi
a_submit(AVCodecContext *avctx,
> AVFifo *fifo,
> FrameData fd = { .pts = frame->pts };
> int ret;
>
> -#if CONFIG_LIBVPX_VP9_ENCODER
> -if (avctx->codec_id == AV_CODEC_ID_VP9 &&
> +if (IS_VP9(avctx) &&
Weren't we moving towards g
easier to find at least one
> file containing the core code in the base directory.
> And I'd like to do the same for other big modules with 3+ source files.
> hevc, h264, vp9, etc.
I dislike this.
Though I would be in favor of removing the vvc prefix from the file
names, as it
(ret < 0)
> +return ret;
> +}
Seems wasteful to do this for every frame, when it only needs to be done
once. Is there a reason not to put this code in init_thread()?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-deve
---
Now mentioning that vvcdec is experimental, as suggested by Martin on
IRC.
---
src/index | 28
1 file changed, 28 insertions(+)
diff --git a/src/index b/src/index
index 1eb5524..2deb6af 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,34 @@
News
+
---
src/index | 27 +++
1 file changed, 27 insertions(+)
diff --git a/src/index b/src/index
index 1eb5524..ba4f0e8 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,33 @@
News
+ April xxth, 2024, FFmpeg 7.0 "XXX"
+
+ A new major release, FFmpeg 7.0
Quoting Gyan Doshi (2024-04-01 14:20:01)
> On 2024-04-01 04:46 pm, Anton Khirnov wrote:
> > Hi all,
> >
> > the vote has now ended with 23 votes cast, results are available at
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> >
> >
Hi all,
the vote has now ended with 23 votes cast, results are available at
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
The winning option is 'Anton', i.e. my proposal. Voting data as reported
by CIVS is attached to this email for future reference.
Cheers,
--
Anton
This is a reminder that I'm planning to end the vote on Monday morning.
We have 17 votes so far, if you have not voted yet please do so ASAP.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo
Quoting Gyan Doshi (2024-03-29 10:19:15)
> LGTM. Should have been done a long time ago.
> What about the other muxers in movenc?
I don't know what they are used for or what constraints they have, so I
left them alone for now. Can also change them if people see no problem
with it.
--
---
libavformat/movenc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b97c479cc4..30cfbf6e74 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -8230,11 +8230,11 @@ const FFOutputFormat ff_mov_muxer
Quoting James Almer (2024-03-28 12:41:40)
> On 3/28/2024 8:23 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-03-28 04:12:04)
> >> Enable it only for side data types that don't allow more than one entry.
> >>
> >> Signed-off-by: James Alme
Quoting James Almer (2024-03-28 12:49:08)
> On 3/28/2024 8:27 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-03-28 04:12:05)
> >> Signed-off-by: James Almer
> >> ---
> >> libavutil/frame.c | 53 +
Quoting James Almer (2024-03-28 12:36:37)
> On 3/28/2024 8:32 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-03-28 04:12:09)
> >> They will be useful to fill arrays stored in other structs.
> >>
> >> Signed-off-by: James Almer
> >
Quoting James Almer (2024-03-28 12:33:47)
> On 3/28/2024 8:29 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-03-28 04:12:06)
> >> src->data does not need to match src->buf->data
> >
> > When does it not?
>
> It always matches for s
all the decoders, longer and harder to read lines.
Why not make ff_frame_new_side_data_from_buf() a wrapper for a new
function instead?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
Quoting James Almer (2024-03-28 04:12:06)
> src->data does not need to match src->buf->data
When does it not?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
a/libavutil/frame.h b/libavutil/frame.h
> index 2ea129888e..3e5d170a5b 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1048,6 +1048,10 @@ void av_frame_side_data_free(AVFrameSideData ***sd,
> int *nb_sd);
> * Don't add a new entry if another of the same type exists.
> */
/libavutil/frame.h
> @@ -1040,7 +1040,14 @@ const AVSideDataDescriptor
> *av_frame_side_data_desc(enum AVFrameSideDataType typ
> */
> void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
>
> +/**
> + * Remove existing entries before adding new one
es. Additionally, provide an option for users
> to manually "force" a type in the event that this matters for a particular
> source.
Is it not possible to extract all of them simultaneously?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpe
crc -i
> $(TARGET_PATH)/tests/data/asynth-44100-1.wav -af "atempo=2.0" -ar 44100
atempo uses floats for processing, are you sure this will produce
exactly the same results everywhere?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg
vcodec/h264_parse.c
> +++ b/libavcodec/h264_parse.c
> @@ -468,7 +468,7 @@ int ff_h264_decode_extradata(const uint8_t *data, int
> size, H264ParamSets *ps,
> int ret;
>
> if (!data || size <= 0)
> -return -1;
> +
Quoting Kieran Kunhya (2024-03-27 15:13:12)
> On Wed, 27 Mar 2024 at 14:03, Michael Niedermayer
> wrote:
>
> > On Fri, Feb 09, 2024 at 03:19:58PM +, Anton Khirnov wrote:
> > > ffmpeg | branch: master | Anton Khirnov | Thu Feb
&
Quoting Michael Niedermayer (2024-03-27 22:54:14)
> On Fri, Mar 22, 2024 at 11:29:31AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-22 03:25:25)
> [...]
> > > alternative is "wont fix" for all such cases,
> >
> > I
This filter produces VFR output in general.
Avoids dropping frames in the setpts test.
---
libavfilter/setpts.c | 17 ++-
tests/ref/fate/filter-setpts | 89 +---
2 files changed, 67 insertions(+), 39 deletions(-)
diff --git a/libavfilter/setpts.c
Actual frame durations are, in general, not computable without buffering
a frame.
---
libavfilter/setpts.c | 1 +
tests/ref/fate/filter-setpts | 100 +--
2 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/libavfilter/setpts.c
the filtergraph */
> >> +while (1) {
> >> +ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
> >> +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> >> +break;
> > how are we supposed to handle the
Quoting James Almer (2024-03-27 13:35:35)
> On 3/27/2024 4:41 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-03-25 22:13:25)
> >> On 3/25/2024 6:02 PM, Andreas Rheinhardt wrote:
> >>> James Almer:
> >>>> I don't mind a function like that be
ULTI types the functions should always
add a new instance, because very few scenarios need anything else.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, v
Quoting Stefano Sabatini (2024-03-27 12:27:24)
> it's increasing the line count and therefore decreasing readability
I don't think this holds in general.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mail
For consistency with its API header packet.h.
---
libavcodec/Makefile | 2 +-
libavcodec/{avpacket.c => packet.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename libavcodec/{avpacket.c => packet.c} (100%)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index
It is unused internally and has been marked as deprecated a long time
ago.
---
libavcodec/packet.h| 2 ++
libavcodec/version_major.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index b0ba3baea2..a9a41576da 100644
---
It is highly unsafe, as AVCodecContext contains many allocated fields.
Almost everything needed by worker threads should be covered by
routing through AVCodecParameters and av_opt_copy(), except for a few
fields that are copied manually.
avcodec_free_context() can now be used for per-thread
Will allow avoiding forward declarations in following commits.
---
fftools/ffmpeg_sched.c | 138 -
1 file changed, 69 insertions(+), 69 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index ec88017e21..67c32fb5a0 100644
---
Even in cases where the task failed to start due to pthread_create()
failing.
---
fftools/ffmpeg_sched.c | 68 +++---
1 file changed, 44 insertions(+), 24 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 67c32fb5a0..ee3af45908
size);
> -if (st->codecpar->block_align) {
> +if (st->codecpar->block_align &&
> +st->codecpar->ch_layout.nb_channels < FF_SANE_NB_CHANNELS &&
I objected to this approach.
--
Anton Khirnov
___
cases should be covered by the user explicitly.
Then we only need a single flag, which only applies to non-MULTI types,
and chooses whether to replace or not.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/l
l in scenarios where you
> need to
> know the runtime size of AVMasteringDisplayMetadata.
In what scenarios besides side data do you need to know the size of this
struct?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
1 - 100 of 4154 matches
Mail list logo
