Just checked this on a Windows XP 32bit machine with Blender 2.5 Rev 27070 and there is no moire.

Correct me if I am wrong Yellow, but is that an interlaced source?

Looking at the trees I can't help but wonder if the source is in interlaced progressive format?

Troy

Thanks but...

Yes it is from a psf25 (segment fields). :-)

DGIndex confirms this.

The problem has only arisen after Linux builds went to system FFMPEG or just coincidence.

The issue doesn't arise on Windows builds and it hasn't been a problem for the last 2 years that I have worked with psf25 footage from this source.

So I feel it's a blender problem in this instance.

Cheers for the double check though.

Correction to last comment.

2.5 Blender built against system FFMPEG. But when I experienced the moire problem as per my other recent bug tracker entry, I tried to build 2.5 with FFMPEG from svn and opted to build FFMPEG in home folder, that's when this issue arose.

But will try again from scratch.

oh man, posted last comment in wrong bug sorry. duh!

I wasn't suggesting that the bug wasn't valid, but rather trying to figure out what _looks_ like is happening there.

It certainly looks like some sort of interlacing is being mishandled with ffmpeg? As in you aren't getting to the true progressive image output.

Do you get the same output with ffplay on the same frame?

Troy thanks for your help.

It's not just this psf25, original bug submit mentions a number of different formats and I've tried it with PAL DV, mpeg4, mpeg2 etc. All exhibit same moire.

It doesn't happen with 2.49b built from svn with either system or local FFMPEG builds.

This is a recent issue after blender went to system FFMPEG.

All exhibit moire in Blender 2.5. But all play correctly with ffplay.

System FFMPEG is:

VN-r19352-4:0.5+svn20090706-2ubuntu2, Copyright (c) 2003-2009 Fabrice Bellard, et al.
configuration: --extra-version=4:0.5+svn20090706-2ubuntu2 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --disable-vhook --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --extra-cflags=-I/build/buildd/ffmpeg-0.5+svn20090706/debian/include --enable-shared --disable-static
libavutil 49.15. 0 / 49.15. 0
libavcodec 52.20. 0 / 52.20. 0
libavformat 52.31. 0 / 52.31. 0
libavdevice 52. 1. 0 / 52. 1. 0
libavfilter 0. 4. 0 / 0. 4. 0
libswscale 0. 7. 1 / 0. 7. 1
libpostproc 51. 2. 0 / 51. 2. 0
built on Oct 13 2009 22:35:00, gcc: 4.4.1

I've downloaded 2.5 Alpha1 2.51.0 and I don't have the problem, so it's something specific to my machine, argh!!

I've also deleted my .B25.blend and saved a new one from the official 2.5 Alpha1 but still I have the problem.

So I guess close this bug and use Blender.Org Alpha 1 until I find out why. :-(

Last one on this, just built 2.5 from svn on a totally clean laptop, Ubuntu Karmic 64bit and tested some video files.

The moire is clearly there so there is a bug I think.

So what's different between Blender.org build and mine.

Can't spend any more time on this for now.

Yellow - push a sample that is short and easily visible. I'll test it at my end.

I get this too, but on the precompiled ffmpeg included with OS X (0.5.1 release).

Hi Matt

Due to compiling FFMPEG from svn for the 16 - 235 clamping patch the problem has resolved itself on Karmic Koala 64bit, FFMPEG SVN r22802.

Was using an svn build of FFMPEG from a PPA repository for Openshot, which used a more upto date precompiled build than Ububtu and that still had problems. 4.0.5+svn20090706.

So does look like an older FFMPEG problem now resolved.

Interesting - can anyone else confirm this? Troy?

@Matt: "Interesting - can anyone else confirm this? Troy?"

I haven't tested it, but I did indeed suspect that it was an FFMPEG issue (see above). I'd also keep our daily FFMPEG SVN eyes open for the color 601 scaling bug in interlaced content to dissipate as well...

so as a matter of fact, it is a ffmpeg bug in old versions and not blender, right?

Closing this now.

Please reopen, if it also shows up with a recent ffmpeg svn build.

Cheers,
Peter