On Mon, 2010-01-18 at 17:21 +0100, Adrian Stutz wrote: > On Mon, Jan 18, 2010 at 4:56 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi>wrote: > > Try -noslices. I suspect there are problems due to slice callback being > > called from different threads (I haven't tried to verify that though). > > > > Yes, that makes the distortions go away. > > Looking at my binary archive I can trace the issue back to the oldest one > from 2008-08-01 (r27376) and I would suspect the issue has been around > forever and only surfaced by preferring ffmpeg over libmpeg2 and me using > -lavdopts threads=x consistently. > > Is that easy to fix? As mentioned, ffplay doesn't have the problem - is it > just not doing sliced decoding or properly handling the threading? If that actually is the issue there's probably no simple fix better than disabling slicing. ffplay could handle the threading more carefully, or maybe it just doesn't use slicing or does nothing sophisticated enough to break - I haven't checked. > Or is it possible to disable slices for codecs that don't properly handle it > (there seems to be no issue with H264, for example)? I'd really like to be IIRC slices are not used with H264 by default. > able to just set -lavdopts threads=x without needing to worry which codec is > being used. I haven't seen or done any benchmarks about whether slicing gives a significant benefit in any situation on current hardware. But if "-lavdopts threads=x -noslices" works it's probably a reasonable default on a multicore machine.
