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.
Related
While playing 4K video user can resize players window - and result image will be scaled smoothly in run time.
On the other hand - program written with libav which reads 4k video file frame by frame and scale it down with sws_scale function do it less effective: it took more time then video duration to resize it.
Why is it so? Maybe because player fps is less and some frames are skipped - but video still looks smooth?
This is because most video players do scaling in the video card's hardware. With GL, for example, scaling (or even format conversion from YUV to RGB) is free.
I would like to copy pixels from a 1080p video from one location to another efficiently/with as little CPU impact as possible.
So far my implementation is fairly simple:
using BitmapData's draw() method to grab the pixels from the video
using BitmapData's copyPixels() to shuffle pixels about
Ideally this would have as little CPU impact as possible but I am running out of options and could really use some tips from experienced actionscript 3 developers.
I've profiled my code with Scout and noticed the CPU usage is mostly around 70% but goes above 100% quite a bit. I've looked into StageVideo but one of the main limitations is this:
The video data cannot be copied into a BitmapData object
(BitmapData.draw).
Is there a more direct way to access video pixels, rather than rasterizing a DisplayObject ?
Can I access each video frame as a ByteArray directly and plug it into a BitmapData object ?
(I found appendBytes but it seems to do the reverse of what I need in my setup).
What is the most CPU friendly way to manipulate pixels from an h264 1080p video in actionscript 3 ?
Also, is there a faster way to moving pixels around other than copyPixels() using Flash Player ?Also, I see Scout points out that video is not hardware accelerated( .rend.video.hwrender: false ). Shouldn't h264 video be hardware accelerated (even without stage video) according to this article (or is this for the fullscreen mode only) ?
Latest AIR beta introduced video as texture support which you could possibly use to manipulate the video on GPU (and do that way faster than with BitmapData). But keep in mind that it is currently available for AIR on Windows only and there are some other limitations.
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 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.
I'm trying to write an application to display multiple video streams, all updating at 25 or 30 images per second. The images are being rendered into WPF controls using Direct3D and some Interop to avoid using a Winforms control. As more video streams are added, the frame rate of each control drops yet the CPU on my machine only ever reaches about 50%.
Using the Microsoft WPF Performance Suite - Perforator tool, it would appear that when the frame rate on the video streams starts to drop, the 'Dirty Rect Addition Rate' levels out like it has reached a maximum for the video card.
There is no software rendering activity in the application so it would appear that overall performance is being limited by the graphics card's ability to update the Dirty Rectangles.
Therefore, is there a feature or performance parameter that can be used to determine the best video card to buy in order to maximise performance for my application?
Either that, or is there a set of graphics cards settings that will boost performance?
Currently running with an ATI FirePro V4800 that will happily run 16 streams of H264 video at a resolution of 4CIF but looking for the ability to run up to 32.