Copying yv12 compnents into C arrays

[lexor]

So I'm studying Simple Sample 1.7 (http://www.avisynth.org/SimpleSample+1.7), but for the life of me I can't figure out how, based on that code, I can load up Y, U, V plane data into 3 2D arrays of doubles in C or C++. Is there any sample code on how to do that? Or a javadoc like documentation for PluginSKD for AviSynth? That'd be great!

Thank you in advance guys!

[neuron2]

I can't figure out how, based on that code, I can load up Y, U, V plane data into 3 2D arrays of doubles in C or C++. Why do you want to put the data into a floating point representation?

[lexor]

Why do you want to put the data into a floating point representation?
Is it not in FP representation already internally? Anyway the reason I want the 2D arrays is since from what I understand AviSynth internally stores values based on a 2D scheme (so x,y coordinates), once I understand how to get 2D array I can string them out into a long vector and solve a large sparse linear system. Ax=b for x, where A is denoiser matrix, b is (Y or U or V plane, work on one at the time) and x is denoised image. A research project of mine.

[hanfrunz]

Hello lexor,
the data is stored in 8bit bytes. Y' ranges from 16 to 235, Cb and Cr range from 16 to 240. Use google and search for "Rec.601" and study this articels on www.poynton.com (http://www.poynton.com/Poynton-video-eng.html) to understand all that colorspace stuff.

hanfrunz

[lexor]

Hello lexor,
the data is stored in 8bit bytes. Y' ranges from 16 to 235, Cb and Cr range from 16 to 240. Use google and search for "Rec.601" and study this site http://www.poynton.com/ to understand all that colorspace stuff.

hanfrunz
will do, but unfortunately that doesn't help me with this current problem, even if it stores it as bytes in some integer range, I can normalise them to doubles between 0 and 1, that's not the problem, the problem is getting them out of AviSynth and into C array, that's the part I'm asking help with.

[hanfrunz]

okay, but did you understood how YV12 works? You have 3 planes. One is Y' it is in full resolution. The other two components are stored in a quarter of the Y' resolution. 300x200 -> 150x100
In a Avisynth filter you can read one line at once, the next line may start a few bytes later (src_pitch and dst_pitch in the simplesample code).
So just read line1 store it in your array, move the pointer to the next line and repeat until you are ready. i hope that helps you...

hanfrunz

[lexor]

btw what is the inteded effect of the simplesample filter? all I see is it copies source values over to destination and increaments the last one by a constant. Is that it? So in my case, all I need is srcp values?

for (h=0; h < src_height;h++) {
for (w = 0; w < src_width; w++)
*(dstp + w) = *(srcp + w);
srcp = srcp + src_pitch;
dstp = dstp + dst_pitch;
}
that seems like it doesn't do anything, I mean it sets *(dstp+w) = *(srcp+w), that's just pointer arithmetic, but it's the only thing done in the inner loop, and dstp and srcp are primitive vars not arrays, srcp=scrp + src_pitch only works on the last value of srcp. and value of dstp are never written anywhere, so what's the point?

[hanfrunz]

btw what is the inteded effect of the simplesample filter? all I see is it copies source values over to destination and increaments the last one by a constant. Is that it? So in my case, all I need is srcp values?

yup! its just a simple sample :)
the srcp is a pointer, it points to a value in the memory. so if you want the value of a pixel you have to do something like that

value=*(dstp+any_offset);



for (h=0; h < src_height;h++) {
for (w = 0; w < src_width; w++)
*(dstp + w) = *(srcp + w);
srcp = srcp + src_pitch;
dstp = dstp + dst_pitch;
}
that seems like it doesn't do anything, I mean it sets *(dstp+w) = *(srcp+w), that's just pointer arithmetic, but it's the only thing done in the inner loop, and dstp and srcp are primitive vars not arrays, srcp=scrp + src_pitch only works on the last value of srcp. and value of dstp are never written anywhere, so what's the point?

the pointer is srcp and dstp. *dstp is the value of the byte the pointer points at! If you want to copy all pixels to an array use:


count=0;
for (h=0; h < src_height;h++) {
for (w = 0; w < src_width; w++) {
myarray[count] = *(srcp + w);
count++;
}
srcp = srcp + src_pitch;
}

regards,
hanfrunz

[neuron2]

That fragment just copies the Y plane from the source frame to the destination frame. You need only the srcp to get the source values to stick wherever you want them. You need to get the chroma planes too if you are interested in them.

[lexor]

omg... so what you are telling me is that they treat dstp and srcp as pointers to the beginning of an array, but they didn't declare those arrays, thus didn't allocate memory for them, so any other app can write to location (srcp+w) and screw up that filter? No wonder I couldn't figureout what it's doing.

[mg262]

The arrays are dynamically allocated inside the AVISynth framework (and automatically deallocated at an appropriate time). You certainly can't write to (srcp+w) as it is a const pointer.

[lexor]

The arrays are dynamically allocated inside the AVISynth framework (and automatically deallocated at an appropriate time). You certainly can't write to (srcp+w) as it is a const pointer.
oops sorry missed the get method :)

[mg262]

Clarification to that -- you can't write using srcp, and the framework makes sure that this is never aliased as a non-const pointer.

As you say, this pointer arithmetic is very ugly... I think the reason for it is that you can't tell whether the compiler is going to optimise nicer alternatives properly.

[hanfrunz]

The arrays are dynamically allocated inside the AVISynth framework (and automatically deallocated at an appropriate time). You certainly can't write to (srcp+w) as it is a const pointer.

:D You can write to the src, just use


env->MakeWritable(&src);


in your getframe-sourcecode. I used this in my framenumber-filter to get more speed.

hanfrunz

[mg262]

That's true... although I tend to avoid that since finding that it can sometimes slow things down. (Although Manao recently told me that the issue is well understood and should be infrequent.) It's definitely a good idea for overlaid information like frame numbers though.

[tsp]

maybe this version is easier to read:

for (h=0; h < src_height;h++) {
for (w = 0; w < src_width; w++)
dstp[w] = srcp[w];
srcp = srcp + src_pitch;
dstp = dstp + dst_pitch;
}

it's the same as the above code.