Re: Limit of 4 threads in the VfW GUI

Hi all,

I have refactorized the encoder multi-threading code to get rid off the
thread limit and introduce also a new slice-based threading scheme:

There's now the new API parameter "num_slices" that controls in how many
independent slices the encoder should segment each frame. The slices are
then dispatched to different threads and encoded in parallel (depending
on "num_threads" settings).

The advantage of the slice-based multi-threading is that it has less sync
points and scales better. The disadvantage is that it writes resync
markers to the bitstream that reset intra/inter predictors, which results
in larger file size (typically less than ~0.1% bitrate increase).

By default, slice-based multi-threading is off, so the encoder should
behave just as before (but should not crash anymore now with many threads).
If you set num_threads and num_slices both to values larger than one, the
slice-based multi-threading will be used. Slice-based and row-based ME can
also be combined: E.g. by setting num_threads to '4' and num_slices to
'2', the two slices will be coded in parallel while for each of the slices
two row-based ME threads are launched.

Some performance figures (Core2 Quad Q9550, 720p input, encoder defaults):

Threads		Row-based MT (FPS)	         Slice-based MT (FPS)

-1			21.0			21.0
  1			20.9			20.9
  2			29.7			35.6
  3			35.3			48.2
  4			38.3			56.0
  6			34.8			49.0
  8			34.0			54.7

Note that the slice-based multi-threading feature is only available in
xvid_encraw for now and not yet in VfW. So in case you want to try it you
need to compile xvid_encraw.

Regards,
Michael


Quoting Jawor <[email protected]>:

> Thank you. It would explain the report I got lately (Xvid on an Intel
> Core i7-870 crashes with 8 threads, but not with 4 threads).
>
> Best regards,
> Marcin Jaworski
> _______________________________________________
> Xvid-devel mailing list
> [email protected]
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>