[FFmpeg-devel] [PATCH 4/6] dv: fix weight table for 2x4x8 transform

Christophe Gisquet christophe.gisquet at gmail.com
Sat Oct 25 20:32:18 CEST 2014


2014-10-25 18:25 GMT+02:00 Reimar Döffinger <Reimar.Doeffinger at 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.Doeffinger at 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,

More information about the ffmpeg-devel mailing list