>From: ffmpeg-devel On Behalf Of Lynne
>via ffmpeg-devel
>Sent: Thursday, June 6, 2024 2:11 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Lynne
>Subject: Re: [FFmpeg-devel] [PATCH v13 15/15] avcodec/hw_base_encode:
>avoid getting FFHWBaseEncodeContext from avctx
>
>On 03/06/2024 11:19, tong1.wu-at-intel..
Le 6 juin 2024 00:00:57 GMT+03:00, Andreas Rheinhardt
a écrit :
>James Almer:
>> uyvytoyuv422_c: 23991.8
>> uyvytoyuv422_sse2: 2817.8
>> uyvytoyuv422_avx: 2819.3
>
>Why don't you nuke the avx version in a follow-up patch?
Same problem with the RGBA stuff as well. Are the AVX functions expected
On 03/06/2024 11:19, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
This patch is to make FFHWBaseEncodeContext a standalone component
and avoid getting FFHWBaseEncodeContext from avctx->priv_data.
This patch also removes some unnecessary AVCodecContext arguments.
For receive_packet cal
Yet another thing not mentioned in the spec.
---
libavcodec/aac/aacdec_usac.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 97655787ee..5dd489a43b 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcod
The issue was that in case of common TNS parameters, TNS was
entirely skipped, as tns.present was set to 0.
---
libavcodec/aac/aacdec.h | 1 +
libavcodec/aac/aacdec_usac.c | 25 +++--
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/libavcodec/aac/aacdec.h
Although LPD is not functional yet, the bitstream ends at that point.
---
libavcodec/aac/aacdec_usac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 3b4e980df4..9b28a9e90b 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavc
This was left out, and due to av_unused, forgotten about.
---
libavcodec/aac/aacdec.h | 1 +
libavcodec/aac/aacdec_usac.c | 16
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aac/aacdec.h b/libavcodec/aac/aacdec.h
index ee21a94007..f0a33e7ac3 1006
On Wed, Jun 05, 2024 at 12:31:28PM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont" a
> écrit :
> >But by reacting *only* to Vittorio trying to defend himself and explicitly
> >(and ineffectively) asking for help from the CC, you look like you ar
On Wed, Jun 05, 2024 at 03:22:55PM +0100, Andrew Sayers wrote:
> On Wed, Jun 05, 2024 at 09:46:16AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers
> > wrote:
> >
> > > On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > > > On Wed, Jun 5
On Wed, Jun 05, 2024 at 02:34:07PM -0700, Chun-Min Chang wrote:
> This patch updates libaomenc.c to accept parameters for SVC (Scalable
> Video Coding) settings via the FFmpeg API `av_opt_set`. The SVC
> configuration is applied based on the provided parameters. As libaom's
> SVC functionality only
The ff_nv12ToUV_* functions don't use non-temporal stores
at all.
Signed-off-by: Andreas Rheinhardt
---
libswscale/x86/rgb2rgb_template.c | 4
1 file changed, 4 deletions(-)
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index edbacea784..e4e884827c 100
The SSE2 and AVX versions of deinterleaveBytes are external ASM.
Move them out of the inline ASM template.
Signed-off-by: Andreas Rheinhardt
---
libswscale/x86/rgb2rgb.c | 48 +++
libswscale/x86/rgb2rgb_template.c | 30 ---
2 files changed, 36
Signed-off-by: Andreas Rheinhardt
---
libswscale/x86/rgb2rgb_template.c | 104 --
1 file changed, 104 deletions(-)
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index 5c73fa4e16..d1403d08e6 100644
--- a/libswscale/x86/rgb2rgb_temp
This patch updates libaomenc.c to accept parameters for SVC (Scalable
Video Coding) settings via the FFmpeg API `av_opt_set`. The SVC
configuration is applied based on the provided parameters. As libaom's
SVC functionality only operates with constant bitrate encoding [1],
these parameters will onl
> On Jun 5, 2024, at 5:23 AM, Niklas Haas wrote:
>
> On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt
> wrote:
>> Niklas Haas:
>>> From: Niklas Haas
>>>
>>> This code was unnecessarily trying to be robust against downgrades of
>>> libavutil (relative to the version libavcodec was compil
Test all four pixel formats, but only bench the two native endian ones for a
given target.
Signed-off-by: James Almer
---
tests/checkasm/sw_rgb.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
in
James Almer:
> uyvytoyuv422_c: 23991.8
> uyvytoyuv422_sse2: 2817.8
> uyvytoyuv422_avx: 2819.3
Why don't you nuke the avx version in a follow-up patch?
> uyvytoyuv422_avx2: 1972.3
>
> Signed-off-by: James Almer
> ---
> libswscale/x86/rgb2rgb.c | 6 ++
> libswscale/x86/rgb_2_rgb.asm | 3
James Almer:
> On 6/5/2024 5:10 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Test all four pixel formats, but only bench the two native endian
>>> ones for a
>>> given target.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> tests/checkasm/sw_rgb.c | 22 --
>>> 1 file cha
shuffle_bytes_2103_c: 46.5
shuffle_bytes_2103_mmxext: 29.3
shuffle_bytes_2103_sse2: 12.5
Signed-off-by: James Almer
---
libswscale/x86/rgb2rgb.c | 6 ++
libswscale/x86/rgb_2_rgb.asm | 30 +++---
2 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/lib
On 30/05/2024 20:43, averne wrote:
> To save on energy, the clock speed of multimedia engines should be adapted to
> their workload.
>
> Signed-off-by: averne
> ---
> libavutil/hwcontext_nvtegra.c | 165 ++
> libavutil/hwcontext_nvtegra.h | 7 ++
> 2 files chan
On 30/05/2024 20:43, averne wrote:
> This includes hwdevice and hwframes objects.
> As the multimedia engines work with tiled surfaces (block linear in nvidia
> jargon), two frame transfer methods are implemented.
> The first makes use of the VIC to perform the copy. Since some revisions of
> the
uyvytoyuv422_c: 23991.8
uyvytoyuv422_sse2: 2817.8
uyvytoyuv422_avx: 2819.3
uyvytoyuv422_avx2: 1972.3
Signed-off-by: James Almer
---
libswscale/x86/rgb2rgb.c | 6 ++
libswscale/x86/rgb_2_rgb.asm | 32
2 files changed, 30 insertions(+), 8 deletions(-)
dif
abgr_to_uv_8_c: 43.3
abgr_to_uv_8_sse2: 14.3
abgr_to_uv_8_avx: 15.3
abgr_to_uv_8_avx2: 18.8
abgr_to_uv_128_c: 650.3
abgr_to_uv_128_sse2: 110.8
abgr_to_uv_128_avx: 112.3
abgr_to_uv_128_avx2: 64.8
abgr_to_uv_1080_c: 5456.3
abgr_to_uv_1080_sse2: 888.8
abgr_to_uv_1080_avx: 900.8
abgr_to_uv_1080_avx2: 5
On 30/05/2024 20:43, averne wrote:
> This includes a new pixel format for nvtegra hardware frames, and several
> objects for interaction with hardware blocks.
> In particular, this contains code for channels (handles to hardware engines),
> maps (memory-mapped buffers shared with engines), and co
On 6/5/2024 5:10 PM, Andreas Rheinhardt wrote:
James Almer:
Test all four pixel formats, but only bench the two native endian ones for a
given target.
Signed-off-by: James Almer
---
tests/checkasm/sw_rgb.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff -
These only apply to obsolete drivers which do not work with the
now-required libva 2.x.
---
Fixed checkheaders.
libavutil/hwcontext_vaapi.c | 123 ++--
libavutil/hwcontext_vaapi.h | 17 +
2 files changed, 52 insertions(+), 88 deletions(-)
diff --git a/libavu
libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays. Various features no longer need any
configure check after this change, including all codecs except AV1.
Note that the libva version is the API version plus one, so this is
removing support for
On 6/5/2024 5:08 PM, Andreas Rheinhardt wrote:
The MMXEXT versions of the rgb2rgb functions tested here
always emit emms on their own. Therefore one can use
a stricter test to ensure that it stays that way.
Or we could nuke it in favor of an SSE2 version :p
Signed-off-by: Andreas Rheinhardt
James Almer:
> Test all four pixel formats, but only bench the two native endian ones for a
> given target.
>
> Signed-off-by: James Almer
> ---
> tests/checkasm/sw_rgb.c | 22 --
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/tests/checkasm/sw_rgb.c b/t
The MMXEXT versions of the rgb2rgb functions tested here
always emit emms on their own. Therefore one can use
a stricter test to ensure that it stays that way.
Signed-off-by: Andreas Rheinhardt
---
tests/checkasm/sw_rgb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff -
Test all four pixel formats, but only bench the two native endian ones for a
given target.
Signed-off-by: James Almer
---
tests/checkasm/sw_rgb.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b5
Rather than turning the constraint flags into a single profile and then
searching for that profile (and failing if it doesn't match any profile
exactly), instead search all supported profiles and use the first one
which supports the given set of constraint flags.
---
libavcodec/vaapi_decode.c | 45
---
libavcodec/Makefile | 2 +-
libavcodec/tests/.gitignore | 1 +
libavcodec/tests/h265_profiles.c | 440 +++
tests/fate/libavcodec.mak| 5 +
4 files changed, 447 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/tests/h265_pro
Replace existing get_profile() with find_profile(), which finds the
lowest compatible profile rather than requiring an exact match.
---
Now with an enum tag.
libavcodec/h265_profile_level.c | 80 +
libavcodec/h265_profile_level.h | 70 -
From: Thomas Siedel
Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,
passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configu
This patch is based on the latest patchset from Thomas Siedel
(thomas...@spin-digital.com).
The libvvenc patch has been changed with following changes:
avcodec: add external encoder libvvenc for H266/VVC
- sort includes alphabetically
- remove unneeded cast
- do not separate variables declaratio
Le lauantaina 1. kesäkuuta 2024, 11.03.55 EEST Rémi Denis-Courmont a écrit :
> The OS may silently fix (emulate) unaligned hardware access exceptions.
> This is extremely slow and code should be fixed not to rely on unaligned
> access on affected hardware. Accordingly this requests that the OS
> di
T-Head C908 (cycles):
vp8_idct_add_c: 312.2
vp8_idct_add_rvv_i32: 117.0
---
libavcodec/riscv/vp8dsp_init.c | 2 ++
libavcodec/riscv/vp8dsp_rvv.S | 59 ++
2 files changed, 61 insertions(+)
diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp
Offers a modest performance gain due to the switch from naive linear
probling to robin hood.
Signed-off-by: Connor Worley
---
libavcodec/dxvenc.c | 121
1 file changed, 33 insertions(+), 88 deletions(-)
diff --git a/libavcodec/dxvenc.c b/libavcodec/d
Signed-off-by: Connor Worley
---
libavutil/Makefile | 2 +
libavutil/hashtable.c | 192
libavutil/hashtable.h | 91 +
libavutil/tests/hashtable.c | 110 +
4 files changed, 395 insertions(+)
create mo
Signed-off-by: James Almer
---
tests/checkasm/sw_rgb.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index b51d0836c3..57bd6b20cd 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -187,11 +187,1
Michael - Sorry I missed your response on 5/15. I led the x265 project from
2013 to 2018, and I helped to define this feature, but I can't speak for the
x265 development team today. I could put you directly in touch with the x265
developers at Multicoreware to work this out. I will also encourag
On Tue, Jun 4, 2024 at 3:15 PM Ramiro Polla wrote:
>
> ---
> libswscale/x86/yuv_2_rgb.asm | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
> index e3470fd9ad..a1f9134e08 100644
> --- a/libswscale/x86/yuv_2
On Tue, Jun 4, 2024 at 2:54 PM Ramiro Polla wrote:
> On Thu, May 30, 2024 at 11:24 PM Sean McGovern wrote:
> > On Thu, May 30, 2024 at 5:20 PM Ramiro Polla wrote:
> > >
> > > ---
> > > libavcodec/libxvid.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/
---
libavcodec/aac/aacdec_usac.c | 105 +--
1 file changed, 63 insertions(+), 42 deletions(-)
diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 04dd5facff..561734f930 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec
On Wed, Jun 5, 2024 at 1:51 AM Michael Niedermayer
wrote:
> On Tue, Jun 04, 2024 at 03:05:35PM +0200, Ramiro Polla wrote:
> > ---
> > libavcodec/mpegvideo_enc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM
Pushed.
___
ffmpeg-devel
Previous rewrite from inline assembly into nasm (commit e934194) missed the
required EMMS instruction to bring the x87 FPU back into usable state.
Signed-off-by: Mario Hros
---
libswscale/x86/yuv_2_rgb.asm | 1 +
1 file changed, 1 insertion(+)
diff --git a/libswscale/x86/yuv_2_rgb.asm b/libsws
From: Zhao Zhili
The line width 8 is supposed to test corner case, while the
performance doesn't matter. Width 1080 is also a case of
unaligned to 16.
Width 1920 meant for benchmark (together with --runs options).
---
v2: add bgr24 support
Feel free to remove 128 and/or 1280 from input_sizes if
T-Head C908:
rgb24_to_uv_half_4_c: 2.0
rgb24_to_uv_half_4_rvv_i32: 3.5
rgb24_to_uv_half_64_c: 27.0
rgb24_to_uv_half_64_rvv_i32: 12.5
rgb24_to_uv_half_540_c: 223.7
rgb24_to_uv_half_540_rvv_i32: 105.2
rgb24_to_uv_half_640_c: 265.5
rgb24_to_uv_half_640_rvv_i32: 123.
T-Head C908:
rgb24_to_uv_8_c:2.7
rgb24_to_uv_8_rvv_i32: 3.2
rgb24_to_uv_128_c: 41.0
rgb24_to_uv_128_rvv_i32: 12.7
rgb24_to_uv_1080_c: 342.5
rgb24_to_uv_1080_rvv_i32: 105.7
rgb24_to_uv_1280_c: 406.0
rgb24_to_uv_1280_rvv_i32: 124.2
rgb24_to_uv_1920_c: 626.
T-Head C908:
rgb24_to_y_8_c:2.0
rgb24_to_y_8_rvv_i32: 2.7
rgb24_to_y_128_c: 26.2
rgb24_to_y_128_rvv_i32:9.2
rgb24_to_y_1080_c: 219.5
rgb24_to_y_1080_rvv_i32: 76.2
rgb24_to_y_1280_c: 276.2
rgb24_to_y_1280_rvv_i32: 89.7
rgb24_to_y_1920_c: 389.7
rgb24_t
On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:
This allows users to determine whether a stream is USAC or not.
---
libavcodec/aac/aacdec_usac.c | 4
libavcodec/avcodec.h | 1 +
libavcodec/defs.h| 1 +
libavcodec/profiles.c| 1 +
libavcodec/profiles.h
On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:
---
doc/APIchanges | 3 +++
libavcodec/version.h | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index e36a01336c..d9bec790a3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,
On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:
This makes it far easier to figure out which AOT belongs to which
profile.
Also, explicitly highlight the holes.
---
libavcodec/mpeg4audio.h | 82 +
1 file changed, 42 insertions(+), 40 deletions(-)
di
On 6/5/2024 12:08 AM, Lynne via ffmpeg-devel wrote:
The issue is that AOT 45 isn't defined anywhere, and looking at the git
blame, it seems to have sprung up through a reordering of the enum,
and adding a hole.
The spec does not define an explicit AOT for SBR and no SBR, and only
uses AOT 42 (pr
Le tiistaina 4. kesäkuuta 2024, 16.55.00 EEST Zhao Zhili a écrit :
> From: Zhao Zhili
>
> ---
> tests/checkasm/sw_rgb.c | 103
> 1 file changed, 103 insertions(+)
>
> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
> index 7cd815e5be..cc9b
On 6/4/2024 11:06 AM, Zhao Zhili wrote:
On Jun 4, 2024, at 21:58, James Almer wrote:
On 6/4/2024 10:55 AM, Zhao Zhili wrote:
From: Zhao Zhili
---
tests/checkasm/sw_rgb.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/checkasm/sw_rgb.
On Wed, Jun 05, 2024 at 09:46:16AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers
> wrote:
>
> > On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> > ffmpeg-de...@pileofstuff.org>
> > > wrote
this code is simple, you can combine it with the next one
On Wed, Jun 5, 2024 at 5:24 PM Frank Plowman wrote:
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/ps.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
> i
On Wed, Jun 5, 2024 at 3:44 PM Andrew Sayers
wrote:
> On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> ffmpeg-de...@pileofstuff.org>
> > wrote:
> >
> > > An external API developer might think they can use AVOptions to modify
> > >
Hi Frank,
Thank you for the patch
On Wed, Jun 5, 2024 at 5:24 PM Frank Plowman wrote:
> On the top of p. 112 in VVC (09/2023):
>
> It is a requirement of bitstream conformance that the values of
> qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
> of −QpBdOffset to 63, inclusive fo
Hi,
On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers
wrote:
> On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> ffmpeg-de...@pileofstuff.org>
> > wrote:
> >
> > > An external API developer might think they can use AVOptions to modify
>
On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers
> wrote:
>
> > An external API developer might think they can use AVOptions to modify
> > values
> > during playback (e.g. putting a playback quality slider next to the volume
> > slider).
On Wed, Jun 5, 2024 at 11:31 AM Rémi Denis-Courmont wrote:
>
>
> Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont"
> a écrit :
> >But by reacting *only* to Vittorio trying to defend himself and
> explicitly (and ineffectively) asking for help from the CC, you look like
> you are attacking
On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers
wrote:
> An external API developer might think they can use AVOptions to modify
> values
> during playback (e.g. putting a playback quality slider next to the volume
> slider). Make it clear that behaviour is not recommended.
>
There are options that
Stefano Sabatini:
> On date Wednesday 2024-06-05 13:14:01 +0200, Andreas Rheinhardt wrote:
>> Stefano Sabatini:
> [...]
One does not need two checks as long as int is 32 bits (because then one
can just perform the addition in 64bits).
>>>
>>> sizeof(int) is not defined by the C standard,
On date Wednesday 2024-06-05 13:14:01 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
[...]
> >> One does not need two checks as long as int is 32 bits (because then one
> >> can just perform the addition in 64bits).
> >
> > sizeof(int) is not defined by the C standard, so you cannot assume i
An external API developer might think they can use AVOptions to modify values
during playback (e.g. putting a playback quality slider next to the volume
slider). Make it clear that behaviour is not recommended.
Include the warning in the group description and the text for every function
that sets
In USAC, we set the max to 64.
---
libavcodec/aac.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 9508760fa6..fc6d1361b2 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -31,7 +31,7 @@
#define AVCODEC_AAC_H
#define MAX_CHAN
On 05/06/2024 07:33, Andreas Rheinhardt wrote:
Lynne via ffmpeg-devel:
This allows users to determine whether a stream is USAC or not.
---
libavcodec/aac/aacdec_usac.c | 4
libavcodec/avcodec.h | 1 +
libavcodec/defs.h| 1 +
libavcodec/profiles.c| 1 +
liba
Note: I somehow managed to send this message directly to Anton before - sorry
Anton for the message spam, please reply to this one if you want the list to
see it!
On Wed, Jun 05, 2024 at 10:12:47AM +0200, Anton Khirnov wrote:
> Quoting Andrew Sayers (2024-06-04 16:47:23)
> > The goal of putting th
On Wed, Jun 05, 2024 at 12:34:48PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2024-06-04 15:47:22 +0100, Andrew Sayers wrote:
> > + * Structs that only use logging facilities are often referred to as
> > + * "AVClass context structures", while those that provide configuration
> > + * options
It is unnecessary to first pad to 32bits; the memset later
will pad everything will with zeroes anyway.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dnxhdenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 4760a2932c..028604a6e5 1006
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dnxhdenc.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 0cb25d7714..4760a2932c 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhde
On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > This code was unnecessarily trying to be robust against downgrades of
> > libavutil (relative to the version libavcodec was compiled against), but
> > in the process, ended up with very bri
Andreas Rheinhardt:
> This is the VVC version of 8b5d15530127fea54e934043a64653859de07353.
>
> (Hint: This ensures that the order of NALU arrays is OPI-VPS-SPS-PPS-
> Prefix-SEI-Suffix-SEI, regardless of the order in the original
> extradata. I hope this is right.)
>
> Signed-off-by: Andreas Rhei
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)
This results in a file
H266RawSliceHeader.num_entry_points is an uint32_t.
Fixes -Wformat warnings:
https://fate.ffmpeg.org/log.cgi?slot=aarch64-osx-clang-1200.0.32.29&time=20240604151047&log=compile
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h266_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 d
Fixes -Wformat warnings; see e.g.
https://fate.ffmpeg.org/log.cgi?slot=aarch64-osx-clang-1200.0.32.29&time=20240604151047&log=compile
Signed-off-by: Andreas Rheinhardt
---
libavformat/evc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/evc.c b/libavforma
Signed-off-by: Andreas Rheinhardt
---
libavformat/vvc.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavformat/vvc.c b/libavformat/vvc.c
index 819ee02e2c..3821de7812 100644
--- a/libavformat/vvc.c
+++ b/libavformat/vvc.c
@@ -527,17 +527,17 @@ stat
This is the VVC version of 8b5d15530127fea54e934043a64653859de07353.
(Hint: This ensures that the order of NALU arrays is OPI-VPS-SPS-PPS-
Prefix-SEI-Suffix-SEI, regardless of the order in the original
extradata. I hope this is right.)
Signed-off-by: Andreas Rheinhardt
---
libavformat/vvc.c | 1
There is no benefit in using it: The fast path of copying
is not taken because of misalignment; furthermore we are
only dealing with a few byte here anyway, so simply copy
the bytes manually, avoiding the dependency on bitstream.c
in lavf (which also contains a function that is completely
unused in
The PutBitContext has just been flushed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/vvc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/vvc.c b/libavformat/vvc.c
index ac3209a01b..d8195f0fd2 100644
--- a/libavformat/vvc.c
+++ b/libavformat/vvc.c
@@ -761,7
If any of these files (say A) would be changed in such a way
that A acquires a new dependency on another file B, building B
would need to be added to all the rules that lead to A being built.
Yet currently the rules for several files are spread over
the lavc Makefile and the Makefile of the lavc/he
Stefano Sabatini:
> On date Wednesday 2024-06-05 12:02:08 +0200, Andreas Rheinhardt wrote:
>> Stefano Sabatini:
>>> On date Tuesday 2024-06-04 17:28:35 -0500, Marcus B Spencer wrote:
> [...]
+#define HEADER_SIZE 16
+
+static int farbfeld_encode_frame(AVCodecContext *ctx, AVPacket *pk
On date Wednesday 2024-06-05 12:02:08 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > On date Tuesday 2024-06-04 17:28:35 -0500, Marcus B Spencer wrote:
[...]
> >> +#define HEADER_SIZE 16
> >> +
> >> +static int farbfeld_encode_frame(AVCodecContext *ctx, AVPacket *pkt,
> >> +
On Mon, 3 Jun 2024 at 23:41, James Almer wrote:
>
> On 6/3/2024 6:32 PM, Michael Niedermayer wrote:
> > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> >> On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> >>> On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> O
On date Tuesday 2024-06-04 15:47:22 +0100, Andrew Sayers wrote:
> ---
> libavutil/log.h | 16 +---
> libavutil/opt.h | 26 +-
> 2 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/libavutil/log.h b/libavutil/log.h
> index ab7ceabe22..88b35897c6 1
Niklas Haas:
> From: Niklas Haas
>
> This code was unnecessarily trying to be robust against downgrades of
> libavutil (relative to the version libavcodec was compiled against), but
> in the process, ended up with very brittle code that is easy to
> accidentally forget to update when adding new f
From: Niklas Haas
This code was unnecessarily trying to be robust against downgrades of
libavutil (relative to the version libavcodec was compiled against), but
in the process, ended up with very brittle code that is easy to
accidentally forget to update when adding new fields.
Instead, do the o
Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont" a
écrit :
>But by reacting *only* to Vittorio trying to defend himself and explicitly
>(and ineffectively) asking for help from the CC, you look like you are
>attacking the victim and defending the troll.
I should have said "the one do
On the top of p. 112 in VVC (09/2023):
It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..bfc3c121fd 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -186,8 +186,11 @@ static int sps_der
Hi,
On 05.06.24 09:34, Marton Balint wrote:
On Tue, 4 Jun 2024, Ronald S. Bultje wrote:
Hi all,
Anton resigned from the CC [1], leaving an empty spot. The remaining
members of the CC agreed it would be best to fill the spot with the next
runner-up from the last CC Elections.
The last CC ele
Le 5 juin 2024 10:20:47 GMT+03:00, Marton Balint a écrit :
>
>
>On Tue, 4 Jun 2024, Vittorio Giovara wrote:
>
>>> If you stop responding with mails on all FFmpeg mailing lists from now to
>>> indefinite time in future nothing of value would be lost.
>>>
>>
>> Please reread what you wrote and a
On the top of p. 112 in VVC (09/2023):
It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_
Quoting Marton Balint (2024-06-03 23:48:47)
> The very old behaviour of -channel_layout was to simply warn the user about
> channel layouts which does not have a matching channel count, and ignore them,
> instead of reporting an error.
>
> The recent fix re-added support for overriding -channel_la
On Tue, 4 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_1080_c: 7.2
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.2
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5
rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_
Quoting Andrew Sayers (2024-06-04 16:47:21)
> Derived from explanations kindly provided by Stefano Sabatini and others:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325903.html
> ---
> doc/context.md | 430 +
> 1 file changed, 430 insertion
Quoting Andrew Sayers (2024-06-04 16:47:23)
> The goal of putting these links in "@see" blocks is to provide hooks
> for future developers to add links to other useful parts of the codebase.
> ---
> libavcodec/avcodec.h | 3 +++
> libavcodec/bsf.h | 3 +++
> libavcodec/
1 - 100 of 106 matches
Mail list logo
