Christophe Gisquet <christophe.gisquet <at> gmail.com> writes: > - ffmpeg's and yours (if I'm not mistaken): the signal > bitdepth should always match the colorspace one, and > bits_per_raw_sample should indicate the original bitdepth
I believe that my opinion is mostly irrelevant but that FFmpeg's opinion is the only one that counts (until you send a patch to change the current meaning but that implies a major version bump and as said, I would like to understand the usecase). > I believe rescaling in the decoder, like pnmdec does, > is wrong. Please provide a sample. > > The sample is broken, you cannot use it to test > > anything else but ticket #2966. > > It isn't, it decodes fine, No. > the pixels are just marked differently. The pixels have an incorrect value, this is what ticket #2966 is about. Fortunately, the ticket is reproducible with ffplay. [...] > > 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 > > lossless). Sorry, I should not have mentioned this, it is absolutely unrelated to this issue. (That pnmenc is currently broken.) [...] > > Because of ticket #2966. > > To fix according to your view, it needs rescaling. > Are you going to implement pnmdec's one? Only if you provide a broken sample;-) > > The values have the right dynamics except for the > > sample from ticket #2966. > > There are several codecs that could output values not ok. Please provide samples, I thought that the issue only exists in mjpeg / ljpeg. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
