The main players seem to be x264, and xvid, and both are GPL. This means we can't integrate decoding capabilities into a playback application without licensing the whole thing as GPL, so we can't use either.
The preferred target platform is Linux. Any non-viral open license is fine, we're more than happy to provide the source of any changes we make to libraries, just not our whole application.
Is there anything? Or maybe we should use GPL for now as a test during development, and plan to replace it with commercially licensed codec before shipping?
The ffmpeg H.264 decoder is LGPL. Only the encoders are GPL, and x264 does not provide a decoder.
It also has the advantage over Framewave and IPP of actually being usable.
Cisco released a BSD-licensed h264 library for encoding and decoding.
I wish you would just use GPL, but I'm not going to just tell you to do that when there is an answer out there.
http://www.openh264.org/
and the GitHub page:
https://github.com/cisco/openh264
PocketVideo's OpenCore is now open-sourced under Apache 2.0 license as part of Android OS:
https://github.com/android/platform_external_opencore
IANAL, but if you're shipping anywhere software patents are enforced, not only do you have to pay the MPEG LA royalties for h.264 decoding, but the license might preclude you from using the open-source decoders anyhow. I've heard of similar annoyances applying to other codecs.
A project derived from AMD performance library, Framewave, now has a video component supporting h.264 decoding.
The license is the "Apache 2.0 license"
you can check it out at Sourceforge SVN
IANAL.
If you ship unmodified binaries created from unmodified GPL source and your application simply invokes them, I believe your entire app does not have to be GPL. You may have to include GPL documentation and/or the source of the bundled GPL apps, but if you are not making any modifications or linking against GPL code, your code should be unaffected.
As far as the MPEG standards, that may be another bag of worms entirely...
Ok, FFMpeg appears to handle h.264. I believe most of it is LGPL.
Would still love to hear experiences with it (good or bad), or other options, thanks.
--
Correction, the version I just tested appears to be compiled with "--enable-gpl", which leads me to beleive it's making use of GPL licensed codecs. Argh!
Take a look at the Intel IPP Libraries. They are not free, but are very cheap (a once-off payment of a hundred dollars or something). You can also get a free evaluation to test it out. The licence is very open, and as far as I know allows you unlimited distribution in your application forever once you buy it.
I've done some work with FFmpeg, though it was limited to libavformat (the codec part is called libavcodec). I found the API to be surprisingly straight forward and easy to use. They provide a few really useful and enlightening samples in the standard source distribution.
Generally the library holds rather high quality, but some modules seems to be lacking, so I can't vouch for the h264 part. I've heard good things about the encoder, though.
Note that VLC and most of its libraries are now LPGL
VLC engine relicensed to LGPL -
http://www.videolan.org/press/lgpl-libvlc.html
VLC playback modules relicensed to LGPL -
http://www.videolan.org/press/lgpl-modules.html
Related
Upon considering the driver side implementation for DirectX API on windows systems for modern video cards I was wondering why this implementation is not available on non-windows system, most notably linux.
Since there is an obvious absence of this functionality I can only assume there is a good reason which I am blind to, but in my primitive understanding I simply see the DirectX calls as no more than function entry points on the hardware device. And for the record I am not referring to a compatibility layer (most notably WINE, a project I am amazed by every single day) but a library making direct hardware calls.
Is it possible to create an open source version of directx? Would it be possible but obscenely difficult?
AFAIK, the DirectX contains 3 parts
Vendor driver (provide low level API defined by DX)
DirectX library (use low level API defined by DX to access hardware, provide DirectX API)
Software (use DirectX API, ex. game)
There are no driver providing the low level API defined by DX on linux, so even it is possible to provide the DirectX library, but it won't work without proper vendor driver, and I can't see if there is any vendor is going to create one for their hardware platform.
Why not just use OpenGL? It supports all the functionality that DirectX does. Do you have a specific reason to use DirectX? As for a reason, Microsoft made DirectX and I guess they didn't see any need to allow it to run on Linux.
You can run DirectX games in Linux using Wine. You can program XNA on Linux using MonoGame. But all of these use OpenGL to provide hardware-accelerated rendering. AFAIK, OpenGL has been (and probably will be) the only option on Linux for the foreseeable future.
Is it possible to write your own DirectX implementation? Sure - but it involves writing drivers, proprietary knowledge and probably too much cost for anyone to REALLY benefit from it.
EDIT: These days, DXVK is a very real and performant way to run DirectX applications on Linux.
DirectX is a suit of API's:
Direct3D (drawing 3D graphics)
DirectX Graphics Infrastructure (enumerating adapters and monitors and managing swap chains)
Direct2D (drawing 2D graphics)
DirectWrite (fonts)
DirectCompute (GPU Computing)
DirectSound3D (playback of 3D sounds)
DirectX Media (DirectAnimation for 2D/3D web animation, DirectShow for multimedia playback and streaming media, DirectX Transform for web interactivity, and Direct3D Retained Mode for higher level 3D graphics)
DirectX Diagnostics (tool for diagnosing and generating reports on components related to DirectX, such as audio, video, and input drivers)
DirectX Media Objects (support for streaming objects such as encoders, decoders, and effects)
DirectSetup (installation of DirectX components, and the detection of the current DirectX version)
DirectX components deprecated, but still supported
DirectDraw
DirectInput
DirectPlay
DirectSound
DirectMusic
As you can see many parts of the DirectX suit of API's would need to be rewritten with functionality for Drivers written for Linux. Also some parts of the DirectX suit are likely going to make calls to the Windows OS and that code would have to rewritten for a Linux machine without infringement of the copy-written parts of either DirectX or the Windows OS.
Yes you could write a open source API suit which does the same kind of thing as DirectX for Linux, however without a great knowledge of sound and graphic drivers/support by their manufactures for Linux, it would be a very hard task to do.
However if you question was more of a "Can I get/write something to be able to run games and programs made with DirectX to run on Linux?" in it's meaning, in short no due to more likely copyright infringement.
Your question is wrong in 2019. DXVK is an implementation of D3D11 and D3D10 implementation for Linux using Vulkan and Wine
Also mesa has native Direct3D 9 implementation but in my knowledge, no one uses it except wine
The work to create a port for DirectX would create the same problems as you encounter in WINE. It will never be the same as on Windows. Derived from that principle you would have to look into OpenGL and related multi-platform libraries.
At this very moment WINE would be your closest medium if you want to accomplish something with DirectX code you already have. Then again, I'm not sure in what manner Visual Studio or plain typing would get you closer yo a fluent environment. The WINE libraries aren't that far from native, but there always exists emulation, what is acceptable to a certain point in my honest opinion.
If I look at how superbly Final Fantasy XIV ran on full settings on my iMac (2011) I think it's not that bad to rely on WINE's implementation. The game exactly rendered as on Bootcamp (Windows) on my iMac.
If you really want to make work on this front you could try to ask WINE Devs at their forums or mailing lists how you could maybe use the implementation of their DirectX compatibility only and use that in your project. Where you maybe can call libraries instead of requesting DirectX through Windows-emulated system calls.
Edit: I fully agree with user956030's answer too.
DirectX is a propriety products designed for Microsoft targets, so for this to happen would be very unusual
There are two other pieces of software that come to mind, SDL and OpenGL
OpenGL provides the hardware alternative to DirectX, and SDL works with OpenGL to provide the software support you would expect from DirectX
Since 2020, Microsoft has been working to port DirectX 12 to WSL2, which is being done in this repository. In a mailist, Steve Pronovost commented that they might work to port this driver to Linux to have it running natively.
However, in order to do this, they would need to implement the driver on top of the kernel's DRM stack, which itself needs to be modified if they want to keep the driver similar to the Windows one and have related APIs.
There is some effort being done in the Mesa library as well, to support D3D12 within itself, the main purpose being to optimize server-sided GPU calculations that are heavily used in machine learning algorithms.
Even though this is great, it's unlikely that we will ever see any advantage running Windows games on Linux with that driver. The open source community would only have the upper ground if more games start supporting Vulkan, which is faster and better than DirectX, there had been experiments where using DXVK on Windows would be faster than DirectX 9 or even 11, such as the one mentioned here, but DXVK tends to be less reliable and more prone to errors and crashes.
My team is tasked with building a full screen, kiosk-style application for playing back media files. Initially we need to support WMV / MP4 as well as some images in full 1080p, although down the line we will need to extend this to cover other formats (different videos formats as well as display of HTML, SWF, etc).
The application also contains a decent chunk of business logic relating to scheduling, logging, performance monitoring as well as network code to talk to a central server through web services (or maybe TCP) and potentially act as a server itself.
For our WMV / MP4 video playback, hardware acceleration will be a massive bonus. The targetted hardware has weak CPUs but strong graphics cards.
Here's the kicker: we're a .NET shop (our existing application is a WinForms smart client) and extremely experienced and productive in C# and the .NET stack. The app will initially be targetting Windows Embedded (.NET 3.0), but we will quickly need a Linux version as well. Between us we have some C/C++ experience and some Linux experience but we do not anticipate good productivity on that platform.
So I am soliciting recommendations specfically on the following points:
Video. On Windows we have seen good success using DirectShow.NET. On capable hardware, the WPF MediaElement also seems to perform well. What should we be using on Linux? libavcodec seems like a common choice. Is it hardware accelerated on NVidia graphics cards on Linux? What other options do we have on Linux? Is there something cross-platform that I could consider?
Stack.
a) Ideally we could write the whole thing in .NET and then run under Mono on Linux. The video playback and presumably some other components (like performance monitoring) would not be supported on Mono. I guess we could rewrite these elements in, say, C++; but I'm guessing that most stuff on the business logic side would work.
b) Maybe it's better to forfeit our up-front productivity on the Windows version for something that's cross platform out of the gate. What about Java? Do we have different options when it comes to video there? How about another framework? Something like QT? Can anyone else suggest something cross platform that would be relevant?
Broadly speaking, given the requirements, what would you use?
I appreciate any anwsers you might have.
My suggestion is that you use Fluendo's GStreamer components for the video playback as it has support for hardware acceleration where available and fully licensed codecs.
You can look at the Banshee media player which support video playback if you have the Fluendo/GStreamer packages installed. Get OpenSUSE 11.2 which contains everything you need to try it and develop, and then buy and install the Fluendo codecs.
Source code wise, Banshee does the video display from C#, look here:
The C# source code consuming GStreamer and doing the video rendering is here:
http://git.gnome.org/browse/banshee/tree/src/Extensions/Banshee.NowPlaying/Banshee.NowPlaying
The C supporting library to call into Fluendo is available here:
http://git.gnome.org/browse/banshee/tree/libbanshee
For testing Banshee, you do not need to buy anything, but your video codecs will be limited to Ogg/Theora encoded videos. Once you get Fluendo's codecs you will be able to play WMV files.
One option would be to use Silverlight, and explore Moonlight as an option for the linux version. My understanding is that Moonlight has several media/codec plugins (I believe ffmpeg is the main provider) and can additionally use the MS codec pack to give you support for things like WMV/MP4.
You can use ffmpeg in mono and .net. This may or may not include video display - ffmpeg usually just provides you with a decoded bitmap that you can do whatever you want with, be it display it in a window, save it in a file, whatever. If you use ffmpeg-sharp the same code should work on Windows or Linux. Really, putting the bitmap in a window is the easy part.
Moonlight offers two codecs: (a) A fully licensed version that comes straight from Microsoft and requires no further negotiation with the MPEG-LA and other patent holders, or (b) an ffmpeg backend that requires you to negotiate with the patent stock holders if you plan on using.
You could build a Silverlight-based application, the trick to get access to the local system is very simple: you run a local web server that exposes those services.
You can still use C#/Sqlite or VistaDB as your storage system as part of your Silverlight application.
You could host the silverlight app in http://localhost/App.xap and this app would gain local access to the machine by contacting a REST or SOAP web service on http://localhost/rest.ashx or http://localhost/soap.asmx
For example, if you needed to read some values from a scanner connected to the machine, you would issue this request:
http://localhost/scanner.ashx?operation=scan_badge
Then your scanner.ashx HttpHandler will do the actual scanning (this one has full system rights) and return the value to the Silverlight application.
What code libraries are there to rip audio CDs (e.g. DAE, Digital Audio Extraction)? Must be suitable for commerical use (e.g., no GPL) Preferably free. Linux or FreeBSD or Windows. Most interested in libraries that run on unix-like OS's, especially FreeBSD.
If you're interested in Windows-only, I believe you can use the Windows Media Player control to rip CDs. It's built into Windows and thus shouldn't have any royalty issues.
If you need something that runs cross-platform, it may be more challenging.
If the Mono project is successful it will pave the way for commercial software on non-Windows platforms.
I am interested in the prospect of writing and selling commercial software for the Mono platform along the lines of our existing Smoke Vector Graphics (OCaml) and F# for Visualization (.NET) products. Are any commercial library developers already building upon Mono and, if so, are they turning a profit from it?
Also, will it be feasible to write the software in Microsoft's F# language or will Mono have trouble with ILX?
Mono is a perfectly valid platform for running commercial software as a lot of companies have already proven. Some of them you can see here but there is a lot of which you will never hear about as they are running Mono in embedded environments (Sandisk Salsa mp3 player). From the latest news, Electronic Arts is going to use Mono for Sims3. How is that for an argument?
One of the main points of Mono is minimizing the effort for developers coming from Windows to Linux. In most cases no additional effort is required to make the same software that you already have on Windows, run on Linux, MacOS and other platforms in Mono.
Just to clarify some things that other people answering your question conveniently forgot about. Most of Mono (recently even the compiler) is licensed under MIT/X11 license which allows you to pretty much deploy it in under and conditions you see fit. There is no GPL "cancer" that some people seem to be so afraid of.
Personally, I have been playing with F# and Gtk# in Mono and I loved the experience. More about it here. This was possible due to the fact that the F# team has made sure that F# can run on Mono and they provided a simple Linux installer in their release. This should also be a signal that Mono is regarded as serious alternative to .Net, even by Microsoft.
The Mono project lists a number of successful commercial projects here, and I would particularly point out Unity as being one of the more notable ones.
My figures speak against it, we developed Qide 10 years ago and got 4 or so buys. We got at least a few hundred time more on Windows. The state of tools on Linux can just be named bad. Agreed you have wonderful things there but if you use GPLd software you will drown in their license stuff. There does exist one debugger really and one C compiler it gdb and gcc, despite the efforts of Intel and if you come along into some less well known language you got nothing. Ever tried ProjectCenter (Objective C development environment)? , the debuggers are mostly clis and you have to type info reg to get info about registers. DDD works very funny, it's one tools that while scrolling did not get that right, you scroll up you have to scroll the mouse wheel down. It's also unbelievable slow to scroll it's just as if the BOFH wants to make a joke of you.
Well I could argue about the even sader state on IBM AIX. What you have to pay to IBM is way beyond any reason...
So maybe you're luckier than we are. But I'm mostly fed up with trying to earn money with "application" development on Linux. The best I can say is that Linux works well for setting up net infrastructure, there you got decent payments, but with programming tools, forget it.
Regards
Linux people are notoriously thrifty, so I'd consider the ROI.
Do you really want to spend your resources to target a group that has less than 10% market adoption, and out of that 10%, only 1% would be interested in your product, and only %0.01 percent would pay for it?
I'm designing a user interface for a large touchscreen device running Linux. What would be the best toolkit/developer kit/SDK to use? The only requirement is that its able to run on a semi-low performace device, and that there is a Linux version.
Nice-to-haves would be build in support for effects/animations and a modern look-and-feel, but they are not necessary.
I'm looking at Adobe Flex/AIR already, but I'm not sure if the device will meet the minimum specs.
Try QTopia (http://trolltech.com/products/qtopia)
It's from the same stable as the popular Qt desktop toolkit.
I agree with Mopoke, QTopia is what you want.
It has support from some graphics hardware (2d and 3d), and can also use the kernel framebuffer device if that's all you need.
It's based on Qt, a very well-designed object-oriented GUI framework
It's available for both open-source and commercial projects, although closed-source projects need to pay a license fee.
You should check out whatever tool-kits are used for the Chumby. It's a completely open-source Linux device (open schematic, open source software, etc) with a very rich user-interface (color touch-screen, builtin wifi, USB ports, etc). I believe it's user-submitted "applications" are Adobe Flex/Flash based but there are a variety of open "hacks" including a port of Quake that can be easily downloaded and run.
You can try Disko.
Check out Clutter.
QTopia is indeed a good option; others are DirectFB, and of course X11 generally running Matchbox.
CodeTyphon can let you easily code, visually design and cross compile GUI touch screen applications for embedded linux.
http://www.pilotlogic.com/sitejoom/index.php?option=com_content&view=article&id=96&catid=68&Itemid=147