[FFmpeg-devel] [PATCH 2/2] libavcodec/ffv1: Support storing LSB raw
Michael Niedermayer
michael at niedermayer.cc
Wed Oct 16 16:36:55 EEST 2024
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 <michael at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241016/1364c4d9/attachment.sig>
More information about the ffmpeg-devel
mailing list