[FFmpeg-devel] [PATCH]Fix pnm encoding with bpc set
Carl Eugen Hoyos
cehoyos at ag.or.at
Sun Aug 24 13:25:24 CEST 2014
Christophe Gisquet <christophe.gisquet <at> gmail.com> writes:
> 2014-08-24 12:48 GMT+02:00 Carl Eugen Hoyos <cehoyos <at> ag.or.at>:
> >> I think "[PATCH 2/5] pnmenc: use bits_per_raw_sample"
> >> is wrong then
> > Definitely, I still wonder how you tested it.
> ljpeg 36bits from #2966 and having the actual
> bits_per_raw_sample value
The sample is broken, you cannot use it to test
anything else but ticket #2966.
> What this situation underlines is that bits_per_raw_sample is
I believe it is very useful and works as expected,
the only issue I found today is that it gets lost
on endian conversion in libswscale (that should be
> Compare ljpeg RGB with more than 8 bits and pnmdec:
> - ljpeg sets bits_per_raw_sample to 12 (because that's
> what the sample dynamics is), colorspace is 16bits
And this is working as expected for the samples
from ticket #2952, it is broken for the sample
in ticket #2966.
> - pnmdec set bits_per_raw_sample to 12, but scale
> samples to 16bits to match colorspace, hereby making
> bits_per_raw_sample less useful
> (samples have actually 16 bits of dynamics)
Yes, this is to make sure that you can use the same
frame for encoders (displays) that only support 16bpc
(as most do) while it allows to know how many bpc
are actually coded.
> We have 2 cases resulting in the same info but
> needing different processing.
Because of ticket #2966.
> So, at this point you can't know if
> bits_per_raw_sample!=color space bitdepth means the
> values have the right dynamics indicated by
> bits_per_raw_sample, if they have been rescaled to
> get to the colorspace bitdepth, and so on.
The values have the right dynamics except for the
sample from ticket #2966.
> A potential "fix" would be to remove
> bits_per_raw_sample setting from pnmdec.c
> But I expect some other decoders to be potentially
> wrong/doing yet another thing at this point, so
> bits_per_raw_sample is not completely reliable.
Bugs in FFmpeg do exist.
> My suggestion in "[PATCH 2/5] pnmenc: use
> bits_per_raw_sample" was "if bits_per_raw_sample is
> correct". This looks to uncertain to me, so that
> patch should be reverted.
bits_per_raw_sample is correct imo but I have
certainly no objections.
More information about the ffmpeg-devel