[FFmpeg-devel] [PATCH] libavcodec/zmbvenc: Add support for RGB formats

[Tomas Härdin]

mån 2019-03-11 klockan 11:43 +0100 skrev Carl Eugen Hoyos:
> > 2019-03-11 11:37 GMT+01:00, Tomas Härdin <tjoppen at acc.umu.se>:
> > fre 2019-03-08 klockan 21:39 +0000 skrev Matthew Fearnley:
> > > > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos <ceffmpeg at gmail.com>
> > > > wrote:
> > > > > > > > 2019-03-08 15:04 GMT+01:00, Tomas Härdin <tjoppen at acc.umu.se>:
> > > > > 
> > > > > Maybe we could coordinate 1/2/4/24-bit support with the
> > > > 
> > > > I believe FFmpeg cannot support 1/2/4 bit for encoding.
> > > 
> > > As far as I can see, FFmpeg has very limited support for bit depths less
> > > than 8.  I think there are basically two formats (plus variants), with
> > > fixed "palettes":
> > > 1bpp: MONO_BLACK / MONO_WHITE (black/white only)
> > > 4bpp: RGB4[_BYTE], BGR4[_BYTE] (RGB 1:2:1, 16 colours - I presume red/blue
> > > would be 0,255; green would be 0,85,170,255)
> > > 
> > > If the ZMBV formats were defined, these might be worth encoder adding
> > > support for.
> > > (Practically speaking though, it would be a slight pain, because the
> > > encoder would do the work in 8bpp and pack/unpack as needed.)
> > > But with PAL8 being the only format allowing a free palette, all sub-8bpp
> > > formats would have to decode to that, so they wouldn't round-trip.
> > 
> > There's some justification for adding sub-8bpp, like BMP. bmp.c
> > converts all of them except GRAY8 to PAL8. Bitdepths besides 1, 4 and 8
> > don't work at all.
> > 
> > One way to at least allow both the bmp and zmbv encoders to do sub-8bpp
> > from PAL8 would be to keep track of the maximum number of colors in
> > some appropriate struct.
> 
> bits_per_coded_sample

bits_per_raw_sample would seem more appropriate, depending on what part
of the documentation you trust. It's unfortunate that AVCodecContext
and AVCodecParameters have different wording, and possibly different
semantics for these fields..

Whichever is used, the wording would need to become more
precise. bits_per_coded_sample documentation mentions ADPCM which packs
samples, whereas 1/2/4-bit-in-PAL8 would not.

I sent an email to the DOSBox crew about bit ordering

/Tomas