[FFmpeg-devel] FFV1 high bit depth RGB
georg.lippitsch at gmx.at
Wed Jul 4 16:43:34 CEST 2012
Am 04.07.2012, 16:08 Uhr, schrieb Michael Niedermayer <michaelni at gmx.at>:
>> So as a first step, I added 10 bit support by adding a new 10 bit
>> packed RGB colorspace, and rewriting encode_rgb() / decode_rgb() in
>> ffv1 to support it. That works well, and encoding is proven to be
>> lossless with 10 bit RGB input.
>> Patches attached, any comments appreciated!
> why dont you use the existing PIX_FMT_GBRP10 ?
Because DXF uses packed rgb, ffv1 already handles packed RGB, and it
seemed easier to stay with packed formats than adding support for planar.
>> Especially, does any one have any ideas if there is a (more or less)
>> simple solution for adding 16 bit RGB to FFV1?
>> If that is too hard to implement, do you think adding 10 and 12 bit
>> colorspaces is feasible? Any other suggestions on how to support
>> more than 8bit properly?
> the code has to be changed to use larger data types. This needs to be
> if its slower some preprocessor templating will be needed to build
> it for both <16bit and >=16bit so the existing code isnt slowed down
Could you give a rough estimation how much work that would be (like 1 day
or 1 month or 1 year)?
AFAICT FFmpeg uses 16bit data types nearly everywhere, and I haven't been
able to figure out if simply replacing all uint16_t with uint32_t would do
the job (I suppose not).
>> + PIX_FMT_RGB30BE, ///< packed RGB 10:10:10, 48bpp, 10R, 10G, 10B,
>> the 2-byte value for each R/G/B component is stored as big-endian 10 bit
>> + PIX_FMT_RGB30LE, ///< packed RGB 10:10:10, 48bpp, 10R, 10G, 10B,
>> the 2-byte value for each R/G/B component is stored as little-endian 10
>> PIX_FMT_RGB48BE, ///< packed RGB 16:16:16, 48bpp, 16R, 16G, 16B,
>> the 2-byte value for each R/G/B component is stored as big-endian
>> PIX_FMT_RGB48LE, ///< packed RGB 16:16:16, 48bpp, 16R, 16G, 16B,
>> the 2-byte value for each R/G/B component is stored as little-endian
> breaks ABI, you cannot add anything in the middle
Ah, sure, will add at the end next time.
More information about the ffmpeg-devel