On Wed, Oct 16, 2024 at 02:13:35AM +0200, Lynne via ffmpeg-devel wrote:
> On 16/10/2024 01:17, Michael Niedermayer wrote:
> > This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression 
> > with rawlsb=4
> > 
> > Please test and comment
> > 
> > This stores the LSB through non binary range coding, this is simpler than 
> > using a
> > separate coder
> > For cases where range coding is not wanted its probably best to use golomb 
> > rice
> > for everything.
> > 
> > We also pass the LSB through the decorrelation and context stages (which is 
> > basically free)
> > this leads to slightly better compression than separating them earlier.
> > 
> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > ---
> >   libavcodec/ffv1.h             |  2 ++
> >   libavcodec/ffv1_template.c    | 19 ++++++++++---------
> >   libavcodec/ffv1dec.c          |  2 ++
> >   libavcodec/ffv1dec_template.c | 16 +++++++++++++---
> >   libavcodec/ffv1enc.c          | 15 ++++++++++++++-
> >   libavcodec/ffv1enc_template.c | 17 +++++++++++++++--
> >   libavcodec/rangecoder.h       | 20 ++++++++++++++++++++
> >   libavcodec/tests/rangecoder.c |  9 +++++++++
> >   8 files changed, 85 insertions(+), 15 deletions(-)
[...]
> > diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
> > index 89d178ac314..d02a65fa7da 100644
> > --- a/libavcodec/rangecoder.h
> > +++ b/libavcodec/rangecoder.h
> > @@ -111,6 +111,16 @@ static inline void put_rac(RangeCoder *c, uint8_t 
> > *const state, int bit)
> >       renorm_encoder(c);
> >   }
> > +static inline void put_rac_raw(RangeCoder *c, int bits, int len)
> > +{
> > +    int r = c->range >> len;
> > +
> > +    c->low += r * bits;
> > +    c->range = r;
> > +
> > +    renorm_encoder(c);
> > +}
> > +
> >   static inline void refill(RangeCoder *c)
> >   {
> >       if (c->range < 0x100) {
> > @@ -142,4 +152,14 @@ static inline int get_rac(RangeCoder *c, uint8_t 
> > *const state)
> >       }
> >   }
> > +static inline int get_rac_raw(RangeCoder *c, int len)
> > +{
> > +    int r = c->range >> len;
> > +    int bits = c->low / r;
> > +    c->low -= r * bits;
> > +    c->range = r;
> > +    refill(c);
> > +    return bits;
> > +}
> > +
[...]
>
> You're interfering with the rangecoder by asking it to write very random
> data in between each symbol.

the data is needed in that order for context modeling and decorrelation
to work.

At least with the CPU implementation we have this gives the same speedup
but better compression and its simpler code


> You should do what Opus does and write the rawbits in a separate buffer
> which gets merged at the very end.

I like more what h264 does with storing raw bits (get_cabac_bypass())
and given that h264 also works with much higher bitrates as a video codec
than opus as a audio codec, it seems the example is closer to our use case.


> 
> I think rather than doing this, you should instead simply permit golomb
> coding to be used on high bit-depths.

yes or rather, not "instead" but too.
We should permit golomb coding on high bit-depths.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to