I have seen many smartphones coming with hardware accelerated video decoding supporting mpeg2 and h264, but unlike in desktop and laptop systems, it is not clear to me how to interact with the hardware acceleration.
For desktops/laptops there is DXVA, VDPAU and OpenMax.
Is any of those supported in Mobile phones? I think OpenMax is, but I am not sure of how widely supported it is.
Is anyone familiar with what is usually used to write hardware accelerated media players and decoders for platforms like Snapdragon, Tegra 2 or Omap 4 running Android or Windows Phone?
I know that ffmpeg can be compiled for arm and I wonder what kind of hardware video acceleration it supports on that platform.
For ARMs, these are going to be vendor specific based on the silicon. I've seen some offer speedups by integrating subsets of the video decoding algorithms in hardware and you need to set up special registers to point to the data, flip a bit to go and wait for the output.
I think the majority of these though are going to be APIs to whatever embedded GPU is being used (Nvidia's Tegra, PowerVR SGX). I don't know a whole lot more about these, because they usually require NDAs and all you get is a header file and a ELF binary.
OpenGL ES seems to be supported pretty much everywhere.
Related
I'm trying to record timing video from a Thorlabs DCC cmos 1280x1024 with a code in Matlab but Matlab don't recognize it as a video device in imaqhwinfo,
a=imaqhwinfo('winvideo',1) command.
How can I fix it?
It's not supported hardware, see the Supported Hardware page.
Your options are to either request for your hardware to be added to the supported hardware list (if you're prepared to wait a few years...) or use the adaptor kit to write a communication layer between the Image Acquisition Toolbox acquisition engine and the third-party SDK and drivers for your hardware. However, this is a very advanced manoeuvre for experienced users and requires extensive knowledge of the hardware vendor's SDK (and is not something I can help you with).
I'm thinking of making a game in 8086 ASM using VGA for graphics, but before I proceed with anything I want to make sure that I can get audio into my project. I doubt PC Speaker will be sufficient.
I'm looking for a way to program music in 8086 for Windows. Is there some kind of standard in modern sound cards that I can access directly, or will I have to use the Windows API? I'm not really sure what to look for at this point, so any suggestions are welcome.
Unlike the displays, which ultimately converged to (S)VGA, soundcards never reached the same compatibility. There were different Sound Blasters, Gravis Ultrasound and others. These days the modern hardware is often incompatible with those and you cannot program them in DOS as the Sound Blaster without having a proper DOS driver or without knowing the supported memory regions, ports, formats and protocols.
I can only suggest writing such a program for a PC/DOS emulator like DosBox, which emulates Sound Blaster and (S)VGA. That should work.
Alternatively, you can just write a normal Windows program, using Win32 APIs for input, drawing and sound.
What is the Direct3D? It is an API, is not it? Is it implemented by Windows or by graphics cards?
If the graphics cards implement the Direct3D API, why can not other operating systems use Direct3D resources from the graphics card?
If Direct3D is implemented by Windows, it has to use graphics card resources, such as OpenGL or OpenCL. If Direct3D calls are not directly to the graphics card, it would be slower due to intermediate calls.
Please, help me to understand what the Direct3D is.
What is the Direct3D? It is an API, is
not it? Is it implemented by Windows
or by graphics cards?
Yes, Direct3D is an API. It is implemented (mostly) by Windows itself. However, Windows will offload a considerable part of the actual work to the drivers of the graphics card and ultimately to the gfx card itself, so one can also say that a gfx card "implements" D3D.
If the graphics cards implement the
Direct3D API, why can not other
operating systems use Direct3D
resources from the graphics card?
They can, and they do, but only a relatively small (but often critical part) of D3D functionality is implemented directly by the card's hardware, so a lot more work in software is required to implement D3D.
If Direct3D is implemented by Windows,
it has to use graphics card resources,
such as OpenGL or OpenCL.
No, that's a misunderstanding. OpenGL and OpenCL are also APIs, and only partially implemented by the gfx hardware (just like D3D). The gfx hardware usually has a (proprietary) "native" API, which is what the gfx drivers (both for D3D and OpenGL) use.
If Direct3D calls are not directly to
the graphics card, it would be slower
due to intermediate calls.
There are not necessarily any "intermediate calls" - the D3D driver uses the cards native API, as explained above.
Direct 3D is a graphics API created by Microsoft. Its similar in function to opengl. OpenGL is a competing 3D graphics API created as a open standard. D3D doesn't need OpenGL to function.
Card manufactorers decide which APIs they want to implement; most always include DirectX (which includes Direct3D) and possibly OpenGL.
There is indirection as it doesn't go directly to the card, the cards D3D in turn calls the drivers, but this typicially is insignificant.
Direct3D is an API developed by Microsoft designed to help developers render 3D graphics. OpenGL and Direct3D are two separate APIs, but they must both interface to the video card using the drivers developed by the companies who manufacture the video cards. Both APIs (Direct3D and OpenGL) must both go through the driver in order to access the video card, and their speeds are dependent upon their design and their implementation in the video card drivers.
OpenCL is something different -- it's designed to help developers write programs which perform general-purpose computing on the GPU (not just for graphics). OpenCL is comparable to CUDA, but the latter in only supported on NVIDIA cards. Using CUDA instead of OpenCL may have some advantages, depending on your target system, since NVIDIA can make new features available to the CUDA API before they are accepted into the OpenCL API. However, even OpenCL and CUDA must interface to the driver in order to get anything done on the GPU.
As you already know, Direct3D only works on Microsoft and on Wine (for the most part), but its structure as an API is vastly different from that of OpenGL. Direct3D makes use of structures and includes more OOP elements in its API, while OpenGL acts as a state machine, lacking any structures or OOP features. Direct3D can often progress a little faster than OpenGL in terms of the features which it claims to officially support in its API because it is not designed for maximum compatibility with a wide range of devices; on the other hand, OpenGL has typically exhibited more inertia when it has come to adopting new features because of the inherent difficulty in adding new features to its API (the Khronos Group is influenced heavily by the CAD industry as well as many others, so it must cater to a wide range of needs). The time it took for the Khronos Group to finally adopt asynchronous API calls in the OpenGL is testament to this fact, and caused many people to lose faith in OpenGL.
However, OpenGL is cross-platform, endorsed by Apple, and it works on all operating systems on which it is implemented. You can easily use it with many popular window toolkits (Qt, SDL, FreeGLUT, JogAmp, gtk, etc.) and have confidence that your application will compile on other operating systems if you wrote it properly. The OpenGL API, unlike Direct3D, is an open-source industry standard.
As far as performance goes, it's still debatable as to which one is faster: depending on how you structure your program or batch your calls, this could change. However, performance should not really be a consideration for which API you use unless you have tested your application and have evidence that the choice of API is the cause of your bottleneck.
From Wikipedia:
Direct3D is a Microsoft DirectX API
subsystem component. The aim of
Direct3D is to abstract the
communication between a graphics
application and the graphics hardware
drivers. It is presented like a thin
abstract layer at a level comparable
to GDI (see attached diagram).
Direct3D contains numerous features
that GDI lacks.
Direct3D is an Immediate mode graphics
API. It provides a low-level interface
to every video card 3D function
(transformations, clipping, lighting,
materials, textures, depth buffering
and so on). It also had a higher level
Retained mode component, that has now
been officially discontinued.
What would be the best approach to take in order to achieve a backwards compatible (Windows XP through Windows 7) way to capture sound that is being sent to the speakers on a machine, even if the audio driver doesn't expose the "Stereo Mix" recording device.
For extra points, it would be great if this approach allowed for capturing sound from a single application only (excluding sounds from other apps and Windows itself).
Is writing a loopback audio driver the only solution?
AFAIK there is no realiable way of doing this. Even if a card does have something like a stereo mix its a nightmare under XP and below due to a lack of coherent interfaces. CoreAudio under Vista and 7 massively improves matters but if you don't have stereo mix then you won't get far ...
Has anyone out there created a version of GDI32.dll that takes advantage of hardware acceleration available on the machine? gdiplus.dll?
Starting with Windows Vista, GDI is no longer hardware accelerated. (GDI+ was never hardware accelerated). Without Microsoft fixing GDI (and GDI+) to be able to run well on the computer: native applications (C++ MFC, Delphi, etc), and managed WinForms applications, will continue to run poorly forever.
While i could use Direct2D for business applications, i cannot control the fact that the development environment still creates controls, with decades of library support code, that assumes the presence of GDI.
Application Compatibility: Graphical Device Interface (GDI):
GDI primitives such as LineTo and
Rectangle are now rendered in software
rather than video hardware, which
greatly simplify the display drivers.
Windows And Video Memory
In XP GDI is GPU accelerated to
various degrees depending on how the
OS is configured or the device driver
(for details see Hooking Versus
Punting).
In Vista, GDI is not GPU accelerated
Comparing Direct2D and GDI
As a result, in Windows Vista, the GDI
DDI display driver was changed to be
only implemented by a Microsoft
supplied driver, the Canonical Display
Driver (CDD). GDI rendered to a system
memory bitmap. Dirty regions were used
to update the video memory texture
which the window manager uses to
composite the desktop.
It seems that Vista was a special case in the history of GDI performance.
Both articles below show that the future for GDI looks bright again.
http://msdn.microsoft.com/en-us/library/ff729480%28VS.85%29.aspx
GDI is hardware accelerated on Windows
XP, and accelerated on Windows 7 when
the Desktop Window Manager is running
and a WDDM 1.1 driver is in use.
Direct2D is hardware accelerated on
almost any WDDM driver and regardless
of whether DWM is in use. On Vista,
GDI will always render on the CPU.
http://blogs.msdn.com/b/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx
Based on real-world application
statistics, ... we worked with our
graphics IHV partners to provide
support in their drivers to accelerate
the most commonly used GDI operations.
Well, yes, GDI is the "it works anywhere anytime" API for rendering graphics. It puts very low demands on the video driver. Everybody got that right a long time ago. Which took a while, I got a distinct memory of a ATI Mach video card that gave me no end of trouble. It stopped me from buying ATI products for quite a while.
Everybody got DirectX right a lesser long time ago too. It is being taking advantage of in the WPF rendering model, it completely relies on DirectX to get the job done. Milcore is the shim name. You won't get it until you buy into the WPF programming model.
What do you mean by hardware acceleration?
I mean, GDI doesn't do a lot other than raster blits, but those were hardware accelerated. And, given that Vista and Windows 7 arn't terribly slower with desktop apps, still are.
GDI still gets the video drivers to do all the heavy lifting, so if GDI isn't hardware accelerated, then its the driver vendors fault, not GDI's.