I would like to develop a media player/recorder.
The primary target platform is Windows, support for other OSs would be nice, but that's not a high priority. It should be able to play formats like wav, mp3, avi. It should also be able to record audio (microphone) and video (webcam or capture card).
As I have some experience with QT and C++, I looked at QT (4.7.2) phonon with DS backend. But unfortunately I was unable to play a simple AVI, even with the MediaPlayer sample that comes with the QT demos. I could only hear sound, but saw no video.
The developer machine is a 64-bit Vista. I also tried it on another 64-bit Vista without any luck. On a 32-bit Win7 (QT MinGW) it then finally worked. But when I copied that MediaPlayer executable and its dlls to the 64bit machines and tried to run it, it again failed.
Is there a known problem with QT phonon on 64 bit machines? I also heard of a VLC phonon backend. Could that be solution? Is QT phonon mature enough to develop a commercial application on top of it? Or is it maybe more wise to access directshow directly?
Thanks
Directshow is just a programming framework or API, it does not guarantee that you will be able to play every possible video format on every computer, since it relies on codecs installed on the system to decompress the audio/video streams. A codec for one specific format might be available in one system an not in anotherone. On top of that, 64 bits architecture adds even more complexity, since codecs built in 64 bits mode cannot be used from 32 bits applications and vice-versa. The issue you are facing on the 32 bits Phonon player is very likelly to be caused by a missing or "not 32 bits compatible" codec.
VLC on the other hand is a self contained application, it does not depend on DirectShow or in any codec installed on the system, so it might be a good idea to use it instead of DirectShow, however you will need to read VLC legal terms and decide if you can still use it for your purposes.
Related
I have been working with QML for a couple of weeks now. But now a new requirement has risen where I have to check whether I can run QT5 in an embedded device for my project. I need this for my GUI related operations. The device has an ARM processor (Intel ARM920T-PXA27x processor to be exact) with 64 MB RAM. 32 MB will be taken up for the OS and the rest will be available for application and QT.
I have to check whether this is possible. I have googled for some references and unable to find a suitable answer to my requirement with QT5. I need the GUI libraries but my project does not have advanced graphical requirements like swiping or animations. It contains basic controls like texts, buttons and lists/grids. Since I am new to QT especially to this part, I would like to hear whether
1) Is this a viable option and should I keep digging more into this? Any feedback would be welcome to know if it's worthy to spend time to attempt this or if it's a lost cause.
2) If there are options, could you point me in the right direction to look more into this?
It depends on the OS you are running on your SOC.
It's definitely possible when running Linux. You can e.g. use Qt Lite for configuring a minimal static build of Qt. Then you deploy your statically linked application to the device. You can check this blog post for experiences with Qt Lite.
One possibility is to go with Qt for Device Creation for the whole embedded Linux based software stack which boots to a UI implemented with Qt technologies.
We are converting directx9 to directx10 and we are getting an error: Cannot open include file :dplay8.h .
Please provide the solution how to resolve this and also the steps that might required to convert from directx9 to direct10.
DirectPlay is a deprecated legacy component. The last version of the legacy DirectX SDK to include the headers for it was August 2007. See DirectX SDKs of a certain age. It is not available in any Windows SDK.
It exists in the Windows operating system today for appcompat only. There are a number of important limitations to keep in mind:
DirectPlay Voice is not supported on Windows Vista or later operating systems. See KB970978
The NAT helper object is unsupported on Windows Vista or later
On Windows 8.x and Windows 10, DirectPlay is an optional Windows feature so it's not present by default. It has to be enabled by the user.
In short, you shouldn't use it. You should plan to rewrite the multiplayer support for that porting project, or strip it out.
DirectPlay's primary value was back when networking was a complex and evolving world: modem play, head-to-head serial ports, IPX/SPX, TCP/IP over modem, and TCP/IP. At this point TCP/IP is the only network solution that matters so using WinSock directly is far preferable. There's are also a number of security implications around use of UDP (datagram) vs. TCP (virtual circuit) that modern games need to take into account. The lobby mechanism of DirectPlay is also woefully outdated.
There are numerous modern game services (such as Xbox LIVE, Valve's Steam, etc.) that are designed to provide the match-making, NAT-traversal, and other features that are essential to modern multiplayer. You use WinSock in combination with service-specific libraries.
In a related note, there is absolutely no reason to use DirectX 10. DirectX 11 supports much more hardware, is supported on all the same operating systems (Windows Vista SP2+), and has numerous replacements for legacy support libraries that don't exist for Direct3D 10.
I am posting this to know whether a media player can be developed with Qt5 without using gstreamer plugins as backend.Is there any other backend engine available in embedded linux platform to play media files other than gstreamer. I am using intel X86 32 bit architecture.
Thanks in advance.
Just checked the Qt5 plugin sources (/qt5/qtmultimedia/src/plugins) and it seems like gstreamer is the only option for linux. Phonon has been dropped in Qt5.
If you want to use phonon you'll have to stick with Qt 4.8.
Qt5 on Linux only supports gstreamer by using the plugins in http://qt.gitorious.org/qt/qtmultimedia/trees/stable/src/plugins. Of course you can write your own plugin using ffmpeg or whatever you want. This is pretty simple, but entirely depends in the performance you need.
Phonon was available in Qt 4, but AFAIK Phonon is gstreamer based again. There is also a project to create a vlc-based Phonon, but I don't really know how it works (https://projects.kde.org/projects/kdesupport/phonon).
However, you don't specify your specific target, but if you want to achieve acceptable performance for graphics and/or video on embedded devices, you probably really need hardware acceleration. And Phonon will hardly help you with this. Also consider that Qt 4 is old: it misses years of development.
I'm also writing a Qt5 backend using OpenMAX and ffmpeg: http://thebugfreeblog.blogspot.it/2013/04/hardware-accelerated-qtmultimedia.html. It might be an example if you need to write your own.
Also consider that the errors you reported (why reporting in an answert?) seem to suggest you built gstreamer wrong.
I have to port the application which is using the Qt3 library to a new embedded OS.
If the OS is not yet selected but it is known that it is not Linux/Windows, what is the general way of porting procedure? I mean what files should be changed and what are independed and can be left as is?
If it's not Linux or Windows you could be pretty stuck out the door. Qt is highly dependent on libraries being available for it to be able to build. This is not a no however, it has been ported to Symbian which is obviously not Linux or Windows. The big thing on that though is that it was ported by Nokia, who had amount of time and amount of developers, where those X's are reasonably big numbers.
Start by getting the Qt everywhere source code, work out what bits you're going to need and which bits you won't. If the platform has gcc/g++/another reasonably well understood C++ compiler you're in luck and you should be able to build the bits as needed. Qt does depend on standard libraries throughout so make sure they're also available in some form for the platform, and it does use some non-standard ones for some components so you'll need to know which aspects of Qt you're working on. You should be able to get some sort of toolchain from there.
I'd stick to platforms that Qt supports though, if you go off the beaten track you're looking into increasing your dev times and having very little useful support.
I am trying to get a deeper understanding around the codec area and how it all works.
The primary drive is the uncertainty of installing codec packs to deal with certain unplayable videos, which ends up not allowing the playback of those files anyway. This is often later complicated by installing other codec packs on top. I have also noticed that sometimes simply reinstalling a codec pack can cause videos, which were playable before to be unplayable after codec pack reinstall.
What I am curious about the most is what is happening in the background when a codec pack is installed (Shark007, CCCP, K-Lite) - how are codecs registered with different players, windows media player in particular? Is there a list of known codecs in WMP internals which gets new codecs added to? How can I find out whether I have a particular codec for a particular encoding type? How does DirectShow and its filters work together with new codecs?
Most of the information that I have found has been quite top level, with most advice being playing around with codec pack settings and/or installing other codec packs.. :(
Any sort of advice or recommendations for further info on this area (books, links, etc) would be GREATLY appreciated! :)
In Windows the most widely used multimedia API is DirectShow, and as you indicated in question tag you perhaps target exactly it. There are other APIs too. Important note is that DirectShow is NOT the primary API for Windows Media Player: WMP would attempt to play a file through Media Foundation, and if failed, the second attempt would be to leverage legacy DirectShow. Still, DirectShow is the most commonly used in applications.
In DirectShow, the multimedia pipeline is built from filters which are connected into a graph through their pins. The connected structure has the data streamed through, e.g. from file to decoded video/audio delivered to the devices. The codecs are components that frequently used within this pipeline.
The registration of codecs is the scope of authority of Filter Mapper subsystem. It takes care of all registrations and provides connectivity options for Intelligent Connect - the subsystem which connects stuff together, including supplies codecs when they are needed and the application requests the codec to be provided automatically.
The best documentation of the internals you will find on MSDN, under DirectShow.