Proposal for AviSynth 2.6

[sh0dan]

Is Avisynth capable of reading dvr-ms files with any current plugins, or is that something that is on the roadmap for the future?

I'd like to request it if it's not...

Even though it's MPEG 2, MS doesn't provide information about the format, since it's DRM'ed. AFAIK there are conversion tools available to convert it to other formats.

If it's playable using DirectShow you should be able to open it using DSS.
On another note, I think it would be really powerful if you would extend the DirectShowSource function to allow scripts to specify the exact DirectShow filter chain to use. I know that I could change the priorities of certain filters, but to have manual control over filters through Avisynth would be incredible!
Use GraphEdit to make your graph, and open the GRF file using DirectShowSource. See the documentation on avisynth.org.

[jeffmikels]

Even though it's MPEG 2, MS doesn't provide information about the format, since it's DRM'ed. AFAIK there are conversion tools available to convert it to other formats.


I don't think the format is DRM. My reading on the subject leads me to believe that the format has the capability of carrying encrypted streams or unencrypted streams and that the format itself is publicly available. I thought DVR-MS was supposed to be simply a wrapper around other streams.

http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/directx9_c_Summer_03/directX/htm/aboutthedvrmsfileformat.asp


If it's playable using DirectShow you should be able to open it using DSS.

Use GraphEdit to make your graph, and open the GRF file using DirectShowSource. See the documentation on avisynth.org.

Opening a DVR-MS file with DSS yields a video stream that plays twice the normal speed and an audio stream that plays at normal speed.

Opening a GRF file in Avisynth has been nearly impossible for me to figure out. Apparently Avisynth doesn't recognize the open pins on the end of my graph even though I only remove the final render filters. On top of it, there's no way I know of to programmatically change the source file (the input source) of a GRF.

[Wilbert]

Opening a DVR-MS file with DSS yields a video stream that plays twice the normal speed and an audio stream that plays at normal speed.
Did you set the fps parameter?

Opening a GRF file in Avisynth has been nearly impossible for me to figure out. Apparently Avisynth doesn't recognize the open pins on the end of my graph even though I only remove the final render filters.
Could you post a screenshot of your graph and state the error message?

[Fizick]

Sorry, I am not sure, if this question was discussed:

Can we give info about internal (and plugin's) functions parameters names (and types) to external programs (like AVSEdit) ?
This info may be somehow used internally too.

[sh0dan]

Sorry, I am not sure, if this question was discussed:

Can we give info about internal (and plugin's) functions parameters names (and types) to external programs (like AVSEdit) ?
This info may be somehow used internally too.
Internal and external (plugin) functions are exported as AviSynth Variables.

$InternalFunctions$ Should contain function names of all internal functions.
$InternalFunctions!Functionname!Param$ Should contain all parameters for each internal function.
$PluginFunctions$ Should contain all plugins.
$Plugin!Functionname!Param$ Should contain all parameters.

Use env->GetVar() to access them.

[Fizick]

sh0dan,
Thanks for good (old ?) news. It was true for Avisynth 2.5.5?
It is interesting, why AVS-editors do not use it, but use some external function descriptions in xml-files.

So, there are no info for parameter's type?

[sh0dan]

External plugins have been exported for several versions, I believe the Internal functions were added by Ian for 2.5.6. Vdubmod use the plugin export for syntax highlighting.

You can use a try/catch mechanism, when you request "$InternalFunctions$". If you get a "NotFound" exception, people are using an earlier version.

Parameter types are passed in the "$Plugin!FUNC!Param$". They are delivered as they are specified in the filters "c[type]s[audio]b", etc.

[Fizick]

I know about syntax highligting in VDMod, (recently i added some new words to new VDMod version) , but it still not use parameters names. It will be very useful hints for user. I hope, somebody read this info and implement it.
So, one more undocumented Avisynth feature is opened. :)

[sh0dan]

Yes - you are right. I actually planned to do a "How to use avisynth directly from your application", but never got around to doing it. I'll put it on my to-do-list (which is basicly scattered in this thread).

While Ian works out if there is a solid solution to the baked code, I'll do some time documenting the new colorspace stuff in 2.6.

[Wilbert]

I'll do some time documenting the new colorspace stuff in 2.6.
I already added much about this at avisynth.org :) I still have to copy it to sourceforge.

[IanB]

I've just finished a session Planarising various bits and pieces, and I found myself coding (vi.IsPlanar() && !vi.IsY8()) a lot more than I would like. I am slowly coming to the realization that IsPlanar maybe should respond false for Y8 data.

What do others think?

And I am becoming convinced that I was right that the core should treat planar formats genericly and just look at the H and V subscaling factor. Using the various IsYV??? seems to paint oneself into a corner quite code wise. I suspect removing them from the API in favour of various representations of subscaling factors i.e. BitShift (0, 1, 2), Mask (0, 1, 3), Divisor/Multiplier (1, 2, 4), etc would be a positive thing.

Thorts?

IanB

[Bidoche]

I like Y8 being planar, after all for some tasks, it can be handled exactly like them.

You may just need a method to get the list of available planes.

[mg262]

I found myself coding (vi.IsPlanar() && !vi.IsY8()) a lot more than I would likeCould you give us some examples?

For the second, IMO the more structural information describing colour spaces available, the better... that number and possibly type of planes, sub sampling factors, and colour depth. By type I mean something like this:

Luma
chroma (in the presence of luma -- e.g. Y)
chroma (in the absence of luma -- e.g. R)
alpha channel

I'm not sure whether this is overkill, but being able to get hold of the number of planes and colour depth are more substantive.

[foxyshadis]

Isn't Y16 also going to be available, in which case that would have to be blocked from multiplane access areas? It seems (vi.IsPlanar() && vi.PlaneCount() > 1) would make more sense. (However you were to implement a # of planes property.)

[Wilbert]

Isn't Y16 also going to be available, in which case that would have to be blocked from multiplane access areas?
It's YV16, which has three planes.

[Bidoche]

Shouldn't be the correct code here be : vi.IsPlanar() && vi.IsYUV() ?

[foxyshadis]

It's YV16, which has three planes.
I must have misread a while back, I thought a 16-bit greyscale was going in as well. Sorry!

[sh0dan]

@IanB: I was also a bit amazed at how much special code Y8 needed. But in reality it's usually pretty easy to handle. Since:

* PVideoFrame->GetWidth(PLANAR_U) and GetHeight return 0. This make 90% of the routines skip chroma.
* Usually just a matter of returning the destination frame when luma processing is done.

I considered if there was another solution, but didn't see any significantly better way. Making Y8 "not planar" would lead to a lot of (vi.IsPlanar() || vi.IsY8()) in the cases where ordinary planar code could be used.

Mask & Divisor/Multiplier are nice helper functions, though I don't want to encourage multiplication/division. :D (Just kidding - they would be nice to have)

[IanB]

Yes, IsPlanar() is not the right test for where I have been working, something like plane enumeration, PlaneCount or IsMultiPlane() is what should be being used. I'll survey the code and think about it a bit more.

Probably helper vi.Validate(const char *messagetext) is what we should have.

[Bidoche]

Probably helper vi.Validate(const char *messagetext) is what we should have.What would you be passing in messagetext ?

[Bidoche]

related link :

http://aegisknight.org/cppinterface.html

[IanB]

> What would you be passing in messagetext ?

Probably the name of the script verb choking on it's parameters.

i.e. "Crop : YV411 images must be Mod 4 width."

> related link :

Pity Ben didn't read this years ago :D

[jeffmikels]

Did you set the fps parameter?



Yes.


Could you post a screenshot of your graph and state the error message?

The error message says:
Video Returned: DirectShowSource: The filter graph manager won't talk to me
Audio Returned: DirectShowSource: The filter graph manager won't talk to me

I'm attaching a screenshot of my graph.

[IanB]

Okay, I have had a quick survey of the IsPlanar() use in the code.I found myself coding (vi.IsPlanar() && !vi.IsY8()) a lot more than I would like. I am slowly coming to the realization that IsPlanar() maybe should respond false for Y8 data.And as I said, I now more strongly believe CS_Y8 should not include the CS_PLANAR bit. Given the current state of play the CS_PLANAR bit would be best utilized to say simply and exclusively This format has separate data planes for each channel!

I like Y8 being planar, after all for some tasks, it can be handled exactly like them.Making Y8 "not planar" would lead to a lot of (vi.IsPlanar() || vi.IsY8()) in the cases where ordinary planar code could be used.This is not a good reason to have Y8 included in the set of Planar formats. I would actually prefer seeing (vi.IsPlanar() || vi.IsY8()) coded in these cases because it states This code is good for both single and multiple plane data. All the current interleaved formats can be treated the same as each plane for vertical operations, and we wouldn't want to declare them planar just because of that. In a lot of cases Y8 data processes equally well thru both the planar and interleaved code paths.

I was also a bit amazed at how much special code Y8 needed.

* PVideoFrame->GetWidth(PLANAR_U) and GetHeight return 0. This make 90% of the routines skip chroma.And that is the crucial rub. Not all code copes with zero dimmension planes. I have always been uneasy trusting routines to correctly do nothing with a plane because the dimensions are zero. Most coding bugs fall under the category of boundary condition errors, off by 1 errors being the most prevelant. And these bite here.

By not pressing the boundary conditions of code more reliable software ensues. If the conditions to expose a bug can never occur then the bug never occurs.


Yes, IsPlanar() is not the right test ..., something like ... IsMultiPlane() is what should be being used. I'll survey the code and ...Much earlier in this thread I proposed that Y8 also include the CS_INTERLEAVED bit as well as the CS_PLANAR bit. Having had some experience actually implementing this now I change my position and believe Y8 format should not include either of these bits and IsPlanar() is the appropriate name and test.

Format Y8 really stands alone, it shares most of the benefits of both planar and interleaved formats but does not suffer from the deficiencies of either. Having a test like IsPlanar() is most beneficial when it can be succesfully used to filter for both benefits or restrictions of a given data set.

Thorts?

IanB

[sh0dan]

New "tweak" functionality by Wilbert:

1) It enables you to adjust the hue and/or saturation in a specific hue range [startHue,endHue] and/or in a specific saturation range [maxSat,minSat]. Some interpolation to the prescribed saturation range is added to prevent color banding. The interpolation can be set with interp (interp=0 won't interpolate, interp=4 is maximal).

2) Added planar support (trivial).

I removed the SSE code. It's not being used since it's slower, and there were many conditions in which it wasn't used. Parameter is still present for script compatibility, but simply ignored.

[mg262]

Planar Tweak -- :)

Ian,
May I go back to Planar/Y8? Specifically: is it that people have previously been using IsPlanar() where they should have been using IsYV12(), or is it that there are genuine cases where code deals with any planar colourspace except Y8?

[Fizick]

All these planars is important...
But may I ask once more about some special arbitrary (not video) format or additional custom data for such plugins as MVTools, Motion (motion vectors), DePan (global motion), DeComb (hints) ? Now they use hacks with frambuffers in various video formats.

[mg262]

May add I something similar to mull over? At present, working with floats, integers or bools on a per-frame basis requires the use of ConditionalFilter/ScriptClip... apart from any other problems, they can impose linear-access requirements if you look at previous frames' info. I claim that it would be preferable to have streams of floats, integers and bools (in exactly the sense that a clip is a stream of videoframes) -- i.e. something that assigned one float to every frame, or integer to every frame, or etc.

I've mocked such things up for my own use (and you can see a little of it here (http://forum.doom9.org/showthread.php?p=728296#post728296)); it takes a little getting used to, just like using Trim(1, 0) to get the "next" frame does, but IMO its works pretty well. It would be nice if the language supported such things, because it would make it much easier to pass information between filters -- for example, scene break information could be passed as a stream of bools, and blend-detection information as a stream of floats.

I suspect that this may be considered too complex ... but it's worth a try :)

[sh0dan]

@Fizick:
The only way I can see meta-data streams is using the method mvtools use for it. You now have Y8, which is a singleplane single-byte array.

You can put whatever data you wish into such a plane, it'll be cached properly, you can use changefps, selectevery and still maintain frame-to-frame mapping with your image data. It does the job, it does it without modifying any code, and it does the job well.

Agreed, Donalds 'hints' was a hack, but using Y8 to stream meta-data seem like a pretty solid way. You don't have to do any code, that you wouldn't have to do on any other meta-stream.

[sh0dan]

@mg262:
While I agree it would be really great, I think it would be hard without rather large redesign. Conditional filtering as it is IS a hack. When used with global variables, it isn't thread safe, which IS bad.

We could add a function to ScriptEnv, that wrapped AVSValues in a Y8 stream. A "conditional" script would than be like this:

Source filter constructor calls env->CreateStream(&vi, number_of_AvsValuesPerFrame, const char* "TypeIdentifier"), which filles out VideoInfo with the appropriate info (Y8, width, height).

GetFrame calls env->WrapValues(PVideoFrame *dst, AVSValue* ArrayOfAvsValues).

The destination filter could use AVSValues* v = PClip->UnWarpValues(PVideoFrame *src);

This would be the basic principle - and all conditional processing could be translated into this. Some "finer details" about passing the size of the AvsValue array is missing, but the principle is there. "TypeIdentifier" should be there so that filters can ensure that they get expected input (if they care).

It does open up a lot of potential bugs, but it definately solves more problems than it creates.

[mg262]

sh0dan,

I think that being able to have streams of AVSValues is more than needed... and it allows creation of e.g. a stream of streams of AVSValues, which is not a sensible type. Streams of structures would be nice, but simply having streams of the three basic types supported by ConditionalReader, namely bool, int, float, would deal with most things.

I haven't looked at the framework enough to know how hard it is. I don't know whether it would be of any interest, but my code to set up four or five different stream types takes 200 lines or less; the basic setup looks like this:*

*This code is not tidied up to a satisfactory standard. I am somewhat embarrassed to post it. But this discussion is happening now, and I won't have time to tidy this for a while...

template <class T> class Stream //behaves like vector<T>
{
protected:
PClip encoded;
public:
Stream(PClip c) : encoded (c) {}
T point(int n, IScriptEnvironment* env) const
{return T(encoded->GetFrame(n, env));}
};

template <class T> class FilterReturning : public GenericVideoFilter
{
public:
//FilterReturning(const FilterReturning<T> &) {}
FilterReturning(PClip _child, IScriptEnvironment* env);
virtual T GetPt(int n, IScriptEnvironment* env) = 0;
virtual PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env)
{return GetPt(n, env).toFrame(vi, env);}
};

struct NumberData
{
double value;
//NumberData(double _value) : value (_value) {}
};
class NumberPt : public RawIO<NumberData>
{
public:
NumberPt(double d=0){ value =d;}// : x(_x), y(_y) {}
NumberPt(const RawIO<NumberData> &r) : RawIO<NumberData>(r) {}
};
typedef Stream < NumberPt > NumberStream;
typedef FilterReturning < NumberPt > NumberFilter;
(I've excluded the I/O code as this is relatively long and uninteresting.)

So NumberFilter::GetFrame calls the virtual function
NumberPt NumberFilter::GetPt(int n, IScriptEnvironment* env)
(which is overridden by the plugin author) and stores the returned NumberPt in a frame.

Going the other way, a NumberStream can be constructed from a PClip; and numberstream.point(n, env) extracts the relevant value via GetFrame.

Together, these give almost no overhead over using a clip... the only difference is that as you don't have AVSValue::AsNumberStream(), you need to use NumberStream(args[x].AsClip).

There is more I could say... but I don't want to go on for too long.

Edit: But this is important; having one AVSvalue per frame -- and preferably of a fixed type -- lets you override the inbuilt operators (not necessarily in the first release). So if you have two number streams, a and b, you want to be able write a+b in your script and get another number stream back. It also allows automatic promotion float->floatstream, so you can use constant streams easily.

[Fizick]

sh0dan,
Y8 is a little better, but what if somebody will try for example Resize this meta-clip ?
May be some special mark (CS_METADATA or CS_NONVIDEO) for it?
MVTools still use hack with audiochannels number.

[mg262]

MVTools still use hack with audiochannels number.But that is used to pass information upstream. Even if you had built in support for arbitrary colourspaces and arbitrary information attached to frames, I don't see that you could use them to pass information upstream?

[MfA]

Occasionally you might want filtered output of previous frames from later in the chain as input too, not just numerical values. Ideally you would just loopback a clip in script.

[IanB]

New "tweak" functionality by Wilbert:

1) It enables you to adjust the hue and/or saturation in a specific hue range [startHue,endHue] and/or in a specific saturation range [maxSat,minSat]. Some interpolation to the prescribed saturation range is added to prevent color banding. The interpolation can be set with interp (interp=0 won't interpolate, interp=4 is maximal).I appreciate the new capability and find it quite functional.

:angry: However, I am not pleased with the absolutely massive performance hit this has introduce! :angry:

I put considerable effort into writing and tuning the mapping code to get this filter fast. I was quite surprised at the time how fast the mapping code was. I was astounded that I could not even come close with the MMX/iSSE code, no matter what I did.

I expect to see a replacement version in CVS soon that restores or exceeds the previous level of performance. Hint: Start by moving the if (allPixels) test outside the loops and putting the old code in one branch and the new code in the other. When it's fixed and I have stopped seathing I'll see what can be done to make the new chroma range limited code perform passably.

[IanB]

Planar #*!@$ -- :)

May I go back to Planar/Y8? Specifically: is it that people have previously been using IsPlanar() where they should have been using IsYV12(),There possible are cases in the wild but it is not an issue here.or is it that there are genuine cases where code deals with any planar colourspace except Y8?Well yes, sort of. So far there are no "genuine cases" where the Planar path fails for Y8 data. But that is really by more good luck and carefull programming than good managment.

From a practical point of view the code would on balance be cleaner if IsPlanar() returns false for Y8 format data. Doing this coerces the meaning of Planar to mean "Has multiple data planes" rather than a more literal meaning of "Data is arranged in single planes" which I don't think is really much of a stretch.

[IanB]

@Fizick, mg262, sh0dan, MfA,

Unfortunatly, no matter how we cloak it metadata within the current architecture is always going to be a hack or a really big rewrite. Marking a stream with say CS_METADATA won't stop filters munging with it, most current code just tests for what it needs to be special and does something generic with the rest, i.e. if (x.IsPlanar()) {planar code} else {default code}. David has vastly improved structures for coping with this is 3.0 hopefully the final coding model will enforce against our current limited thinking.

[sh0dan]

I appreciate the new capability and find it quite functional.
[...]
:angry: However, I am not pleased with the absolutely massive performance hit this has introduce! :angry:
[...]
I expect to see a replacement version in CVS soon that restores or exceeds the previous level of performance. Hint: Start by moving the if (allPixels) test outside the loops and putting the old code in one branch and the new code in the other. When it's fixed and I have stopped seathing I'll see what can be done to make the new chroma range limited code perform passably.
Easy now. We are in pre-alpha. No need to throw angry faces at people.

I made UV-processing a single lookup per 2 chroma components in a 128k table. We could compare, but I'd be VERY surprised if it doesn't outperform both of the old versions (C and iSSE).

@Wilbert: You might want to re-test your "interp" code. It wasn't activated in the code, as it was missing in the filter definition - this was also why the isse switch you had at the end was acting up.

[mg262]

The 128k table will play havoc with the cache. (Ian pointed this out to me some time ago.)

On the filter I was looking at this for, the values looked up were luma differences and were typically very small, so you tended to access the same parts of the table, and the paired lookup table had a small edge. Here, where the values would range widely, I'd expect it to do substantially worse due to cache misses.

[sh0dan]

The 128k table will play havoc with the cache. (Ian pointed this out to me some time ago.)
[...]

Thanks for pointing this out.

1) L2 caches are at LEAST 256k on modern processors.
2) Chroma is usually very close to 128.
3) Would you agree that a single lookup in L2 cache is USUALLY faster than:
* 4 lookups in a 256 byte table.
* 1 Addition
* 1 Subtraction
* 2 Multiplications
* 2 Bitshifts
* A min(x,y) function.
* A max(x,y) function.

Or am I just daydreaming?

Edit:
Speed in AviSynth 2.56: 584 fps.
Speed in AviSynth 2.6: 986 fps.

(1265 frames 720x576).

If you want it even faster you could make it skip Y or UV planes if they aren't changed. But this is fast enough for me.

[mg262]

sh0dan,

My mistake -- I apologise. I forgot that output U depends on source U and V [not just source U], so I was thinking of two separate look-ups.

986 FPS is fast enough for anyone!

[Fizick]

IanB,
1) In my opinion, we may use CS_METADATA=CS_UNKNOWN=0 for metadata clips.
Almost all filter will not process such clips (it is not planar, not interleaved, not YV12, not RGB, not YUY2, etc) . The only needed operations with metaclips are probably full-frame manipulations with Changefps, interleave, selectevery and similar (as Sh0dan pointed).
Of course we must change BitsPerPixel default (for CS_UNKNOWN) from 0 to 8 in avisynth.h.
Is it possible?

2)The second question is about MVTools hack with audiochannels number.
As pointed by Mg262, it is used somehow to transmit poiter of MVanalysis data. I do not understand the manao's code . Probably it is for speed increase to do not calculate some values repeatedly.
Here is part of mvanalyse.cpp:

// we'll transmit to the processing filters a handle
// on the analyzing filter itself ( it's own pointer ), in order
// to activate the right parameters.
vi.nchannels = reinterpret_cast<int>(&analysisData);

I do not understand, how good or bad it is (i am not programmer :) ).
Any comments?

[mg262]

On 2, I think that it is to give a speed increase in MVAnalyse by not calculating some values at all. So, for example, MVAnalyse only computes block variance if it is going to be used by some other filter.

But, how is MVAnalyse to know whether block variance is needed? This is difficult, because no data flows from other filters to MVAnalyse, only from MVAnalyse to other filters. So Manao has essentially stuffed a pointer to the MVAnalyse filter somewhere (specifically, vi.nchannels) where it can be picked up by other filters; those other filters then use this pointer to tell MVAnalyse what they need.

This is not guaranteed to work by C++ -- the behaviour is implementation-defined. However, it works with MSVC, at least as long as you don't e.g. put TCPDeliver/TCPSource in. It seems to me that it would be tricky to add this behaviour to the framework.

[MfA]

@Fizick, mg262, sh0dan, MfA,
Unfortunatly, no matter how we cloak it metadata within the current architecture is always going to be a hack or a really big rewrite. Marking a stream with say CS_METADATA won't stop filters munging with it, most current code just tests for what it needs to be special and does something generic with the rest, i.e. if (x.IsPlanar()) {planar code} else {default code}. David has vastly improved structures for coping with this is 3.0 hopefully the final coding model will enforce against our current limited thinking.If you use Shodan's suggestion and use an extra clip for metadata you could add a format none of the standard filters can munch to make sure users dont accidently pass the metadata the wrong way.

That wasn't really what I was talking about though, regardless of how the metadata is passed mg262 seems to want the ability to access (meta)data added to previous frames by filters later in the chain. He only wants it for some numerical values for scenechange detection and such apparently, but if you put metadata in a seperate clip then just looping back a clip as input for a filter earlier in the chain would be a more generic solution (with at least a 1 frame delay to keep things deterministic of course).

[mg262]

mg262 seems to want the ability to access (meta)data added to previous frames by filters later in the chain. He only wants it for some numerical values for scenechange detection and such apparently, but if you put metadata in a seperate clip I want no such thing, nor did I ask for it.

I don't want to add data to frames at all, and in fact I think that metadata of this kind is a subpar solution for a number of reasons. I asked for a type -- probably implemented as 3 extensions to AVSValue that would store an stream of floats (or an stream of integers or and stream of bools). For present purposes, a stream is much like an array, except that it has lazy evaluation, i.e. values are only computed on demand.

Here is another way of putting it:
I want x, where x is to int as a clip is to a video frame.

[MfA]

If the numbers are associated with frames they are frame metadata.

[mg262]

The numbers are not associated with frames any more than video frames are numbered. You can take the third number and treat as if it corresponds to the third frame, and this is often a sensible thing to do, but it's not mandatory. I'm not going to argue terminology -- call it meta-data if you want -- but it's not tied to a particular clip.

I certainly don't only want it for scene change detection; that was one of the examples I gave, together with blend detection, but it's a complete replacement mechanism for ConditionalFilter.

[squid_80]

Here is part of mvanalyse.cpp:

// we'll transmit to the processing filters a handle
// on the analyzing filter itself ( it's own pointer ), in order
// to activate the right parameters.
vi.nchannels = reinterpret_cast<int>(&analysisData);

I do not understand, how good or bad it is (i am not programmer :) ).
Any comments?
It really annoys me when programmers cast pointers to ints.

[Manao]

squid_80 : it's not like I had the choice... I must put the data into the videoinfo, and it is made of int only, so...

his is not guaranteed to work by C++ -- the behaviour is implementation-defined.Why wouldn't it work ?

[IanB]

Easy now. We are in pre-alpha. No need to throw angry faces at people. :cool: :) :D :thanks: No offence intended. There seems to be a poor range of displeasure icons since vBuletin 3, I really wanted :mortified: rather than : angry :

I made UV-processing a single lookup per 2 chroma components in a 128k table. We could compare, but I'd be VERY surprised if it doesn't outperform both of the old versions (C and iSSE).Now this is the ticket. Any half modern processor cache is gonna swallow a 128K table easily these days. Even my old PIImmx, which struggles a little cachewise, runs a whisker faster than before and anyway it can't run the iSSE code. Good job :D