[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).

Carl Eugen



More information about the ffmpeg-devel mailing list