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. Adding proper sub-8bpp support would involve a lot of libsws headache I suspect. > (It should be possible to implement decoding to pal8 if > > that doesn't work yet and if samples exist.) > > > > No samples or specifications exist that I know of, so I don't plan to > submit any patches to the decoder unless/until there is something to work > with there. > > > dosbox devs? And maybe we should do something about > > > the RGB24 thing in the decoder.. > > Yeah, I think talking with the DOSBox devs sounds like a potentially good > idea. > > > > > Do I understand correctly that no existing implementation > > supports 24bit rgb? If that is correct, I believe FFmpeg > > shouldn't add it (but this may only be me). > > > > I agree that FFmpeg shouldn't add support for any formats that haven't been > defined. > As far as I know, the specifics of the 24-bit RGB format havn't been > discussed anywhere, and there are no samples I know of. > > A likely specification of 24-bit is trivial enough to add support for, that > I was originally planning to add it with an #ifdef (like in the decoder). > But it wouldn't do to have contradictory channel orders proposed in the > decoder and encoder, so I will leave that for now unless DOSBox will commit > to one. > > I presume that FFmpeg generally doesn't like to set standards in media > formats, only to implement existing ones. > My personal feelings in this case would be to provide support that's > disabled at compile-time if an official specification can be agreed, and to > have support included by default if an independent implementation - or at > least independent samples - are available that agree with the specification. Just a small thing to be clear: ZMBV_ENABLE_24BPP is not defined anywhere, so we're free to do however we want with it. It's not going to break anyone's workflow unless they were foolish enough to encode 24-bit ZMBVs outside of the non-existing spec. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel