Hi
On Mon, Mar 24, 2025 at 02:53:27AM +0100, Michael Niedermayer wrote:
> Hi Jerome
>
> On Sat, Mar 22, 2025 at 06:54:25PM +0100, Jerome Martinez wrote:
> > Le 22/03/2025 à 18:45, Michael Niedermayer a écrit :
> > > [...]
> > > Also I failed to find any worthy gain from adjusting mul_count so
> >
Hi Jerome
On Sat, Mar 22, 2025 at 06:54:25PM +0100, Jerome Martinez wrote:
> Le 22/03/2025 à 18:45, Michael Niedermayer a écrit :
> > [...]
> > Also I failed to find any worthy gain from adjusting mul_count so
> > while the code in the encoder looks complex ATM alot of that can be
> > dropped late
On Fri, Mar 21, 2025 at 11:22:45PM +0100, Michael Niedermayer wrote:
> On Fri, Mar 21, 2025 at 10:36:58PM +0100, Michael Niedermayer wrote:
> > On Fri, Mar 21, 2025 at 10:12:50PM +0100, Michael Niedermayer wrote:
> > > Hi
> > >
> > > On Fri, Mar 21, 2025 at 09:13:49PM +0100, Michael Niedermayer wr
ATM this performs as well or better as any other algorithm tried.
Its simple for the decoder.
On the encoder side complexity depends on how parameters are
choosen. But with a fixed mul_count of 1 and basic heuristic
it performs as well as any more complex choice i tried so far.
The encoder code he
Le 22/03/2025 à 18:45, Michael Niedermayer a écrit :
[...]
Also I failed to find any worthy gain from adjusting mul_count so
while the code in the encoder looks complex ATM alot of that can be
dropped later if for example we choose to never put mul_count > 1 into
the specification and ATM it make
On Fri, Mar 21, 2025 at 10:36:58PM +0100, Michael Niedermayer wrote:
> On Fri, Mar 21, 2025 at 10:12:50PM +0100, Michael Niedermayer wrote:
> > Hi
> >
> > On Fri, Mar 21, 2025 at 09:13:49PM +0100, Michael Niedermayer wrote:
> > > On Fri, Mar 21, 2025 at 12:07:30AM +0100, Lynne wrote:
> > > > On 20
On Fri, Mar 21, 2025 at 10:12:50PM +0100, Michael Niedermayer wrote:
> Hi
>
> On Fri, Mar 21, 2025 at 09:13:49PM +0100, Michael Niedermayer wrote:
> > On Fri, Mar 21, 2025 at 12:07:30AM +0100, Lynne wrote:
> > > On 20/03/2025 23:30, Michael Niedermayer wrote:
> > > > This performs about as good as
Hi
On Fri, Mar 21, 2025 at 09:13:49PM +0100, Michael Niedermayer wrote:
> On Fri, Mar 21, 2025 at 12:07:30AM +0100, Lynne wrote:
> > On 20/03/2025 23:30, Michael Niedermayer wrote:
> > > This performs about as good as the non LRU system for 16bit and
> > > better than then the LRU system for 16 co
On Fri, Mar 21, 2025 at 12:07:30AM +0100, Lynne wrote:
> On 20/03/2025 23:30, Michael Niedermayer wrote:
> > This performs about as good as the non LRU system for 16bit and
> > better than then the LRU system for 16 converted to 32. So
> > its basically performing best in all cases we have atm maki
On 20/03/2025 23:30, Michael Niedermayer wrote:
This performs about as good as the non LRU system for 16bit and
better than then the LRU system for 16 converted to 32. So
its basically performing best in all cases we have atm making
the LRU system unneeded.
Test on *real* 32-bit content, please
This performs about as good as the non LRU system for 16bit and
better than then the LRU system for 16 converted to 32. So
its basically performing best in all cases we have atm making
the LRU system unneeded.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ff
11 matches
Mail list logo
