DirectShowSource.dll 2.5.8.8

[manolito]

For various (good) reasons I am still using AVISynth v. 2.56a. Can I use the latest DirectShowSource.dll with this version of AVISynth, or am I asking for trouble?

Cheers
manolito

[IanB]

For various (good) reasons I am still using AVISynth v. 2.56a.Hmmm interesting statement, are you sitting on unreported (or slipped through the cracks) bugs? :confused:

Can I use the latest DirectShowSource.dll with this version of AVISynth, or am I asking for trouble?Yes, it is a standard 2.5 plugin.

[Didée]

Ian, remember my past report about complex MVTools script being faster for me under 2.56a than under 2.58? (Probably because of 2.56's cache bug/feature.) - I'm still on the same old machine, and at the end of the day, 2.56a is still faster for me than 2.58. :)
(No, SetMemoryMax does not come to rescue, for whichever reason.)

[IanB]

@Didée,

I assume this post 1207290 is where you are talking about. I was never able to reproduce your results and nobody stepped up with anything to help me find it, so it slipped through a crack. I couldn't fix it because I couldn't see it breaking.

If you want to crack a devel thread with this issue for builds of 2.6.0's we can try to solve the problem again.

[manolito]

Hmmm interesting statement, are you sitting on unreported (or slipped through the cracks) bugs? :confused:
My main use of AviSynth is from DVD2SVCD which creates avs files automatically. This software uses some very old filter versions, and with newer versions of AviSynth than 2.56 I would have to insert SetPlanarLegacyAlignment() into my scripts manually. Too lazy to do this all the time, plus v. 2.56 has always worked perfectly for me...
Yes, it is a standard 2.5 plugin.
Thanks, this was what I had hoped for.

Cheers
manolito

[Didée]

@ Ian - yepp, that one. Good memory. :)

I don't think it's worthwile to track down that penomenon. Such ancient architecture really is disappearing nowadays. Better do care for the present technique.

For the record, my guess is that some change in memory/cache managment was done from 2.56 to 2.58 that doesn't hurt (or probably improve) on every *normal* CPU, but that causes *my particular* CPU to struggle more.

I'll show you my suspected culprit:

http://img535.imageshack.us/img535/5479/miniceleron.png http://img517.imageshack.us/img517/2760/miniceleroncache.png

Out of the sleeve, could that be a possible explanation? Some code change that works out practically everywhere, but is contraproductive with such hilarious bonsai-sized caches?

[IanB]

It's not caused by the SetPlanarLegacyAlignment() changes is it?

Line pitch 720y/360uv -> 736y/368uv, with a small cache this could tip what just managed to squeeze in to "oops it don't fit no more". Easy to test just bung a SetPlanarLegacyAlignment(False) at the end of the script and test with 2.5.6a.

And for completeness add SetPlanarLegacyAlignment(True) at the end of the script then test with 2.5.8.