With 16bit float rawlsb 2 gives 0.66% better compression. This is maybe due
to the quantization tables being tuned to smaller number of bits
rawlsb 4 is about 30% faster than 0 and about 1% worse compression
Above was tested using ACES_OT_VWG_SampleFrames
Signed-off-by: Michael Niedermayer
---
On Tue, 4 Mar 2025 09:56:20 -0600, Kieran Kunhya via ffmpeg-devel wrote:
> >
> > Nevertheless, the CC does issue a warning regarding unnecessarily
> > offensive recent comments by Kieran on other topics, as well as for
> > initially failing to provide background and context regarding Paul’s
> > ac
Hi Jerome
On Thu, Mar 06, 2025 at 10:20:58PM +0100, Jerome Martinez wrote:
> Le 06/03/2025 à 17:37, Michael Niedermayer a écrit :
> > On Thu, Mar 06, 2025 at 03:14:49AM +0100, Lynne wrote:
> > > On 06/03/2025 01:15, Michael Niedermayer wrote:
> > > > Hi everyone
> > > >
> > > > Current FFv1 code
Hi Traneptora
On Thu, Mar 06, 2025 at 01:17:30PM -0500, Leo Izen wrote:
> On 3/6/25 11:37 AM, Michael Niedermayer wrote:
> > Hi
> > >
> > > I did mention this once before, but you should look into the Daala/Opus
> > > way
> > > of storing rawbits into a separate chunk at the end of the bitstream
I think you were looking at an older version of the patch. Newer version
didn't have this. Anyhow, there's a new version I uploaded (v3).
On Thu, Feb 27, 2025 at 6:31 PM Lynne wrote:
> On 25/02/2025 22:37, Pranav Kant via ffmpeg-devel wrote:
> > By default, all globals in C/C++ compiled by clang
I uploaded a new patch (v3) that addresses these concerns.
On Thu, Feb 27, 2025 at 5:14 PM Michael Niedermayer
wrote:
> On Wed, Feb 26, 2025 at 07:44:37PM +, Pranav Kant via ffmpeg-devel
> wrote:
> > By default, all globals in C/C++ compiled by clang are allocated
> > in non-large data secti
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Donnerstag, 6. März 2025 18:05
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2 0/3] avutil/log: Replace addresses
> in log output with simple ids
>
>
>
> > -Origi
Hello everybody,
this is not the kind of e-mail you might be expecting from the title. I think
we had enough of those. Nobody will be blamed; nobody will be criticized. This
is meant to address everybody equally, specifically not meant to be supportive
of those who had brought up doubts about t
> The core procedure in the CC operations is designed as follows:
>
> - A community member X can file a complaint to the CC about
> inappropriate behavior of another user Y
Erratum: the word "privately" got lost: "..can privately file.."
___
ffmpeg-
Soft Works (HE12025-03-05):
> Sorry. So - seriously: what would be your recipe then?
I see not just a little of non-trivial code for a very minor feature,
that might be a hint that it would be best to let it go.
Also, if somebody is debugging a program using the libraries, the
pointers are releva
ffmpegagent (HE12025-03-05):
> Cc: softworkz , Soft Works
> , Nicolas George ,
> Gyan Doshi
Please do not Cc people who did not ask for it. Especially when headers
say not to.
> Date: Wed, 05 Mar 2025 18:19:40 +
> From: ffmpegagent
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [
On 3/6/2025 11:50 AM, Andreas Rheinhardt wrote:
Can't you add a new parameter nb_elems to also handle all the side data
that only has a single array? This would then also cover
AV_FRAME_DATA_REGIONS_OF_INTEREST, AV_FRAME_DATA_VIDEO_ENC_PARAMS,
AV_FRAME_DATA_DETECTION_BBOXES, AV_FRAME_DATA_VIDEO_H
Signed-off-by: James Almer
---
libavcodec/exr.c | 70 +++-
tests/ref/fate/exr-ya-scanline-zip-half-12x8 | 2 +-
2 files changed, 25 insertions(+), 47 deletions(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b25e9ef397..4482f104d0 100644
---
Andreas Rheinhardt:
> Ramiro Polla:
>> On Tue, Mar 4, 2025 at 6:05 PM Andreas Rheinhardt
>> wrote:
>>> Ramiro Polla:
On 3/4/25 14:42, Andreas Rheinhardt wrote:
> (Mostly trivial) patches attached. A branch is at
> https://github.com/mkver/FFmpeg/tree/mpegvideo_misc
Patches attached
- Andreas
From 7453c8ca973d886914cba7535a1a0835e9ae4f81 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Thu, 6 Mar 2025 16:00:12 +0100
Subject: [PATCH 1/2] avcodec/sbcenc: Mark sbc_encode_init() as av_cold
Signed-off-by: Andreas Rheinhardt
---
libavcodec/sbcenc.c | 2 +
On 6 Mar 2025, at 20:27, Soft Works wrote:
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Marvin
>> Scholz
>> Sent: Donnerstag, 6. März 2025 19:59
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log
>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marvin
> Scholz
> Sent: Donnerstag, 6. März 2025 21:02
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log
> output with simple ids
>
>
>
> On 6 Mar 2025, at
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Donnerstag, 6. März 2025 11:09
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log
> output with simple ids
>
> Soft Works (HE12025-0
From: softworkz
---
doc/fftools-common-opts.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index f6d452c40e..756c843c02 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -230,6 +230,8 @@ log to
Le 06/03/2025 à 19:17, Leo Izen a écrit :
May also be worth considering the JPEG XL way, where each
entropy-coded symbol is a "hybrid integer" of a token read from the
entropy stream (ANS) followed by zero or more "raw bits" that are
spliced in.
I would keep FFV1 away from ANS in the next 15
On Wed, Mar 05, 2025 at 09:59:34PM +0530, MihirGore wrote:
> From: MihirGore23
>
Hi,
comments below.
> ---
> libavcodec/vpx_rac.h | 75 ++--
> 1 file changed, 59 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/vpx_rac.h b/libavcodec/vpx_rac.
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marvin
> Scholz
> Sent: Donnerstag, 6. März 2025 18:49
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log
> output with simple ids
>
>
>
> On 6 Mar 2025, at
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Donnerstag, 6. März 2025 17:43
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2 0/3] avutil/log: Replace addresses
> in log output with simple ids
>
> Soft Works (HE
From: softworkz
also adds a log flag AV_LOG_PRINT_MEMADDRESSES, which is meant to
control prefix formatting. The actual formatting has to be performed
by the consuming application which needs to provide a formatting
callback via av_log_set_formatprefix_callback.
Signed-off-by: softworkz
---
do
..and individual numbering. The benefits are:
* Smaller log file sizes
* The disambiguation is much easier to recognize and to follow
* It eventually allows comparing and viewing log file diffs without almost
every line being different due to those addresses
Before
==
[hevc @ 018e
From: softworkz
This commit adds the memaddresses log flag.
When specifying this flag at the command line, context prefixes will
be printed with memory addresses like in earlier ffmpeg versions.
Example with memaddresses flag:
[hevc @ 018e72a89cc0] .
without (new behavior):
[hevc #0]
> -Original Message-
> From: ffmpeg-devel On Behalf Of Marvin
> Scholz
> Sent: Donnerstag, 6. März 2025 18:38
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log
> output with simple ids
>
>
>
> On 6 Mar 2025, at
Signed-off-by: James Almer
---
Untested as i don't have a camera that outputs this, and no decoder or filter
seems to generate it either, but it seemed simple enough to write.
Anyone that can use the libdc1394 device and test would be welcome.
libswscale/input.c | 23 +++
li
On 3/6/25 11:37 AM, Michael Niedermayer wrote:
Hi
I did mention this once before, but you should look into the Daala/Opus way
of storing rawbits into a separate chunk at the end of the bitstream. It
avoids polluting the range context with equiprobable bits.
I didnt like it, but it seems more
29 matches
Mail list logo
