Codec and Format requests

Team-XBMC get the questions "Where can I request/suggest a new codec-decoder or file-format to be implemented into XBMC?" and "When will this and that codec-decoder or file-format be added and supported by XBMC?" so often that this page had to be added to the manual, please read it through and try to understand and respect what this says.

Everyday now you can see more requests for codec or container that XBMC does not yet support or better support of existing formats,
 * ...you have probably seen them yourself too, example:


 * DivX Media Format (DMF DivX6 container) (DivX Ultra Certification) end-users are better of requesting this directly from DivXnetworks
 * RealNetworks RealVideo 10 (rv10)
 * RealNetworks RealAudio10 (ra10) Cook 6-channel surround
 * Sony ATRAC3
 * mp3PRO Coding Technologies "SBR (Spectral Band Replication)" code)
 * Fraunhofer IIS MP3 surround (5.1 multi-channel MP3)
 * MPEG surround audio coding ISO standard (5.1/6.1/7.1 multi-channel MP3, AAC, PCM)
 * HDCD (High Definition Compatible Digital) CDs at their full quality (and not just in 'backwards compatible mode')
 * XMV (Xbox Video Format/Codec) (this could probebely be added by any dev since the XDK supports it?)
 * Vodei multimedia processor video codec
 * ...etc. (and so on, and so on, and so on...).

We hope that we here can clearly explain why we can't do very much with these requests or suggestions for new video/audio codec;

The fact is that the Team-XBMC developers do not add any codecs ourselves to XBMC. XBMC uses MPlayer as our main 'core' to play video/audio files and therefore XBMC only support those codecs which MPlayer can demux and decode, (well, most of the media codecs/formats that MPlayer supports anyway), and MPlayer in turn get most of its codec support from the FFmpeg codec-suit. Sure, Team-XBMC would also love it if XBMC always supported all the latest (and oddest) codecs, however Team-XBMC opionion is that those should be added to MPlayer for Linux/Win32] first and not directly into XBMC. So the best thing if you are an end-user is to instead of requesting it from Team-XBMC (and The XBMC Project), kindly ask the MPlayer-developer guys (www.mplayerhq.hu) and/or the FFmpeg-developer guys (ffmpeg.sourceforge.net) to add your favorite codec into their player (MPlayer) respective codec-suit (FFmpeg). Then if and when MPlayer plays it on Linux/Win32, you got a big chance that XBMC will be able to play it too soon).

Besides, no one of Team-XBMC are experts on audio/video codecs, thus rather leave it to the real codec gurus, like the MPlayer and FFmpeg developers, (please do not get the wrong idea, many of Team-XBMC know a great deal of the inside workings of MPlayer, however no one Team-XBMC feel comfortable enough with writing their own native demuxers/codecs or reverse-engineer existing proprietary demuxers/codecs as doing so are enormous tasks). Of course, if someone else has the skill and wants to program/port new codecs for XBMC then thats fine; feel free to submit the source code patch for it to The XBMC Project and it will integrate into the XBMC CVS if it good, (but, if you are a codec-developer then you should not have to mess with the Xbox Development Kit, instead code the patch directly for MPlayer and/or FFmpeg on Linux or Windows and then submit it to them instead of The XBMC Project, as if it makes to into MPlayer or FFmpeg it will sooner or later make it into XBMC ...the only downside to that approch is that it will take longer before the code/patch reaches the XBMC CVS).

Another thing to note is a few codecs that are supported by MPlayer on Linux/Win32 but not working in XBMC; (generally all native codecs, such as the FFmpeg codec-suit in MPlayer works just fine in XBMC, and these include codecs like MPEG-1/2, DivX, XviD, MP3, etc. which MPlayer/FFmpeg have the full source code of nativly). This is becuase external proprietary codecs like DLL's (Dynamic Link Library codec-files, which for MPlayer are all closed cource binary codecs, with no open source code is available for) generally do not work well in XBMC; Team-XBMC have managed to add support for a few DLL's like RealVideo, QuickTime, WMV9/WMA9 and VP4/5/6 into XBMC but those where a hell of a job to code support for so they would load, (plus they are not as fast as the native codecs, nor as stable). The main problem is that DLL codecs-files depend very heavily on Microsoft Windows operating-system to work (because they where only designed to work on that operating-system platform). Under Linux, MPlayer have managed to emulate Windows pretty well because it has the resourses of a complete operating-system (and the full WINE library to help emulate Windows components), but understand that even though the Xbox is made by Microsoft it does not run a Windows operating-system (nor Linux), at least not as you might think, (and the Xbox also have many other limitations), so it is very hard, if not impossible for Team-XBMC to use closed source DLL's perfectly in XBMC, as most binary codecs (DLL's) simply depends too heavily on the full Windows operating-system. Native codecs with the full source code openly available are always best and much prefered to any closed source DLL codec. (In conclusion; closed source proprietary codecs and proprietary codecs and bad in general).

If you like to request a new codec for MPlayer then respect that they use mailing-lists (and not a forum like the XBMC-project hav,e) and you can not just send a mail to those mailing-lists without first suscribing to it first, (suscribing is free, and you can unsubscribe at any time). MPlayer does also have a bugzilla bug-tracking system for MPlayer but it is only for MPlayer-bugs, and not for codec/feature requests so please respect that, ...however if you suspect that an issue/problem with an existing codec or media-file that already is supported in MPlayer on Linux/Win32 then confirm that you see the very same issue/problem it latest MPlayer for Linux/Win32 and then report that bug to MPlayer via their bugzilla bug-tracking system, (and optionally also write to their their dev mailing-list informing them about that bug-report, for a possible faster reply). Before you post your bug-report to MPlayer's bug-tracker make sure you followed the guide-lines in the MPlayer documentation. Respect that it is not enough that you see the issue/problem in XBMC, (in fact you should not even mention XBMC in a MPlayer bug-report!).

Note! Before you request support for any new codecs from MPlayer or FFmpeg developers, carefully research codec coding process:
 * 1st: They will preferably need the full source code (of the full stand-alone audio/video codec written in C or C++ programming-lanuage and it must be open sourced under GPL or LGPL lisence), if three are not open source codec for that format then the MPlayer/FFmpeg developers would have to reverse-engineer it from scratch to create a new native codec, which is very/extremly hard and can take a long time to do, and thus they are very unlikely to do so even if you ask nicely, (however one project has the skill and experince of reverse-engineering codecs from scratch are FFmpeg, but they require much more convincing than a simple request from one or two end-users to take on something as difficult, (lobbying is one way, bribing is another, to encurage them to do so, ...money is usually not welcomed by them on principle but computer equipment/hardware usually is).
 * 2nd: The source code available must 'fit' in the current MPlayer or FFmpeg design; for example. you could give someone the engine of an huge air-plane and ask him/her to put that into a small Peugeot-206 car but that would just not fit no matter how hard one tries. The same goes with software, just having the source code is sometimes not enough as it sometimes will means rewriting (all) code to get it into your own application (MPlayer/FFmpeg in this case).

PS! The MPlayer-developers are very technical and do not appreciate novice people who have not thoroughly researched what they are asking for! (Nothing againts the MPlayer and FFmpeg developers who are known to be very strict, but they easily start flaming naive requests, many times for good reason, stupid requests should be ignored). So highly recommend you start your research by extensive googling first, you may also want to start with checking out websites and projects like; multimedia.cx, gmerlin, libquicktime, xine, and corecodec, which are some open source projects that work on reverse enginnering audio/video codecs).