2019-03-11 12:07 GMT+01:00, Tomas Härdin <tjop...@acc.umu.se>: > mån 2019-03-11 klockan 11:43 +0100 skrev Carl Eugen Hoyos: >> > 2019-03-11 11:37 GMT+01:00, Tomas Härdin <tjop...@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 <ceffm...@gmail.com> >> > > > wrote: >> > > > > > > > 2019-03-08 15:04 GMT+01:00, Tomas Härdin >> > > > > > > > <tjop...@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
Of course! Sorry, Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
