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 output is ready for the idct in hybrid coders like h26x the idct_permutation used by the fdct is not set to the identity permutation so that either need to be changed or idct_permutation must be used when encoding the coefficients or maybe something else and this analysis is wrong ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
