That sort of speed seems unlikely, depending on requrerements, but you can work it out. How many pixels do you want to read per frame?
If you running some sort of video output via the GPU (e.g. using the HW aceleration) then the framebuffer never sees that information - its is composited over the top of the frame buffer in HW straight to HDMI. So reading a pixel will not get the video but the underlying framebuffer.perfo wrote: ↑Thu Mar 14, 2019 12:48 pmHello Jamesh
I only want to read one pixel per frame no matter what the resolution is. I was hoping with only reading one it may enable it to be speedy enough,
I'm not interested in the camera for this application so that's not a problem but what do you mean by the video display is not presented to the frame buffer. It's the HDMI output I want to sniff pixels from is this the video display ? or do you mean the composite video output on the other port ?
As mentioned above, the OP is playing a video using OMXplayer, and that data never enters the framebuffer, so FB operations will not work.bzt wrote: ↑Tue Mar 26, 2019 2:24 pmHi,
To access the framebuffer read this. It's taking about plotting a pixel, all you need to do is to reverse that and read instead.
There are many example C codes out there, for example this one has an fb_getpixel32() routine.
But framebuffer is not the only way. If your video player is using X11, then you can get the info from it's window. That should be simpler, more portable and faster (because it's using RAM only, no MMIO). See X protocol and the Xlib manual. If your video player is fullscreen, then you'll probably need to use the XRootWindow(), otherwise I suggest a tool like xprop or xdotool to find the window id and use that. Example code here, grabc has interactive mode but you can also specify window id and x,y offset.
Those are all C sources, but there's a library to access Xlib from python (not sure how up-to-date though).
No. Moving the data from the Videocore to the ARM then into the frame buffer is a lot of operations, so will always be slower. It might be quick enough, but will definitely be slower.perfo wrote: ↑Wed Mar 27, 2019 9:32 amThanks for the detailed answer you put some effort I to it and that is appreciated.
I did manage to get pixel stuff from the FB but as JamesH points out that was before I found out OmxPlayer didn't use the frame buffer and thus I couldn't make head nor tail out of the info I was managing to get. I believe I can play OMXplayer in an X11 window with the -b switch. So I may give that a go and see if it works any better...
I guess another question would be, would there be a fast video player that does use the FB ?
Mplayer can do that. Both mencoder and mplayer use the same codecs and filters, all can be used as input and for output as well, the only difference is that mencoder saves the result in a file (or streams to network) while mplayer displays it on screen.
Code: Select all