Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
On Thu, Oct 30, 2014 at 02:49:30PM +0100, Christophe Gisquet wrote: Hi, 2014-10-26 19:20 GMT+01:00 Michael Niedermayer michae...@gmx.at: I took the liberty to apply the patch and fix the bug instead of leaving it open until someone succeeds writing a fate test for it Hi, I wonder whether this should be reverted for now (and ticket #2970 reopened at the same time). The patch fixes decoder artifacts, i dont think we should just revert it unless it causes artifacts in some other (known to be good) file I have been checking how to produce interlaced content through the encoder, and the current table produces worse results (PSNR-wise, but it was big enough to not bother checking visually). I don't know if that's an encoder issue yet or if the decoder table is still incorrect. did you try to decode with a known to be correct decoder ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
Hi, 2014-10-25 20:32 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: What I meant is I would need someone to: 1) provide a command line to swap fields to produce an artificially interlaced image 2) confirm that -flags ildct sets CODEC_FLAG_INTERLACED_DCT and does what is needed Unfortunately, I haven't been able to create a sample out of lena with libavfilter that triggers this (and I'm unwilling to spend more time on that). Anyway, most libavfilters require a GPL build, so this contrives the conditions to perform the test. This is potentially an issue in the interlaced encoding decision. The alternative is to just add a fate sample. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
On Sat, Oct 25, 2014 at 11:19:23AM +, Christophe Gisquet wrote: The coefficients must be in the appropriate zigzag scan order. Also fix their values at the same time, as they were pretty wrong. Fixes ticket #2970. --- libavcodec/dvdata.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
On Sat, Oct 25, 2014 at 06:25:22PM +0200, Reimar Döffinger wrote: On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote: 2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de: Could you maybe add e.g. a FATE test that clearly shows the before-after improvements? I've tried for a small while, by swapping fields on lena and converting to yuv42[02]p and feeding it to ffmpeg with: -pix_fmt yuv422p -s 720x576 -i lena.yuv -flags ildct -vf setfield=1,fieldorder=bff -vcodec dvvideo out.dv The PSNR results were weird (with 2 exes I thought were before/after), so I didn't follow through. Maybe someone more versed in libavfi can offer a command-line doing the job. The only conclusive impact is on the #2970 sequence, but it has too few blocks coded as interlaced (!) to matter for anything but visual. And indeed the fate tests do not seem to exercise the affected code. Maybe I misunderstand the issue, but maybe a encoder option to force interlaced encoding would work to trigger this reliably? I took the liberty to apply the patch and fix the bug instead of leaving it open until someone succeeds writing a fate test for it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
On Sat, Oct 25, 2014 at 11:19:23AM +, Christophe Gisquet wrote: The coefficients must be in the appropriate zigzag scan order. Also fix their values at the same time, as they were pretty wrong. Fixes ticket #2970. Could you maybe add e.g. a FATE test that clearly shows the before-after improvements? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de: Could you maybe add e.g. a FATE test that clearly shows the before-after improvements? I've tried for a small while, by swapping fields on lena and converting to yuv42[02]p and feeding it to ffmpeg with: -pix_fmt yuv422p -s 720x576 -i lena.yuv -flags ildct -vf setfield=1,fieldorder=bff -vcodec dvvideo out.dv The PSNR results were weird (with 2 exes I thought were before/after), so I didn't follow through. Maybe someone more versed in libavfi can offer a command-line doing the job. The only conclusive impact is on the #2970 sequence, but it has too few blocks coded as interlaced (!) to matter for anything but visual. And indeed the fate tests do not seem to exercise the affected code. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform
Hi, 2014-10-25 18:25 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de: On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote: 2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de: Could you maybe add e.g. a FATE test that clearly shows the before-after improvements? I've tried for a small while, by swapping fields on lena and converting to yuv42[02]p and feeding it to ffmpeg with: -pix_fmt yuv422p -s 720x576 -i lena.yuv -flags ildct -vf setfield=1,fieldorder=bff -vcodec dvvideo out.dv The PSNR results were weird (with 2 exes I thought were before/after), so I didn't follow through. Maybe someone more versed in libavfi can offer a command-line doing the job. The only conclusive impact is on the #2970 sequence, but it has too few blocks coded as interlaced (!) to matter for anything but visual. And indeed the fate tests do not seem to exercise the affected code. Maybe I misunderstand the issue, but maybe a encoder option to force interlaced encoding would work to trigger this reliably? What I meant is I would need someone to: 1) provide a command line to swap fields to produce an artificially interlaced image 2) confirm that -flags ildct sets CODEC_FLAG_INTERLACED_DCT and does what is needed Regarding 1), it is all the more needed since the encoder decides on the fly which of the interlaced or normal dcts are better. And I would then expect to notice a difference only if it is used frequently. That's not what I observed so I bet I got something wrong for 1) and/or 2). Best regards, -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
