For one moment I wondered what Microsoft's word processor had to do with this , and then realized that MS meant most significant in this case .gsh wrote:with the MS word the minimum absolute
Sorry if it's a stupid question, but what kind of vector are we talking about here? The geometric kind that has a heading and velocity? If so, what are the units?gsh wrote:vector of (-2, 8)
The units are pixel. It is the displacement of this macro block, to the most similar part in the last image. Say it says x=16 y=8, you cut crop these macroblock and shift it 16 pixel to the right and 8 pixel down. and compare this with the old image, then there would be the minimum difference. These units are now in the range from -128 to 127 pixel in x and y direction. If you move your image to far the algorithm would not find it. This helps the encoder, which basically only stores differences, to store the minimum amount of differences if he takes these shift values into account.kaos wrote:Sorry if it's a stupid question, but what kind of vector are we talking about here? The geometric kind that has a heading and velocity? If so, what are the units?
Yes, if we want simply to output the raw buffer to file it is really easy. When I want to do some processing with these I have some problems.gsh wrote:@ethanol100
If you've got it working then please submit a pull request. I'm fairly sure it should be a very simple PR!
Nice idea, but I guess it will be to slow, will try to play with that.Be very interested if anyone has been able to get something useful out of it, basically if you compile a histogram of the vector values then you should be able to implement a very simple motion type thing in Raspivid and trigger the video recording / playback very simply...
That was exactly what I was trying to archive the last hour after I noticed that I need to edit the the circular buffer to keep the h264 stream clean, if someone tries to use circular buffer and the inline motion vectors together. Now I just take one velocity vector to check for change. So very simple and basic. I can now use "raspivid -trigger 960,540,80,0.2 -o test.h264" to monitor the macro block containing the coordinate x=960 and y=540 and trigger the recording, if the velocity magnitude exceeded 80. The last 0.2 is the part of the timeout before trigger, i.e., setting it to 0.2 will record 0.2*timeout before and 0.8*timeout seconds after the trigger event. Here it is getting dark and I can't test it today. Now I have changed to much for a pull request, because I need some "internal" trigger and need to change some other parts and need to include math.h for "sqrt". And I'm not sure if the velocities are stored "[unsigned char vx][unsigned char vy][short sam]" or the other way around.
It'd be very interesting for someone to hook it up to the circular buffer code I wrote previously because then you can record the period before and after the trigger period. I'd like to use this as a cycling camera... I'd set up a number of Pi's (with batteries) running the camera app then when someone cycles past it records each person. Then you could automatically stitch the video together to create video recordings of a mountainbike race for example! (It's something that I do!)
Oh, I thought he meant a hassle for you, that you lost the code and would have to rewrite it.gsh wrote:@peepo
Sorry, if you think this is hassle, but it's not going to get any easier to actually process the data!
Hi Gordon,gsh wrote: Note you get one integer per macroblock (16x16 block) with the MS word the minimum absolute sum of differences found and the LS word the 8 bit vector in pixels (signed)
The H264 hardware has both a Coarse Motion Estimation (CME) and a Fine Motion Estimation (FME) block - there are power savings if the search range is reduced on the fine search.Rayden wrote:Hi Gordon,
Just quick question, vector is in whole pixels not quarter pixels? Does the pi encoder produce quarter-pixel vectors internally?
Code: Select all
raspivid -x test.imv -o test.h264
Code: Select all
split -a 4 -d -b $(((120+1)*68*4)) test.imv frame-
Code: Select all
signed char vx=0; signed char vy=0; short sam=0; memcpy(&vx, buffer->data+4*(i+(pData->pstate->mbx+1)*j), sizeof(signed char)); memcpy(&vy, buffer->data+4*(i+(pData->pstate->mbx+1)*j)+1, sizeof(signed char)); memcpy(&sam, buffer->data+4*(i+(pData->pstate->mbx+1)*j)+2, sizeof(short));
Full FOV firmware changes went in on Mar 14, 2014, so those are present in f0eeb5b9431a87906ee77bc70a5baa9203c361e2 April 07 that peepo says works.ethanol100 wrote:I would guess, that the code breaks when the new full FOV modes where introduced. You are requesting a resolution of 640x640 which will chose one of the new modes. Somewhere there has been reported a similar problem with the "RPi Cam Web Interface" http://www.raspberrypi.org/forums/viewt ... 23#p542523. So I guess you need to update your code somehow.