Le 1 juin 2024 00:06:49 GMT+03:00, averne a écrit :
>Le 30/05/2024 à 22:38, Rémi Denis-Courmont a écrit :
>> Le torstaina 30. toukokuuta 2024, 22.43.03 EEST averne a écrit :
>>> This is useful eg. for memory-mapped buffers that need page-aligned memory,
>>> when dealing with hardware devices
>>>
Le 1 juin 2024 04:03:37 GMT+03:00, James Almer a écrit :
>On 5/31/2024 3:18 PM, Rémi Denis-Courmont wrote:
>> ---
>> tests/checkasm/aacencdsp.c | 37 +
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacen
On 5/31/2024 3:18 PM, Rémi Denis-Courmont wrote:
---
tests/checkasm/aacencdsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacencdsp.c
index 1756c4ecd5..756f92fd8f 100644
--- a/tests/checkasm/aacencdsp.
Billy O'Neal (VC AIR) via ffmpeg-devel:
> Resolves the following compiler error on macOS 14.5:
>
> ```console
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl3.h:1891:21:
> note: 'glShaderSource' has been explicitly marked deprecated
On Thu, May 23, 2024 at 03:17:52AM +0200, Michael Niedermayer wrote:
> Fixes: CID1503075 Unintentional integer overflow
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavdevice/pulse_audio_enc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-
On Fri, May 31, 2024 at 11:06:49PM +0200, averne wrote:
> Le 30/05/2024 à 22:38, Rémi Denis-Courmont a écrit :
> > Le torstaina 30. toukokuuta 2024, 22.43.03 EEST averne a écrit :
> >> This is useful eg. for memory-mapped buffers that need page-aligned memory,
> >> when dealing with hardware device
On 31.05.2024 23:06, averne wrote:
Le 30/05/2024 à 22:42, Rémi Denis-Courmont a écrit :
Le torstaina 30. toukokuuta 2024, 22.43.05 EEST averne a écrit :
These files are taken with minimal modifications from nvidia's Linux4Tegra
(L4T) tree. nvmap enables management of memory-mapped buffers for h
Le 31/05/2024 à 10:32, Rémi Denis-Courmont a écrit :
>
>
> Le 30 mai 2024 22:43:07 GMT+03:00, averne a écrit :
>> 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
Le 30/05/2024 à 22:38, Rémi Denis-Courmont a écrit :
> Le torstaina 30. toukokuuta 2024, 22.43.03 EEST averne a écrit :
>> This is useful eg. for memory-mapped buffers that need page-aligned memory,
>> when dealing with hardware devices
>>
>> Signed-off-by: averne
>> ---
>> libavutil/buffer.c | 3
Le 30/05/2024 à 22:42, Rémi Denis-Courmont a écrit :
> Le torstaina 30. toukokuuta 2024, 22.43.05 EEST averne a écrit :
>> These files are taken with minimal modifications from nvidia's Linux4Tegra
>> (L4T) tree. nvmap enables management of memory-mapped buffers for hardware
>> devices. nvhost enab
Le 30/05/2024 à 22:37, Rémi Denis-Courmont a écrit :
> Le torstaina 30. toukokuuta 2024, 22.43.04 EEST averne a écrit :
>> HorizonOS (HOS) is the operating system of the Nintendo Switch.
>> This patch enables integration with the homebrew toolchain developped by the
>> devkitPro team. Its two main
Michael Niedermayer:
> On Fri, May 31, 2024 at 12:01:56AM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Thu, May 30, 2024 at 09:33:51PM +0200, Andreas Rheinhardt wrote:
Michael Niedermayer:
> On Thu, May 30, 2024 at 08:07:48PM +0200, Andreas Rheinhardt wrote:
>> Micha
On Wed, May 29, 2024 at 02:06:07PM +0200, Gerion Entrup wrote:
> Actually, the jaccard distance is defined as D = 1 - intersect / union.
> Additionally, the distance value is compared against a constant that
> must be between 0 and 1, which is not the case here. Both facts together
> has led to the
On Fri, May 31, 2024 at 12:01:56AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, May 30, 2024 at 09:33:51PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, May 30, 2024 at 08:07:48PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> >
Signed-off-by: James Almer
---
libavutil/x86/float_dsp.asm| 52 ++
libavutil/x86/float_dsp_init.c | 5
2 files changed, 57 insertions(+)
diff --git a/libavutil/x86/float_dsp.asm b/libavutil/x86/float_dsp.asm
index e84ba52566..e9816cdf02 100644
--- a/liba
Le perjantaina 31. toukokuuta 2024, 22.28.03 EEST Lynne via ffmpeg-devel a
écrit :
> > Frankly, this test has outlived its usefulness for my purposes and I have
> > had
enough rebasing it again and again and again and again and again due
> > to mostly external problems. As far as I am concerned,
On 5/31/2024 2:51 PM, Rémi Denis-Courmont wrote:
---
tests/checkasm/lpc.c | 57 ++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
index 592e34c03d..62232fdaf7 100644
--- a/tests/checkasm/lpc.c
On 31/05/2024 20:29, Rémi Denis-Courmont wrote:
Le perjantaina 31. toukokuuta 2024, 21.23.43 EEST Lynne via ffmpeg-devel a
écrit :
Please don't randomize the length in tests. Pick a few lengths to check
all corner cases.
Checkasm tests should be deterministic in how long it takes to run them
bet
T-Head C908:
quant_bands_signed_c:576.0
quant_bands_signed_rvv_f32: 48.7
quant_bands_unsigned_c: 414.2
quant_bands_unsigned_rvv_f32: 31.7
SpacemiT X60:
quant_bands_signed_c:497.7
quant_bands_signed_rvv_f32: 23.0
quant_bands_unsigned_c: 353.5
quant_bands_unsigned_rvv_f
On Fri, May 31, 2024 at 7:49 PM Anton Khirnov wrote:
> ---
> libavcodec/hevc/hevcdec.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/hevc/hevcdec.h b/libavcodec/hevc/hevcdec.h
> index 8208268460..33ad4ac0aa 100644
> --- a/libavcodec/hevc/hevcdec.h
> +++ b/libavcodec/hevc/
Resolves the following compiler error on macOS 14.5:
```console
/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl3.h:1891:21:
note: 'glShaderSource' has been explicitly marked deprecated here
GLAPI void APIENTRY glShaderSource (GLuint sh
Le perjantaina 31. toukokuuta 2024, 21.18.12 EEST Rémi Denis-Courmont a écrit
:
> ---
> tests/checkasm/aacencdsp.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacencdsp.c
> index 1756c4ecd5..756f92fd8
Le perjantaina 31. toukokuuta 2024, 21.23.43 EEST Lynne via ffmpeg-devel a
écrit :
> Please don't randomize the length in tests. Pick a few lengths to check
> all corner cases.
> Checkasm tests should be deterministic in how long it takes to run them
> between invocations.
I agree, but that pro
On 31/05/2024 20:18, Rémi Denis-Courmont wrote:
---
tests/checkasm/aacencdsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacencdsp.c
index 1756c4ecd5..756f92fd8f 100644
--- a/tests/checkasm/aacencdsp.c
On 31/05/2024 19:51, Rémi Denis-Courmont wrote:
---
tests/checkasm/lpc.c | 57 ++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
index 592e34c03d..62232fdaf7 100644
--- a/tests/checkasm/lpc.c
---
tests/checkasm/aacencdsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacencdsp.c
index 1756c4ecd5..756f92fd8f 100644
--- a/tests/checkasm/aacencdsp.c
+++ b/tests/checkasm/aacencdsp.c
@@ -22,7 +22,9 @@
---
tests/checkasm/lpc.c | 57 ++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
index 592e34c03d..62232fdaf7 100644
--- a/tests/checkasm/lpc.c
+++ b/tests/checkasm/lpc.c
@@ -16,6 +16,7 @@
* 51
It is merely a pointer to local_ctx[0], which we can just as well use
directly.
---
libavcodec/hevcdec.c | 24 ++--
libavcodec/hevcdec.h | 2 --
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 0a9443505a..75d0e
Since it stores a pointer to the current frame.
---
libavcodec/dxva2_hevc.c| 12 +++---
libavcodec/hevc_filter.c | 34 -
libavcodec/hevc_mvs.c | 20 +-
libavcodec/hevc_refs.c | 18 -
libavcodec/hevcdec.c | 68
---
libavcodec/hevc/hevcdec.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.h b/libavcodec/hevc/hevcdec.h
index 8208268460..33ad4ac0aa 100644
--- a/libavcodec/hevc/hevcdec.h
+++ b/libavcodec/hevc/hevcdec.h
@@ -456,9 +456,6 @@ typedef struct HEVCContext {
uint8_
---
libavcodec/Makefile | 12 ++-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 2 +-
libavcodec/arm/hevcdsp_arm.h | 2 +-
libavcodec/arm/hevcdsp_init_arm.c | 2 +-
libavcodec/arm/hevcdsp_init_neon.c| 2 +-
libavcodec/bsf
---
libavcodec/hevc/hevcdec.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 4a07fa6612..4e0df4d033 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -298
It is merely a redundant pointer to cur_frame->f
---
libavcodec/hevc_cabac.c| 4 +--
libavcodec/hevc_filter.c | 39 +++--
libavcodec/hevc_refs.c | 3 +-
libavcodec/hevcdec.c | 53 +-
libavcodec/hevcdec.h
This is shorter, loses no information, and is consistent with other
similar structs.
---
libavcodec/dxva2_hevc.c | 8 +++
libavcodec/hevc_refs.c | 34 +--
libavcodec/hevcdec.c | 50
libavcodec/hevcdec.h | 2 +-
libav
hls_slice_data_wpp() is only called when num_entry_point_offsets>0
---
libavcodec/hevcdec.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index ad2cbd7ece..d3715f9de7 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcode
Will be useful in the following commit.
---
libavcodec/hevcdec.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index d3715f9de7..42fd33961b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -975,8
In all HEVCLocalContext instances except the first one, the bitreader is
never used for actually reading bits, but merely for passing the buffer
to ff_init_cabac_decoder(), which is better done directly.
The instance that actually is used for bitreading gets moved to stack in
decode_nal_unit(), wh
Do it in hls_slice_header() rather than cabac_init_decoder() - the
former is a more logical place as according the spec the byte alignment
is a part of the slice header, not slice data. Avoids a second instance
of alignment handling in vaapi_hevc.
Also, check that alignment_bit_equal_to_one is, in
Frank Plowman:
> The picture arrays are not initialised at the same time as the frame
> context itself, but rather when the relevant frame begins being decoded.
> As such, situations can arise where the frame context is being freed but
> the picture arrays have not yet been initialised. This could
On 2024-05-31 09:07 pm, Pierre-Anthony Lemieux wrote:
On Fri, May 31, 2024 at 8:32 AM Gyan Doshi wrote:
Decoding is no longer possible as the decoder wrapper was removed
in 60ccb3fe78
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
in
On Fri, May 31, 2024 at 8:32 AM Gyan Doshi wrote:
>
> Decoding is no longer possible as the decoder wrapper was removed
> in 60ccb3fe78
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 96b181fd21..6c5b8aab9a 100755
> --- a/co
Decoding is no longer possible as the decoder wrapper was removed
in 60ccb3fe78
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 96b181fd21..6c5b8aab9a 100755
--- a/configure
+++ b/configure
@@ -253,7 +253,7 @@ External library support:
tor 2024-05-30 klockan 20:49 +0300 skrev Rémi Denis-Courmont:
> Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit
> > It is not a "theoretical" UB - that's not how UB works.
>
> It is a *theoretical* UB if you can not prove that it leads to
> misbehaviour in
> any *practical*
fre 2024-05-31 klockan 02:22 +0200 skrev Michael Niedermayer:
> On Thu, May 30, 2024 at 12:15:27AM +0200, Tomas Härdin wrote:
> > This doesn't really fix anything, it just makes the value analysis
> > easier. I don't feel strongly about it.
>
> if it doesnt fix anything and it doesnt make the code
On 31/05/2024 15:39, Jan Ekström wrote:
On Thu, May 30, 2024 at 5:39 AM Lynne via ffmpeg-devel
wrote:
apichanges will be updated upon merging, as well as a version bump.
---
libavutil/channel_layout.c | 4
libavutil/channel_layout.h | 8
2 files changed, 12 insertions(+)
dif
On Thu, May 30, 2024 at 5:39 AM Lynne via ffmpeg-devel
wrote:
>
> apichanges will be updated upon merging, as well as a version bump.
> ---
> libavutil/channel_layout.c | 4
> libavutil/channel_layout.h | 8
> 2 files changed, 12 insertions(+)
>
> diff --git a/libavutil/channel_layo
The picture arrays are not initialised at the same time as the frame
context itself, but rather when the relevant frame begins being decoded.
As such, situations can arise where the frame context is being freed but
the picture arrays have not yet been initialised. This could lead to
various UB and
Le 31 mai 2024 15:39:35 GMT+03:00, James Almer a écrit :
>Signed-off-by: James Almer
>---
> libavcodec/lpc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
>index dfd6114690..e793e54038 100644
>--- a/libavcodec/lpc.c
>+++ b/libavc
Signed-off-by: James Almer
---
libavcodec/lpc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
index dfd6114690..e793e54038 100644
--- a/libavcodec/lpc.c
+++ b/libavcodec/lpc.c
@@ -120,9 +120,8 @@ static void lpc_compute_autocorr_c(con
On Fri, 31 May 2024, Timo Rothenpieler wrote:
On 31/05/2024 10:53, Martin Storsjö wrote:
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
On 31/05/2024 10:53, Martin Storsjö wrote:
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
On Wed, May 29, 2024 at 10:03 PM James Almer wrote:
> They will be filled immediately after.
>
Pushed.
thank you, James
>
> Signed-off-by: James Almer
> ---
> tests/checkasm/vvc_mc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/tests/checkasm/vvc_mc.c b/tests/checkasm/vvc_mc.c
>
On Fri, May 31, 2024 at 2:29 AM Ronald S. Bultje wrote:
> Hi,
>
> On Thu, May 30, 2024 at 12:28 PM wrote:
>
> > From: Wu Jianhua
> >
> > Some tests fails with certain seeds
> >
> > tests/checkasm/checkasm 2325607578 --test=vvc_alf
> > checkasm: using random seed 2325607578
> > AVX2:
> > vvc
On Fri, May 31, 2024 at 4:49 AM Ronald S. Bultje wrote:
> Hi Andreas,
>
> On Thu, May 30, 2024 at 2:33 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
> > toq...@outlook.com:
> > > From: Wu Jianhua
> > >
> > > Some tests fails with certain seeds
> > >
> > > tests/checkasm/chec
On Thu, May 16, 2024 at 12:59:05PM +0100, Andrew Sayers wrote:
> On Thu, May 16, 2024 at 01:42:23PM +0300, Rémi Denis-Courmont wrote:
> > Err, please. Keep this to the Windows back-end. Nothing good is going to
> > happen with a function that does nothing (on other platforms) and has a
> > nondes
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
Le 30 mai 2024 22:43:07 GMT+03:00, averne a écrit :
>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
Quoting James Almer (2024-05-27 16:11:13)
> On 5/27/2024 5:15 AM, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-04-27 02:36:23)
> >> This allows detecting issues in side data related code, same as what
> >> framecrc does for before already for packet data itself.
> >>
> >> Signed-off-b
Quoting Michael Niedermayer (2024-05-27 20:11:05)
> If you block this solution without providing another solution
> then i will bring this to the technical committee, to seek its guidance
> on the way forward.
The solution is to use a tool appropriate for the purpose, like ffprobe.
--
Anton Khir
59 matches
Mail list logo
