Depending on the input and/or filters, you sometime have an input or
output pixel format like "rgb48le(12 bpc)". Unfortunately, most often,
the 12 bpc information is ignored or stripped. This patchset modify
some such cases, at the cost of increasing risks as patches go.
0001 is an actual bugfix to dpxenc for a misplaced hunk in 69849a2d.
0002 is more of a feature than anything.
0003 occurs with eg rgb48le(12 bpc): the code goes through the
s->bits_per_component==12 case rather than ==16
0004 is a hack to conserve the 12bpc information across some conversions.
0005 respects bits_per_raw_sample but introduces potential issues
The issues with 0005 is that some formats do not know how to encode
bidepths between 9 and 15. And conversion from a form of rgb48 to
another (stripping alpha or endianness or ...) does not rescale
according to bits_per_raw_sample.
ljpeg output for RGB and bits_per_raw_sample==12 is e.g. not rescaled
to 16bits to match its rgb48 colorspace.
One may argue that a proper solution is to reduce as often as possible
references to bits_per_raw_sample and, instead, always use the
colorspace information and to introduce new colorspaces as needed.
Christophe Gisquet (5):
dpxenc: fix padding in encode_gbrp12
pnmenc: use bits_per_raw_sample
dpxenc: fix encoding of packed RGB48/64
ffmpeg: keep bitdepth where possible
pnmdec: keep bitdepth rather than rescaling
ffmpeg.c | 9 +++++++++
libavcodec/dpxenc.c | 41 ++++++++++++++++++++++++++++++++++++++---
libavcodec/pnmdec.c | 6 ------
libavcodec/pnmenc.c | 2 ++
4 files changed, 49 insertions(+), 9 deletions(-)
--
1.9.2.msysgit.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
