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 with my patchset supports 16bit floats. The implementation
is quite simple. Which is good
I have tried impr
Hi
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 with my patchset supports 16bit floats. The implementation
> > is quite simple. Which is good
> >
> > I have tried improving compression, the gain
Le 07/03/2025 à 02:13, Michael Niedermayer a écrit :
[...]
We have a generic remap table with the float code.
1. This is not really float specific, it could be used with integers
IMO it is important to have a clear split of "tools" available in the
bitstream, so it can be used whatever is the
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
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
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 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
On 06/03/2025 01:15, Michael Niedermayer wrote:
Hi everyone
Current FFv1 code with my patchset supports 16bit floats. The implementation
is quite simple. Which is good
I have tried improving compression, the gains are incremental, but its not
large overall. For example 44% space gain on the rem
Hi everyone
Current FFv1 code with my patchset supports 16bit floats. The implementation
is quite simple. Which is good
I have tried improving compression, the gains are incremental, but its not
large overall. For example 44% space gain on the remapping table is just
0.1% overall.
I have few flo
