Avisynth MT (for multiple cores, and its fucking awesome!)

[Corran]

It seems just for simple directshowsource transcoding with nothing else i don't get any speed increase (24:15 [mm:ss] of footage 1024x68 h264 in MKV to HuffYUV in AVI took around 11.5 minutes both with and without MT).

Multithreading the source filter probably isn't going to help if decoding a video where keyframes are spread out such as H.264 as you need to rebuild the frames sequentially.

Well, I suppose it could open the same file several times in different threads and fetch several frames at once, but I'm honestly not sure if that's going to work too well, at least when you have a codec where frames depend on each other.

It could work if you start a thread at every keyframe (although I'm not sure how to get that information from a source filter) or with keyframe-only formats like HuffYUV or MJPEG, but probably not too well with MPEG4 ASP or H.264 with several hundred frames of max keyframe distance...

[Qyot27]

It seems just for simple directshowsource transcoding with nothing else i don't get any speed increase (24:15 [mm:ss] of footage 1024x68 h264 in MKV to HuffYUV in AVI took around 11.5 minutes both with and without MT).

Multithreading the source filter probably isn't going to help if decoding a video where keyframes are spread out such as H.264 as you need to rebuild the frames sequentially.

Well, I suppose it could open the same file several times in different threads and fetch several frames at once, but I'm honestly not sure if that's going to work too well, at least when you have a codec where frames depend on each other.

It could work if you start a thread at every keyframe (although I'm not sure how to get that information from a source filter) or with keyframe-only formats like HuffYUV or MJPEG, but probably not too well with MPEG4 ASP or H.264 with several hundred frames of max keyframe distance...

There isn't any way around that though? Like DGAVCIndex or FFmpegSource (to be honest FFmpegSource wins that contest for right now since it actually supports reading from the containers and isn't limited to just H.264), for example - both write index files which get read in place of the straight video, and depend on libavcodec to do their decoding. I could see how DirectShowSource would be deficient, but with ones that write indexes it'd be vastly simpler to implement multithreaded decoding, as it'd be more up to the development of libavcodec to achieve that, or so I would think.

Whether AviSynth MT supports either one is something someone else will have to test, I don't have a computer that uses multithreading.

[Corran]

Indexing allows for frame accurate seeking but the video still needs to be rendered in the same fashion; i.e. starting at a keyframe and applying the changes til the current requested frame is rendered.

Out of curiousity I ran the following two scripts and encoded them both to MJPEG. When encoding the one using MTSource, I noticed the frame rendering rate drop to 0fps several times. Thread lock I'm guessing... Even so, I was still shocked that it took so long to render compared to the single thread. It is honestly my first time personally using ffmpegsource and mtsource so maybe the default settings shouldn't have been used in the test?

Code: Select all

MTSource("""FFMPEGSource("F:\Video\AMVs\[Koop] Skittles (1280x720).mp4")""")
converttorgb32()

Time to render: 12:49

Code: Select all

FFMPEGSource("F:\Video\AMVs\[Koop] Skittles (1280x720).mp4")
converttorgb32()

Time to render: 3:23

[Pwolf]

Indexing allows for frame accurate seeking but the video still needs to be rendered in the same fashion; i.e. starting at a keyframe and applying the changes til the current requested frame is rendered.

Out of curiousity I ran the following two scripts and encoded them both to MJPEG. When encoding the one using MTSource, I noticed the frame rendering rate drop to 0fps several times. Thread lock I'm guessing... Even so, I was still shocked that it took so long to render compared to the single thread. It is honestly my first time personally using ffmpegsource and mtsource so maybe the default settings shouldn't have been used in the test?

Code: Select all

MTSource("""FFMPEGSource("F:\Video\AMVs\[Koop] Skittles (1280x720).mp4")""")
converttorgb32()

Time to render: 12:49

Code: Select all

FFMPEGSource("F:\Video\AMVs\[Koop] Skittles (1280x720).mp4")
converttorgb32()

Time to render: 3:23

try changing the mode to 3 and see what it does.

Pwolf

[Corran]

Code: Select all

SetMTMode(3)
MTSource("""FFMPEGSource("F:\Video\AMVs\[Koop] Skittles (1280x720).mp4")""")
converttorgb32()

Render time ~40 minutes x_x

The number is a little tainted as at the 20 minute mark I started watching random stuff on you-tube thus pulling some cpu cycles away from the encode, but even so...

[Pwolf]

do:

setmtmode(3,2) (2 being the number of cores so if you have 4, use 4)


Pwolf

[Corran]

do:

setmtmode(3,2) (2 being the number of cores so if you have 4, use 4)


Pwolf

The default is 0. 0 sets it to use all available cores.

[Pwolf]

do:

setmtmode(3,2) (2 being the number of cores so if you have 4, use 4)


Pwolf

The default is 0. 0 sets it to use all available cores.

i must have missed that part >.>

Pwolf