Humbly requested: Filter SDK / Easy filter sample

[Si]

Just checking to see that your paying attention
(And it shows you can exceed the Y limits without causing an error )

Version 1.5a here
http://www.geocities.com/siwalters_u...esample15a.zip

regards
Simon

[sh0dan]

@Bidoche: The data is flipped on input, and all RGB<->YUV conversion flip the data. So RGB is always flipped internally in AviSynth.

[Si]

What I'm thinking of is a sample working in all colorspaces that manipulates the frame in some simple way (like drawing a centered square on it)

Done
Version 1.6 of SimpleSample here
http://www.geocities.com/siwalters_u...lesample16.zip

Thanks to everyone in helping me/us/we in getting there

@sh0dan
I didn't do anything with the vi.BytesFromPixels(1) as I haven't got my mind around it yet (being a bit slow and dim ) and I deliberately wanted to keep all colourspace code separate.

Now we've done the basic requirement do you (or someone else) want to optimise it?

Or add in some assembler, then MMX then SSE and all those other toyes you clever ones play with

regards
Simon

[Guest]

Originally posted by siwalters
Or add in some assembler, then MMX then SSE and all those other toys you clever ones play with

It would then no longer be "SimpleSample". It seems to me you have reached the appropriate stopping point.

[Bidoche]

A bit unclear to have the four codepaths in one method.
Now maybe the time to replace those ifs by polymorphism


@sh0dan

we can reverse blit on input if we want, will be more consistent and I won't have to do this ***** hack

[Richard Berg]

@Bidoche -- that would break all filters that currently assume RGB is upside-down. Can you point out where the conflict arises in 3.0?

[Bidoche]

All GetReadPtr and GetWritePtr simply forward calls to BufferWindow methods of the same name (which returns top left corner).

Change cannot be down at BufferWindow level without ugliness (it doesn't have to know its RGB).
But it should work redefining GetWritePtr and GetReadPtr in the RGBVideoFrame class. (in videoframe.h)

[sh0dan]

I don't see the problem. The only difference is that the pointer points to lower-left of picture in "screenspace". Bufferwise it looks exactly like YUY2/YV12.
The picture is made the same way as all other - the only difference is that the lowest line is displayed as the upper line.
The pointer will still point to the first byte in the allocated array.

[Bidoche]

Hum, didn't understand it like that. So there is nothing to change.

And I have found a (minor) problem : if we add an alpha plane to each colorspace (besides rgb32), we won't be able to share it in the copy...

[Si]

...perhaps in a future version samples for doing temporal stuff ...

Anyone fancy doing this bit then?


Simon

[Bidoche]

@sh0dan

From the videoframe client perspective, is it a difference between starting at top left with positive pitch and starting at bottom left with a negative pitch ?

If current code can feed from that, RGB don't to have to be really flipped (just appear it is)

[sh0dan]

Negative pitch is a no-no internally in AviSynth - at least - much assembler would have to be rewritten. Let's just keep RGB bottom-up, with positive pitch - there is no need to make things more complicated than that.

[Bidoche]

@sh0dan

As expected, it's not possible... :'(

@siwalters

Here is the OOP version I promised...
... in 3.0 style, but besides it allowed me to skip the copy part, it don't change much.

class SimpleSampleParent : public GenericVideoFilter {
public:
  SimpleSampleParent(PClip _child, int _SquareSize) : GenericVideoFilter(_child), SquareSize(_SquareSize) { }

  virtual CPVideoFrame _stdcall GetFrame(int n)
  //in 3.0 there is a distinction from CPVideoFrame and PVideoFrame
  //C stands for const, those cannot be modified
  {
    PVideoFrame frame = chid->GetFrame(n);
    //conversion a CPVideoFrame to a PVideoFrame
    //does what is needed to allow modifications
    //(I can develop if you want)

    Process(frame);  //call the filling method
        
    return frame;    //implicit cast from PVideoFrame to CPVideoFrame        
  }

protected:
  // define the parameter variable
  const int SquareSize;

  virtual void _stdcall Process(PVideoFrame frame) = 0;

  void _stdcall ByteSquareFill(BYTE * dstp, int pitch, int width, int height, BYTE fillPattern)
  //method to fill a rect with a BYTE value
  //used in RGB and YV12
  {
    for(int h = height; h --> 0; dstp += pitch)
      for(int w = width; w --> 0; )
        *(dstp + w) = fillPattern;
  }

  BYTE * _stdcall FindSquareLeftCorner(PVideoFrame frame, Plane plane, int BpP, int scaleFactor = 1)
  {
    Byte * result = frame->GetWritePtr(plane);
    result += (frame->GetHeight(plane)>>1 - SquareSize>>1/scaleFactor) * frame->GetPitch(plane);
    result += frame->GetRowSize(plane)>>1 - SquareSize>>1/scaleFactor * BpP;
    return result;
  }
};


class SimpleSampleRGB : public SimpleSampleParent {
//no distinction between RGB24 and RGB32
//I fill alpha with 255 too
//if that is unwanted make a special version for RGB32

public:
  SimpleSampleRGB(PClip _child, int _SquareSize) : SimpleSampleParent(_child, _SquareSize) { }

protected:
  virtual void _stdcall Process(PVideoFrame frame)
  {
    int BpP = vi.IsRGB32()? 4 : 3;
    ByteSquareFill(FindSquareLeftCorner(frame, NOT_PLANAR, BpP), frame->GetPitch(), BpP*SquareSize, SquareSize, 255));    
  }
};


class SimpleSampleYUY2 : public SimpleSampleParent {
public:
  SimpleSampleYUY2(PClip _child, int _SquareSize) : SimpleSampleInterleaved(_child, _SquareSize) { }

protected:
  virtual void _stdcall Process(PVideoFrame frame)
  {    
    BYTE * dstp = FindSquareLeftCorner(frame, NOT_PLANAR, 2);
    int pitch = frame->GetPitch(NOT_PLANAR);
    for(int h = SquareSize; h --> 0; dstp += pitch)
      for(int w = SquareSize>>1; w --> 0; )
        *((unsigned int *)dstp + w) = 0x80EB80EB;	
  }
};

class SimpleSampleYV12 : SimpleSampleParent {
public:
  SimpleSampleYV12(PClip _child, int _SquareSize) : SimpleSampleParent(_child, _SquareSize) { }

protected:
  virtual void _stdcall Process(PVideoFrame frame)
  {    
    static const BYTE fillPatterns[] = { 235, 128, 128 };
    static const int scaleFactor[] = { 1, 2, 2 };

    for(int i = 3; i --> 0; )
      Plane p = VideoFrame::IndexToPlane(i);
      int s = scaleFactor[i];
      ByteSquareFill(FindSquareLeftCorner(frame, p, 1, s), frame->GetPitch(), SquareSize/s, SquareSize/s, fillPatterns[i]);    
    }  
  }
};


AVSValue __cdecl Create_SimpleSample(const vector<AVSValue>& args) {

  PClip clip = args[0]; //implicit conversions
  int sq = args[1];
  switch(clip->GetVideoInfo().GetColorSpace().id)
  {
    case I_RGB24:
    case I_RGB32:
      return new SimpleSampleRGB(clip, sq);
    case I_YUY2:
      return new SimpleSampleYUY2(clip, sq);
    case I_YV12:
      return new SimpleSampleYV12(clip, sq);
  }  
}

[Si]

Very interesting - if only I understood it

I had a go at trying to hack it to work in 2.5 but didn't get any where - is it possible to do it?

[EDIT] I mean can it be done at all? (or do you need the 3.0 enviroment to make SimpleSample OOP friendly?) [/EDIT]

regards
Simon

[Bidoche]

@siwalters

It is possible to do it with 2.5, but the code is longer and I am not as used to it.
And I didn't not wanted to copy the frames by myself (in fact I could have blitted them ), 3.0 does it automatically (and I like automatic things (if you don't, you should)).

Please point to what you don't understand and I will try to provide explanations (please don't say everything, it won't get us anywhere )

Edit:

It occured to me that we can use BitBlit to fill the squares provided we fill a BYTE raw somewhere with the good pattern (and a 0 pitch).
This way RGB and YUY2 can even be more merged together.

Will see it tomorrow, it's getting kinda late here

@sh0dan

Please don't tell me 0 pitch is forbidden.

[Si]

I won't say everything .

I didn't mean to distract you from 3.0 - please just ignore my request.

regards
Simon

[Bidoche]

I can do it, no problem.
And besides sometimes I can use the distraction.

[Bidoche]

Well let's do some comments...

In the above code, I made two kind of transformations:
- one is the transformation of the original class into a parent class and some subclasses (ie using OOP legacy/polymorphism)
- the other is just a factorisation of the code, with the functions ByteSquareFill and FindSquareLeftCorner(which I am not so happy about it :/).

To perform the first, used the natural colorspace hierarchy :

General --- Interleaved --- RGB --- RGB24
        \               \       \-- RGB32
         \- YV12         \- YUY2

I guess everyone will agree that how colorspace are naturally grouped
(sometimes YV12 and YUY2 are better seen siblings but not often)

Looking at your code, you search for similitude :
- RGB24 and RGB32 both fill a memory rectangle with 255, then the fill code can be shared and each just need its own rectangle coordinates calculation .

- YUY2 and RGB (24 & 32) both fill a memory rectangle with a specified pattern (FFFFFFFF for RGB, I forgot for YUY2).
Then if I make sych a method it can be shared (and called by the RGB 255 fill method)

- YV12 fills memory blocks like RGB so I can reuse its method (factorisation)

so you have (in pseudo-code)

class parent {
void patternFill(some memory coordinates, pattern);  //a factorisation
pattern bytePattern(int patternlength, byte ToMakeThePatternWith) //same thing
};

class interleaved {
  virtual pattern makePattern(int length) = 0;
};

class interleaved {
  virtual PVideoFrame GetFrame()... //getFrame imple
  //relies on BitPerPixels(colorspace) to get memory coordinates right
  //and call patternFill(makePattern)
};

class yuy2, rgb24, rgb32 {
  virtual pattern makePattern(int length)  //implementation
  //if we set rgb32 alpha to 255 we merge rgb32 and rgb24 (I did this)
  //use of the factorised bytePattern in rgb24 (and maybe 32)
};

class yv12 { 
  virtual PVideoFrame GetFrame...
  //planes coordinates calcul
  //call PatternFill(..., bytePattern) on each plane)
};

Is that better ?

[Si]

Cough Cough
Obviously a moderator and a 3.0 developer can do what they want but have you thought about putting this in a separate thread?

says Simon who then runs away to hide from a thunderbolt from above

[sh0dan]

@siwalters: Being moderator makes it possible to fix these things.

For discussions related to frametypes in Avs 3.0 - see this thread.