does avisynth have some kind of speed limit while encoding?

[Mug Funky]

okay, it's probably a vague sort of question, but i've run against some possibly odd behaviour with avisynth.

basically, with a really fast script (like a straight IVTC and resize on a suped-up machine), i seem to not be able to encode at anything above the actual playback rate of the script.

for example, in virtualdub(mod), you can load a script and set "fast recompress" or "full processing", and when you hit "preview VBR", it will average exactly 25 fps. when you set "direct stream copy" and do the same, you'll get 70-90 fps.

it may well be that there's just extra processing going on somewhere that by coincidence slows it down to 25fps for PAL scripts and 30fps for NTSC scripts by pure chance, but that doesn't really seem likely.

the same happens in HC sometimes. if i were to encode a blankclip() in HC it will go extremely fast (40-50 fps), but if i encode an mpeg2source with no processing it'll stick to the framerate of the mpeg source.

i've not been able to track it down to anything, so i wondered if any devs would know what causes this apparent speed limit.

i guess it's something that hitherto hasn't really been noticed as most scripts (the vast majority) have enough processing going on that there's no possibility of reaching realtime. i've only noticed this as i encode a lot of high bitrate stuff that doesn't really require much processing, and i've also been optimising the balls off my core scripts (like customised deblocking, and several different methods of converting NTSC to PAL and vice-versa) to the point where they're running above realtime.

so yeah... any ideas? :)

[Manao]

when you hit "preview VBR", it will average exactly 25 fpsThat's a feature of VDub which acts like a player when you hit 'preview'.the same happens in HC sometimes. if i were to encode a blankclip() in HC it will go extremely fast (40-50 fps), but if i encode an mpeg2source with no processing it'll stick to the framerate of the mpeg source.I never encountered that behavior. But if HC 'fast' encoding on blankclip is 40-50 fps, then having a speed of 25 fps when encoding real content seems normal to me.

[Mug Funky]

hmm, actually, checking again VDM goes 25fps when it's on "normal recompress", but much faster on "fast recompress" and "direct stream copy".

as for HC, it just seems weird that for PAL it sticks to 25 fps and NTSC 30 fps. it may just be me, but it seems like too much of a coincidence, seeing as the clips benchmark much faster. i'm aware of course that mpeg-2 encoding eats a fair amount of juice.

could it be different frame access methods being used? i don't know enough about the guts of avisynth (or HC or VDM) to say if i'm just imagining things or not.

hmm, doing some specific testing, i'm thinking it might be a coincidence, but it's a weird one. by deliberately making things go too fast without regard for the output quality, i've been able to push it to non playback frame rates.

poop :( i thought there'd be a quick way to get more speed (i was looking forward to the idea of doing 2 passes in less time than it takes to play the movie).

[Manao]

"normal recompress" means colorspace conversion to RGB, then back to yv12 if you actually encode, so it's normal if it's slow. I can't see any reason why HC would try to encode in realtime ( it would uselessly complicates the code ), but I never used HC either, so...

Finally, PAL 25 fps and NTSC 30 fps have the same pixel rate, so if one is encoded in realtime, the other will be too.

[mg262]

Mug Funky,

What about taking a half-D1 source and checking with that?

[AVIL]

Hi all,

IMHO the problem, if any, isn't with avisynth. I think the real speed of an avisynt script is that of direct stream copy in VD (or nearly). For HC issue I suggest try with directshowsource, mpeg2source and avisource (with the same footage recoded to MJPEG for the sake of similarity in decodign speed). Could be a limitation of the dll that feed the source.

Good luck

[Mug Funky]

i think it may be just the pixel rate thing (i'd forgotten about that), and coincidence. it certainly is weird though.

i suspect half-d1 would go faster, but i'm too hungry and cranky right now to test it (i'm stuck at work waiting for a mac to do something completely ordinary. it's always the way).

[Boulder]

HC does encode as fast as it can..my encodes using MPEG2Source without any complicated scripts usually run at 25-30fps.

[IanB]

The only place I am aware a limit like this come up is in DirectShowSource() with ASF based media. Annoyingly the ASF splitter assumes the roll of clocking the graph and so far I have not found a way around this. In light of all the DRM crap assosiated with ASF this is very probably very intensional.