[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:

> Hi,
> 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
> unreliable.

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.

Carl Eugen

More information about the ffmpeg-devel mailing list