On Sun, 15 Dec 2013 17:39:04 +0100
Carsten Kurz <audiovisual(a)t-online.de> wrote:
[snip disappointing results on a fast machine]
I think the user in question has emailed me those results, unless
there's a big coincidence :)
I assume that, roughly put, dvd-o-matic is split into
something like
preprocessor (input, FFMPEG, Filters, etc.), J2k encoding,
postprocessor (audio, wrapping, XML, filewrites, etc). And that
probably only the j2k encoding can actually use multithreading, one
thread per frame?
Yes, that's it; there is a decoding thread generating frames which are
fed to multiple J2K encoding threads and then a writer thread which
puts the J2K data on disc in frame order.
I think the decoding could perhaps be multi-threaded; we might be
able to run two separate decoders outputting alternate frames, or
something.
I'd be surprised if the writer thread can't keep up; anyway, if it
can't write the data to disc fast enough there is no point in encoding
it quickly...
Or is there a fixed limit on the number of encoding
threads used, even if set higher?
No limit, no (at least, not in the back-end; the GUI will limit to 128
at the moment).
I guess the encoding threads are being starved.
[snip]
The easiest thing might be for me to try running an encode on a fast
EC2 machine, to see if that exhibits similar problems. There may be
something silly happening that we can fix easily.
Best regards
Carl