Re: mulithread rework

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 24, 2008 at 12:37:05PM +1000, Con Kolivas wrote:
> On 24/04/2008, Michael Niedermayer <[email protected]> wrote:
> > If anyone is interrested in seeing how scaleable multithreaded encoding
> > based on independant slices is (or is not ...) and by how much it worsens
> > the quality per bitrate. FFmpegs mpeg1/2/4/h263 encoders support
> > multithreaded encoding based on independant slices.
> >
> > PS: for a realistic test with ffmpeg one should tweak the parameters
> > as our defaults are no good quality/bitrate wise.
> >
> > PS2: I dont have a multi cpu system, so i actually dont know how bad
> > ffmpeg scales ...
> 
> ffmpeg scales very well with cpus, and the effect on quality is so
> small compared to the speed gains on a quad core that I never use
> ffmpeg without multiple threads. Quality wise for equivalent
> quantization and psnr vs bitrate, ffmpeg edges out xvid at the lower
> quantization settings by a decent margin (that's not the case at lower
> bitrates / higher quantization settings). So why am I even looking at
> xvid? Well ffmpeg is not really "stable" and has random different
> problems at various intervals, and, well, there was this xvid code

I know you are not trying to report a bug but "random different 
problems at various intervals", could you be slightly more precisse? :)

[...]
- -- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFID//4YR7HhwQLD6sRAlT9AJ99rzUgQSzMN2VbKv+hEFPWktQiCQCdHnp9
8aVs95o/dlfszcCWLzt0roo=
=4Bwa
-----END PGP SIGNATURE-----