[FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
Carl Eugen Hoyos
cehoyos at ag.or.at
Sun Aug 24 03:00:11 CEST 2014
Christophe Gisquet <christophe.gisquet <at> gmail.com> writes:
> 2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos:
> > Christophe Gisquet writes:
> >> 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.
> > Could you explain what command line you are trying
> > to fix?
> > I apparently misunderstand the patchset, I don't
> > see how / what it fixes...
> The biggest "issue" is that 10/12bits data is
> interpreted as 16bits:
I consider this a (important) feature.
> - cf. ticket #2966 (that's the remaining missing part)
There is a bug:
The image has to be rescaled in the demuxer.
> - png can only write 16bits data but sometimes it is
> not rescaled (image appears darker), cf. the above
Is there another example than #2966?
> - ppm images are forcibly rescaled to fill the 16bits
> (probably lossless but still) etc.
If you believe this is a real-world issue, is
can easily be fixed afaict.
> > Note that I believe it would be completely wrong to
> > add additional colourspaces with 8<bpc<16.
> Yes, on second thought it has its own bag of issues
> (multiplications of codepaths eg in swscale), but
> that's to me the only solution that isn't a fragile
> hack. Also note that there are already plenty of
> those 8<bpc<16 for planar rgb.
And it was one the biggest mistakes imo that these
formats were added (the yuv ones originally).
More information about the ffmpeg-devel