AVISynth Reverse is slow

[smike]

I'm trying to use the Reverse function on AVISynth, but whenever I do it, the video becomes very slow and the CPU power goes up.

AudioDub(FFVideoSource("test.wmv", fpsnum = 30000, fpsden = 1001), FFAudioSource("test.wmv"))

Trim(6063,7047)
Reverse

Is the Reverse function really that demanding or is there a way to make it run smoothly?

[newpball]

I'm trying to use the Reverse function on AVISynth, but whenever I do it, the video becomes very slow and the CPU power goes up.

What kind of hardware are you running this with?

[smike]

It's a 2 Quad Core CPU with a 64 bit operating system.

[hello_hello]

Is the Reverse function really that demanding or is there a way to make it run smoothly?

I've never used it but I gave it a test and couldn't get it to always run smoothly. For DVD video it seemd to run at the correct speed in reverse, but when I tried an Xvid encoded video..... not so much. The speed would increase and decrease, but I don't know if it's a decoding issue or whether for video that requires more CPU power to decode it's just going to be inconstant speed-wise. I tried ffms2 and L-Smash.

For me (I only tested a low resolution standard definition Xvid video, aside from a vob file) CPU usage did increase, but it was still only sitting on 30% or so and none of the individual CPU cores hit 100% (or even close), yet the video wasn't playing smoothly in reverse. Sorry, I don't know why.

What kind of hardware are you running this with?

I assume from the question you must know what level of hardware is required, so why keep us in suspense?

[pandy]

Lossy codecs may give slow access (preceding frames to key frame need to be decoded before last one will be accessible) - prerender file to temporary and seek over it faster.

[jagabo]

Long GOPs (not necessarily lossy codecs) require a lot of work for random (or backward) seeks -- which is required by the Reverse() function.

[pandy]

Long GOPs (not necessarily lossy codecs) require a lot of work for random (or backward) seeks -- which is required by the Reverse() function.

Well - yes, You are 100% right - long GOP instead lossy (albeit mostly long GOP's are also lossy - from non lossy and computationally intense i can imagine only FFV1)

[jagabo]

Long GOPs (not necessarily lossy codecs) require a lot of work for random (or backward) seeks -- which is required by the Reverse() function.

Well - yes, You are 100% right - long GOP instead lossy (albeit mostly long GOP's are also lossy - from non lossy and computationally intense i can imagine only FFV1)

I knew you were aware of that. I just wanted to clarify for the OP.