I'm working with a Raspberry Pi 3 that has a ribbon PiCamera. My problem is that I cannot get the still (not video) frame rate to be workable. In my application, the camera acts like a scanner using only a single row of each frame to watch things go by. While the concept is fine, what's killing me is the frame rate which I cannot get above 30 FPS.
A perfect solution would be for someone out there taking the raspicam source, stripped it down and tuning it for speed, and bolting it up to OpenCV. Has anyone done this? Did it work?
The Ava Group in Spain (https://www.uco.es/investiga/grupos/ava/node/40) took an initial stab at this, but their still frame rate is also limited to 30 FPS.
Related
When recording video, we know that it has for instance 60 fps. But do we also know, what the video offset is? We do know that the time difference between frames is 1/60 s. But when did it start as an absolute value? The problem comes into play when trying to sync two videos of the same scenery, for instance stereo with different cameras that were not frame-locked. My idea is to interpolate two - audio synced - 60 fps videos to for instance 180 fps to then change them to 60 fps again to hopefully have matching frames. This does not work, according to my test. A better solution would be to know the time difference between frames to interpolate based on difference, for instance using a deep learning algorithm.
How can ffmpeg help me here?
I'm trying to check 360 Video performance with version 11.62465, the 360 video output can't reach to 60P when we play FHD#60P 360 video. The video decode will update video frame in every 14ms~17 ms, but the application can't call SbPlayerGetCurrentFrame() 16ms, then the drop frame happens. The drop frame rate is nearly 20%. I tried to use chrome://tracing/ check the performance and found that sometimes the rasterizer lasted 40ms, the CPU duration is only 8ms, does this mean the GPU ability is not enough? Will the cobalt render thread be blocked by other modules?
If the CPU duration per-frame is 8ms, then it does sound like the GPU is not powerful enough to process each video frame fast enough. The Cobalt render thread should never be blocked by other modules, though it may be worth double checking that your implementation of SbPlayerGetCurrentFrame() is not taking a long time to render (perhaps it acquires a lock?).
You can use chrome://tracing/ to check the performance of the renderer when a non-360 FHD#60P video is playing, and compare that performance to when a 360 video is playing. This will tell you whether the renderer's performance is affected by the decode-to-texture process or not.
WP 7/8 + xna games by default set to 30 FPS, I would like to know If i set it to 60 FPS , any disadvntages / Performence issues / bugs / any other. becuase i always wants to play/develop the game in 60 fps.
I just want to add a few points to Strife's otherwise excellent answer.
Physics simulations are generally more stable at higher FPS. Even if your game runs at 30 FPS, you can run your physics simulation at 60 FPS by doing two 1/60th of a second updates each frame. This gives you a better simulation, but at a high CPU cost. (Although, for physics, a fixed frame-rate is more important than a high frame rate.)
If you poll input 30 times per second, instead of 60, you will miss extremely fast changes in input state, losing some input fidelity.
Similarly, your frame rate affects the input-output latency. At a lower frame-rate it will take longer for input change to be reflected on-screen, making your game feel less responsive. This can also be an issue for audio feedback - particularly in musical applications.
Those last two points are only really important if you have a very twitchy game (Super Hexagon is a fantastic example). Although I must admit I don't know how fast the touch input on WP7/8 is actually refreshed - it's difficult information to find.
Windows Phone 7 SDK sets XNA to 30 FPS because the screen on Windows Phone 7 Devices has a 30hz refresh rate. This means the screen refreshes at 30 times a second. If you are drawing 30 times a second and you refresh 30 times a second your at the optimal rate of smoothness for that device.
The reason most people aim for 60 (or on my gaming PC, 120) is because most monitors have a 60hz refresh rate (some are now 120hz). If your FPS is HIGHER than your refresh rate you won't notice see anything else except for possible an effect known as "Screen-Tearing" which is what happens when you render more frames in a second than your screen refreshes.
In other words imagine you draw to the screen two times and then your screen refreshes once, why did you bother drawing the second time? You waste battery life, cpu usage, and gpu usage when you render faster than the refresh rate of a device. So my advice to you if your sticking with XNA is that you stick with 30 FPS because the older devices won't get any benefit by having more frames rendered and if anything you'll get graphical anomalies like screen tearing.
If you plan to target higher-end (and newer) windows phone 8 devices, drop XNA, go the Direct3D route and use Microsoft's "DirectX Toolkit" because it includes XNA's "graphics functions" like spritebatch but in C++ instead of C#.
I hope this helps.
I'm developing a card game in Android using SurfaceView and canvas to draw the UI.
I've tried to optimize everything as much as possible but I still have two questions:
During the game I'll need to draw 40 bitmaps (the 40 cards in the italian deck), is it better to create all the bitmaps on the onCreate method of my customized SurfaceView (storing them in an array), or create them as needed (every time the user get a new card for example)?
I'm able to get over 90 fps on an old Samsung I5500 (528 MHz, with a QVGA screen), 60 fps on an Optimus Life (800 MHz and HVGA screen) and 60 fps with a Nexus One/Motorola Razr (1 GHz and dual core 1GHz with WVGA and qHD screens) but when I run the game on an Android tablet (Motorola Xoom dual core 1 GHz and 1 GB of Ram) I get only 30/40 fps... how is that possible that a 528 MHz cpu with 256 MB of RAM can handle 90+ fps and a dual core processor can't handle 60 fps? I'm not seeing any kind of GC calling at runtime....
EDIT: Just to clarify I've tried both ARGB_888 and RGB_565 without any changes in the performance...
Any suggestions?
Thanks
Some points for you to consider:
It is recommended not to create new objects while your game is running, otherwise, you may get unexpected garbage collections.
Your FPS numbers doesn't sound good, you may have measurement errors, However my guess is that you are resizing the images to fit the screen size and that affects the memory usage of your game and may cause slow rendering times on tablets.
You can use profiling tools to confirm: TraceView
OpenGL would be much faster
last tip: don't draw overlapping cards if you can, draw only the visible ones.
Good Luck
Ok so it's better to create the bitmap in the onCreate method, that is what I'm doing right now...
They are ok, I believe that the 60 fps on some devices are just some restrictions made by producers since you won't find any advantage in getting more than 60 fps (I'm making this assumption since it doesn't change rendering 1 card, 10 cards or no card... the OnDraw method is called 60 times per second, but if I add for example 50/100 cards it drops accordingly) I don't resize any card cause I use the proper folder (mdpi, hdpi, ecc) for each device, and I get the exact size of the image, without resizing it...
I've tried to look at it but from what I understand all the time of the app execution is used to draw the bitmap, not to resize or update its position here it is:
I know, but it would add complexity to the developing and I believe that using a canvas for 7 cards on the screen should be just fine….
I don't draw every card of the deck.. I just swap bitmap as needed :)
UPDATE: I've tried to run the game on a Xoom 2, Galaxy Tab 7 plus and Asus Transformer Prime and it runs just fine with 60 fps…. could it be just a problem of Tegra 2 devices?
I'm new to Video technology, so any feedback (such as if I've underspecified the problem) would be greatly appreciated.
I need to display an animation (currently composed of about a thousand PNGs) on Windows and am trying to determine the best video codec or parameters for the job.
Video playback must be smooth at 30 fps
Output display is 1920x1080 on a secondary monitor
Quality does not matter (within limits)
Will be displaying alpha blended animation on top, so no DXVA
Must run on older hardware (Core Duo 4400 + nVidia 9800)
Currently using DirectShow to display the video.
Question:
Is it easier on the CPU to shrink the source to 1/2 size (or even 1/4) and have the CPU stretch it at run time?
Is there a video codec that is easier on the CPU than others?
Are there parameters for video codecs that mean less decompression is required? (The video will be stored on the HD, so size doesn't matter except as it impacts program performance).
So far:
- H.264 from ffmpeg defaults produces terrible tearing and some stuttering.
- Uncompressed video from VirtualDub produces massive stuttering.
There are so many different degrees of freedom to this problem, I'm flailing. Any suggestions by readers would be much appreciated. Thank you.
MJPEG should work. I used it for 1080i60 some 3 years back, and the playback was never an issue. Even encoding worked on-the-fly with a machine of quite similar performance to what you describe.
File size will be about 10MB/s for good quality video.
Shrinking the video will help, because if you are drawing the video to screen using e.g. DirectX, you can use the GPU to stretch it.