I have no idea what I'm supposed to do now, but I cant give up in the middle

Two days Search on H264 gave me only more confusion. I tried to find a library that would work something like encode(buffer) decode(buffer) but I guess if it was that easy I wouldn't have to look for it...

I finaly found a reference to this tutorial:
http://dranger.com/ffmpeg/tutorial01.html
on ffmpeg and I'll try to read it and follow closely to see if this can grab an array of COLORREF dwords (assuming here that the buffer is a big array, if not, I found a snippet by someone, who says his way is faster than the GetPixel macro, here:
http://stackoverflow.com/questions/10515646/get-pixel-color-fastest-way
and build an array myself to pass as data to be encoded).

PS.: Each time I look at something, your words come to my mind: "Know your data types" I know I should read a DX tutorial or two before going any further...

And, by the way, just for reference, I did find something that streams the buffer, but I have no idea how it works (couldn't dissect it...) and its in C#, here:
https://github.com/fishjord/D3DFrameStreamer/tree/master/AVIStreamCLI
It also uses injection, but I guess this can be stripped somehow, if anyone want to stream his own app...

ffmpeg is just the overall project, probably most interesting to you is libavcodec which implements encoders and decoders. Here is an example: https://www.ffmpeg.org/doxygen/0.6/api-example_8c-source.html

And there is more to find on the internet.

In my link run the other day I found people - locking the d3d backbuffer and streaming it by H264 . - Noting the locking to be a bottle neck and also noting that there is no way in dx9 to grab the front buffer.

I can try and grab more of those links with examples if you like. However, I don't want to add more confusion and a different path to your already deep woods.


Manual of note
http://www.conitec.net/beta/adraw_begin.htm
http://www.conitec.net/beta/ad3d_lockable.htm
http://www.conitec.net/beta/prog_using_Direct3D.htm
http://www.conitec.net/beta/bmap_zbuffer.htm
http://www.conitec.net/beta/render_zbuffer.htm

LPDIRECT3DSURFACE9 and IDIRECT3DSURFACE9 seem analog.So I'm not sure if this is
LPDirect3DDevice9->GetBackBuffer() to obtain the back buffer surface
- use LPDirect3DSurface9->GetDC() to obtain the device context.

None dx9
https://msdn.microsoft.com/en-us/library/windows/desktop/dd144947(v=vs.85).aspx
http://www.conitec.net/beta/hWnd.htm

EDIT2 - and just thinking -is possible? create bmap_zbuffer, render screen to it. Then stream that.

Yeah, after my last post I saw that ffmpeg is the encoder that can encode in different codecs (someone was using it to encode in H264)

Malice, thanks for the info, I'll check the links later, because I woke up extremely ill today, and I might be afk for a few days. But for the locking, I saw some people using locking in some codes, but never stayed for too much. I also saw from posts that grabbing the front buffer is a waste of time, literally

Here's what I've currently outlined, as a method (purely Theoretical, haven't written a single line of code yet ):
Get Device Context
Create myDC
CreateBIPSection
Select object BIPSection for myDC
each frame:
- BitBlt content of DC to the BIP section (now I have an array in the order [r][g][b][r][g][b][r][g][b]...
(Note - this is said to be faster than GetPixel)
** I've reached this point in reading, from now on everything is just an outline of thoughts **
- Create a buffer size to hold a matching res YCbCr array and use a conversion function to convert the RGB array into YCbCr (which I somewhere read is kind of slow, but maby there are different implementations)
- Create AVPicture and fill it with YCbCr array (avpicture_fill)
- Copy AVPicture to a fresh AVFrame and pass that frame to the encoder

I hope I'm right so far, but it'll all show up after I begin testing in a few days, when I get better.
I'll first start by creating a video file on my HDD, if succeed, I'll try to send the data and create a file on the raspberry, trying to avoid showing the image yet, just playing the result on my laptop (I'll worry about decoding it on the raspy after I get it sending and receiving correctly )

Thanks for the help so far, guys. I'm glad you're still lingering here...

PS.: Malice, you're suggesting to create a bmap_zbuffer, but isn't bitmap creation slow? I also don't have a clue how render targets work. Used them a lot of years ago, and I have no memory of that process.

Truely I'm just throwing out ideas. But If I understand render z buffer is a direct d3d surface with pointer to the d3d object.

As for using this kind of idea, txesmi did a lot of working it out in a thread in this very topic a week or so ago. So striping the code he posted to what you need 'could' be half your work. LINK HERE

As to speed or if anything I say will work, I'm just spite-firing idea's. I have no clue. I'll try to do some testing, however I'll likely fail as I'm miles behind you in understanding all this.

Mal

EDIT- This didn't crash, however examining the d3d9.h and looking to transfer this http://gamedev.stackexchange.com/questio...without-using-d
Makes my mind explode... I want to help but I am way over my head here. I have no idea what is happening at GetDC() and it might melt your pc. This stuff is to high level for me to just trail and error throw. Sorry
Mal

Lol, wrote a really long boring post

Gotta go to bed, so in short, DC is a structure that contains other stuff, like the bitmap data being displayed in our Acknex window, so GetDC will work on a handle (a Windows handle) of the window and will return a handle to the device context (structure of data about our window). Then, we know the space in memory that holds what is being drawn on our window... With some core functions we can get access to the bits by giving the device context handle to them...from what I understood...

By the way, someone reported bitblt function (image copy in memory) took more than 30ms each time, so 60fps wont cut it. Another guy mentions LockBits being faster and with manual control, but I have to see how I can use it on the buffer (he's giving a Bitmap structure as an example...)

Gotta go, really

The z-buffer is the buffer with the depth in it, you probably actually want to grab the colour buffer! Just an FYI, because I really can't help you with actually grabbing the DirectX pointers and what to do with them.

And then do all your compression stuff. (Its saved as JPG, you might use BMP/PNG if you wanna use another compression)
This is still slower then coding your own device driver like Teamviewer did.

Ch40zzC0d3r , everyone says that getting the FrontBuffer is slow. I'm browsing for other methods.

Searching again on google gave another result, direct quote:

A quick glimpse on GetRenderTargetData - Copies the render-target data from device memory to system memory.

I have to read more on what a "surface" is

Another note, I found some interesting examples on encoding/decoding, but they output to a file stream, so I'll have to learn how to make this data go through a socket. I guess it wont be that much different...
Here's the examples, if anyone is interested in making a video player :
https://ffmpeg.org/doxygen/trunk/encoding-example_8c-source.html

Well where is the problem now?
I just googled 2 seconds to throw in some code, I know that its not the fastest.
Just use GetRenderTargetData and your done.