tor 2023-09-07 klockan 02:32 +0200 skrev Andreas Rheinhardt:
> It is undefined behaviour even in cases where it works
> (it works because both are pointers). Instead change
> the functions involved to use the type expected by the AVIO-API
> and add inline wrappers for our internal callers.
>
> Sig
tor 2023-09-07 klockan 02:32 +0200 skrev Andreas Rheinhardt:
> Fixes many warnings when using -Wcast-qual.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/internal.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks fine
/Tomas
fre 2023-09-08 klockan 22:38 +0200 skrev Marton Balint:
>
>
> On Thu, 7 Sep 2023, Andreas Rheinhardt wrote:
>
> > It is undefined behaviour even in cases where it works
> > (it works because it is only a const uint8_t* vs. uint8_t*
> > difference).
> >
> > Signed-off-by: Andreas Rheinhardt
> >
tor 2023-09-07 klockan 02:23 +0200 skrev Andreas Rheinhardt:
> It is undefined behaviour even in cases where it works
> (it works because it is only a const uint8_t* vs. uint8_t*
> difference).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avio.c | 25 -
> 1 f
On Fri, Sep 08, 2023 at 10:15:02AM +0200, Christophe Gisquet wrote:
> Summary of changes
> - move back to regular, non-macro, get_bits API
> - reduce the lookup to switch the coding method
> - shorter reads wherever possible, in particular for the end of bitstream
> (16 bits instead of 32, as per
On Thu, 7 Sep 2023, Andreas Rheinhardt wrote:
It is undefined behaviour even in cases where it works
(it works because it is only a const uint8_t* vs. uint8_t* difference).
Signed-off-by: Andreas Rheinhardt
---
libavformat/avio.c | 25 -
1 file changed, 16 insertions(
On Fri, 8 Sept 2023 at 20:46, Kieran Kunhya wrote:
>
> On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote:
>
> > On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote:
> > >
> > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow
> > wrote:
> > >
> > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhui
On 08.09.2023 20:55, Kacper Michajlow wrote:
On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel
wrote:
On 07.09.2023 23:38, Kacper Michajlow wrote:
On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
wrote:
On 9/6/2023 6:31 PM, Kacper Michajlow wrote:
What would be a downside of
On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel
wrote:
>
> On 07.09.2023 23:38, Kacper Michajlow wrote:
> > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
> > wrote:
> >>
> >> On 9/6/2023 6:31 PM, Kacper Michajlow wrote:
> >>> What would be a downside of preferring CXX always if
On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote:
> On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote:
> >
> > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow
> wrote:
> >
> > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
> > > wrote:
> > > >
> > > > On 9/6/2023 6:31 PM, Kacper Michajlow
On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote:
>
> On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow wrote:
>
> > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
> > wrote:
> > >
> > > On 9/6/2023 6:31 PM, Kacper Michajlow wrote:
> > > > What would be a downside of preferring CXX always if it ex
On Fri, Sep 08, 2023 at 12:19:45PM -0300, James Almer wrote:
> On 9/8/2023 10:09 AM, Michael Niedermayer wrote:
> > There has been a marked shift of project goals over the years. While long
> > ago FFmpeg
> > was "all of multimedia". With time the scope of the project has shrunk.
> > FFserver was
lgtm
___
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".
On Fri, 8 Sept 2023 at 18:39, Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Sep 8, 2023, at 6:09 AM, Michael Niedermayer
> wrote:
> >
> > modern video encoders where no longer added to ffmpeg
>
> Writing a good modern video encoder is a massive undertaking, and i
> On Sep 8, 2023, at 6:09 AM, Michael Niedermayer
> wrote:
>
> modern video encoders where no longer added to ffmpeg
Writing a good modern video encoder is a massive undertaking, and i think it's
likely that encoders are going to be mostly integrated via libraries.
Along those lines thoug
Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit :
> In the past, most developers in FFmpeg where primarly FFmpeg developers. But
> as FFmpeg is used by almost everyone now, that has changed and many
> developers in FFmpeg today are primarly developer of 3rd party project
Hi,
On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer
wrote:
> On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote:
> [...]
> > Propose a talk, from 5min to 30min.
>
> As i will not be at the conference, here are some quick words
>
I really think you should reconsider this posi
On 9/8/2023 10:09 AM, Michael Niedermayer wrote:
There has been a marked shift of project goals over the years. While long ago
FFmpeg
was "all of multimedia". With time the scope of the project has shrunk.
FFserver was removed not improved, not replaced.
the video encoder core we had, which enco
On 9/8/2023 2:09 PM, Michael Niedermayer wrote:
> Whats the scope of FFmpeg ?
> And is this direction that is taken optimal for FFmpeg, and what people want ?
Not that I don't think this is an issue worth discussing (it is), but I thought
it
was important to note that most/many of the people who
Therefore use a proper prefix for this API, e.g.
ff_init_vlc_sparse -> ff_vlc_init_sparse
ff_free_vlc-> ff_vlc_free
INIT_VLC_LE-> VLC_INIT_LE
INIT_VLC_USE_NEW_STATIC -> VLC_INIT_USE_STATIC
(The ancient INIT_VLC_USE_STATIC has been removed
in 595324e143b57a52e2329eb47b84395c70f93087,
ff_vlc_free() is of course compatible with freeing
a blank VLC.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/truemotion2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index 5527fed958..366d8aefc1 100644
--- a/libav
The flag has been removed long ago.
Signed-off-by: Andreas Rheinhardt
---
tools/patcheck | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/patcheck b/tools/patcheck
index fe52938f29..76ca408b03 100755
--- a/tools/patcheck
+++ b/tools/patcheck
@@ -51,7 +51,6 @@ hiegrep2 '\b_[a-zA-Z0-9_]{1,
Mostly taken from the documentation for ff_init_vlc_from_lengths();
also remove the documentation in vlc.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vlc.c | 23 ---
libavcodec/vlc.h | 29 +
2 files changed, 29 insertions(+), 23 deletions(-)
Not every user of idctdsp.h wants to initialize an IDCTDSPContext;
e.g. the proresdsp only uses ff_init_scantable_permutation()
and the IDCT permutation enum; similarly for cavsdsp and wmv2dsp.
Using a forward declaration here avoids an avcodec.h dependency
in the relevant files.
Signed-off-by: An
Only avctx->bits_per_raw_sample is used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/proresdec2.c | 2 +-
libavcodec/proresdsp.c | 8
libavcodec/proresdsp.h | 5 ++---
libavcodec/x86/proresdsp_init.c | 4 ++--
4 files changed, 9 insertions(+), 10 deletions
Do not rely on an indirect inclusion of avcodec.h in proresdsp.h.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/proresdec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/proresdec.h b/libavcodec/proresdec.h
index 1e48752e6f..230fca41f2 100644
--- a/libavcodec/proresdec.h
Andreas Rheinhardt:
> Regression since fb548fba04193a418f118d21b261ba05db4f480b.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/fate/mpegps.mak | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak
> index 807da1f713..ae301fd
Regression since fb548fba04193a418f118d21b261ba05db4f480b.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/mpegps.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak
index 807da1f713..ae301fd5e1 100644
--- a/tests/fate/mpegps.mak
On Mon, Jul 31, 2023 at 12:11:20AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/sdr.h | 1 -
> libavformat/sdrdemux.c | 7 ---
> 2 files changed, 4 insertions(+), 4 deletions(-)
I will apply this patchset (of mostly bugfixes) in a few days u
On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote:
[...]
> Propose a talk, from 5min to 30min.
As i will not be at the conference, here are some quick words
In the past, most developers in FFmpeg where primarly FFmpeg developers. But as
FFmpeg is
used by almost everyone now, th
This patch add `-replace_fullwidth_japanese` option
introduced in latest (1.0.1) libaribcaption.
---
doc/decoders.texi | 6 ++
libavcodec/libaribcaption.c | 11 +++
2 files changed, 17 insertions(+)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..ee4cc6
On 9/7/2023 9:49 PM, James Almer wrote:
And remove the AVOID_PROBING flag, given it's the last av1 decoder to be tested
either way.
This fixes a regression introduced in 1652f2492f88434010053289d946dab6a57e4d58,
where even if forcing the native av1 decoder, if another decoder was present,
like li
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhao Zhili
> Sent: Saturday, September 2, 2023 4:24 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhao Zhili
> Subject: [FFmpeg-devel] [PATCH v2 8/8] avfilter/dnn_backend_openvino: fix
> wild pointer on error path
>
> From: Zhao Zhili
Le ven. 8 sept. 2023 à 11:19, Andreas Rheinhardt
a écrit :
> > -return 0;
> > +return 0;
>
> You are adding trailing whitespace.
Sorry, will fix. I had to do some of this work on a misconfigured machine.
> > +#include "libavutil/timer.h"
>
> You really need to look over your patches once
Andreas Rheinhardt:
> Christophe Gisquet:
>> x86/x64: 61/52 -> 55/46
>> Around 7-10% speedup.
>>
>> Run and DC do not lend themselves to such changes, likely because
>> their distribution is less skewed, and need larger average vlc read
>> iterations.
>> ---
>> libavcodec/proresdec.h | 1 +
>> l
Christophe Gisquet:
> One indirection less, around 1% speedup.
> ---
> libavcodec/proresdec2.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index b20021c622..85f81d92d3 100644
> --- a/libavcodec/prore
Christophe Gisquet:
> ---
> libavcodec/proresdec2.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 02e1d82d00..b20021c622 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -534,9 +5
Christophe Gisquet:
> x86/x64: 61/52 -> 55/46
> Around 7-10% speedup.
>
> Run and DC do not lend themselves to such changes, likely because
> their distribution is less skewed, and need larger average vlc read
> iterations.
> ---
> libavcodec/proresdec.h | 1 +
> libavcodec/proresdec2.c | 77 ++
Christophe Gisquet:
> Having the various orders and offsets stored in a codebook is compact
> but causes additional computations. Using instead a table for the
> precomputed results achieve some speedups at the cost of ~132 bytes.
>
> Around 5% speedup.
> ---
> libavcodec/proresdec2.c | 54 ++
Christophe Gisquet:
> Summary of changes
> - move back to regular, non-macro, get_bits API
> - reduce the lookup to switch the coding method
> - shorter reads wherever possible, in particular for the end of bitstream
> (16 bits instead of 32, as per the above)
>
> There are cases that really nee
Andreas Rheinhardt:
> Christophe Gisquet:
>> Le ven. 8 sept. 2023 à 10:15, Christophe Gisquet
>> a écrit :
>>>
>>> Summary of changes
>>
>> git send-email --cover-letter apparently didn't let me edit one, so here
>> goes.
>>
>
> Use --compose.
Or even better: --cover-letter --annotate
That way
Christophe Gisquet:
> Le ven. 8 sept. 2023 à 10:15, Christophe Gisquet
> a écrit :
>>
>> Summary of changes
>
> git send-email --cover-letter apparently didn't let me edit one, so here goes.
>
Use --compose.
> This patchset requires my previous one improving the cached bitstream
> reader, and
Le ven. 8 sept. 2023 à 10:15, Christophe Gisquet
a écrit :
>
> Summary of changes
git send-email --cover-letter apparently didn't let me edit one, so here goes.
This patchset requires my previous one improving the cached bitstream
reader, and serves as its justification. It, basically, moves to
One indirection less, around 1% speedup.
---
libavcodec/proresdec2.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index b20021c622..85f81d92d3 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.
---
libavcodec/proresdec2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 02e1d82d00..b20021c622 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -534,9 +534,9 @@ static int decode_picture_head
Basically, the catch-all codebook is for on average long codewords,
and with a distribution such that the 3-step VLC reading is not
efficient. Furthermore, the complete unrolling make the actual code
smaller than the macro, and as the maximum codelength is smaller,
smaller amounts of bits, optimize
Pretty harmless, but not much gained either.
---
libavcodec/proresdec2.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 91c689d9ef..e3cef402d7 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@
x86/x64: 61/52 -> 55/46
Around 7-10% speedup.
Run and DC do not lend themselves to such changes, likely because
their distribution is less skewed, and need larger average vlc read
iterations.
---
libavcodec/proresdec.h | 1 +
libavcodec/proresdec2.c | 77 ++--
Having the various orders and offsets stored in a codebook is compact
but causes additional computations. Using instead a table for the
precomputed results achieve some speedups at the cost of ~132 bytes.
Around 5% speedup.
---
libavcodec/proresdec2.c | 54 +++-
Summary of changes
- move back to regular, non-macro, get_bits API
- reduce the lookup to switch the coding method
- shorter reads wherever possible, in particular for the end of bitstream
(16 bits instead of 32, as per the above)
There are cases that really need longer lengths (larger EG codes)
50 matches
Mail list logo
