Multithreading, x264 and avisynth.

[Dreadkillz]

Hi,

How does multithreading in x264 help when regular avisynth isn't multithreaded? Whenever I play an avs script in MPC, there's only one core being used. Can someone explain in laymen term to me how they work together then?

[Guest]

x264 is an encoder and multiple cores can be used when encoding. That is completely different from decoding, which is what happens when you play an x264-encoded video.

[Dreadkillz]

So when x264 is encoding, wouldn't there also be decoding too to transfer frames to the encoder? Would the decoding also be multithreaded when I serve avs files to x264 if say I have threads=2?

[Guest]

The threads setting for x264 affects only the encoding process.

[kemuri-_9]

the x264cli normally only reads/decodes a frame from the given input when it is demanded to feed into the encoder.

however, there is an option --thread-input which defaults to on when --threads is >1.

this option works such that after a frame is read into the encoder,
a thread is spawned to start processing on the next frame that will be fed into the encoder.

this can give a slight performance boost in the situation where the input decoding/read speed acts as the bottleneck for the encode.

[Dreadkillz]

Well, I'm assuming that my avs is the bottleneck then since it decodes rather slowly in MPC. How would I multithread the decoding of avs files then? Would my x264 encoding speed improve as well if I can multithread avisynth filters?

[TheRyuu]

Depends what you're decoding really and what filters are being used, etc...

Sure threading the filters/decoding may speed up encoding. Pretty much it just depends greatly on what exactly you're doing.

You can try using a ffmpeg-mt compiled ffmpegsource (http://doom10.org/index.php?topic=25.0) (it depends what exactly your source is of course, h264 is the main beneficiary of ffmpeg-mtafied ffms)