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
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".