Hi, 2015-10-11 18:20 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>: > On Sun, Oct 11, 2015 at 04:06:05PM +0200, Christophe Gisquet wrote: >> The functions related to bitstream reading must use the natural zigzag >> order, and not the one permuted for use in the iDCT. This currently >> results in bitstreams with 2 issues: >> - AC coefficients are encoded in an unexpected order; >> - Incorrect weights are applied in the (de)quantization. >> >> This currently can't show up because there's no simple_idct which >> requires a permutation. >> >> With one that does (based on prores'), and using the following source: >> -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p10le >> and encoding to CID 1241 (interlaced 1080p YUV422) using: >> -vcodec dnxhd -flags +ildct -vb 185M >> >> before: stddev: 55.57 PSNR: 61.43 MAXDIFF: 960 >> after: stddev: 0.35 PSNR:105.45 MAXDIFF: 11 >> --- >> libavcodec/dnxhdenc.c | 12 +++++++----- >> 1 file changed, 7 insertions(+), 5 deletions(-) > > breaks: > ./ffmpeg -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p -vcodec > dnxhd -flags +ildct -vb 185M test.mov
> and thinking about it a bit more (which i should have done earlier) > i suspect it to break every 8bit case > the fdct permutes its output if the idct_permutation is set so its OK, so that's the issue, and the current dnxhdenc code totally misled me here. So, actually, it's the quantize function that applies this, and it's missing from the 10bits version. In the end, I don't think the code really needs all of this (there's one single scantable...), but that cleanup is not for now. I decided to reuse the code from mpegvideo_enc in that matter, so see the new patch here. -- Christophe
0001-mpegvideo-dnxhdenc-permute-10bits-content.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
