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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
