Everyday now we see more and more requests for codec or container that XBMC doesn't already support yet, ...you have probably seen them yourself too, ex:
- H.264 in MP4 containers (inc. Nero Digital MPEG-4 AVC)
- dvr-ms (microsoft windows media center container)
- DivX Media Format (a.k.a. DivX6 container, or DMF), (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 we, the Team-XBMC developers don't add any codecs ourselves to XBMC.*XBMC uses MPlayer as our 'core' to play video/audio files and therefore XBMC only support those codecs which MPlayer can demux and decode, (well, most of the media formats that MPlayer supports anyway), (MPlayer in turn get most of its codec support from the ffmpeg codec-suit). Sure, we would also love it if XBMC always supported all the latest (and oddest) codecs, however we believe 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 instead of requesting it from us at the XBMC-project kindly ask the MPlayer guys (www.mplayerhq.hu) and/or the FFmpeg guys (ffmpeg.sourceforge.net) to add your favorite codec into their player respective codec-suit. Then if and when MPlayer plays it on Linux/Win32, you got a big chance that XBMC will soon be able to play it too.
Besides, none of us on Team-XBMC are experts on audio/video codecs, so we rather leave it to the real codec gurus, like the MPlayer and FFmeg developers, (don't get us wrong, many of us know a great deal of MPlayer, however not enough that we feel comfortable with writing own native demuxers/codecs or reverse-engineer existing proprietary ones 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 us and we we will integrate it into XBMC CVS if it's good, (heck, if you are a codec-developer then you don't even have to have XDK, instead code the patch directly for MPlayer or FFmpeg on Linux/Win32 and submit it to them instead of us, ...only downside to that is that it takes longer before the code/patch reaches XBMC CVS).
Another thing to note is a few codecs that are supported by MPlayer but not working in XBMC; generally all native codecs (such as the FFmpeg codec-suit in MPlayer) work in xbmc just fine, (these include codecs like MPEG-1/2, DivX, XviD, MP3, etc. which MPlayer/FFmpeg have the full source code of nativly). However external proprietary codecs like DLL's (all binary codecs which no source code is available for) generally do not work well in XBMC; we managed to add support for a few DLL's like RealVideo, QuickTime, WMV9/WMA9 and VP5/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). the main problem is that DLL codecs depend very heavily on Microsoft Windows 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 full operating-system (and WINE), but understand that even though the Xbox is made by Microsoft it does not run Windows (nor Linux) like some might think, the Xbox also have many other limitations, so it's very hard, if not impossible for us to do use closed source DLL's perfectly in XBMC, most binary codecs (DLL's) simply depends too heavily on Windows. Native codecs with the full source code available are always best and much prefered to any closed source DLL codec, (closed source proprietary codecs and proprietary codecs in general are bad).
If you like to request a new codec for MPlayer then respect that they use mailing-lists instead of a forum like us and you can not just send a mail to those mailing-lists without first suscribing to it/them first, (suscribing is free, and you can unsubscribe at any time). MPlayer does also have a bugzilla bug-tracking system (link) for MPlayer but it is only for [url="http://www.mplayerhq.hu/docs/html/en/bugreports.html"]MPlayer-bugs, not for codec/feature requests or suggestions so please respect that, ...however if you suspect an issue/problem with an existing codec or media-file that already is supported in MPlayer then confirm that you see the very same issue/problem it latest MPlayer for Linux/Win32 and then report that bug to MPlayer, 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! Carefully research codec coding process before you request support for any new codecs from MPlayer-devs and/or FFmpeg-devs:
* 1st: They preferably need the full source code (of the full stand-alone audio/video codec written in C/C++ and it must be GPL or LGPL open source), if noone else has already open sourced this codec then they would have to reverse-engineer it from scratch to create a new native codec (which is very/extremly hard) and they are thus very unlikely to do so even if you ask nicely, (one project we know who can/will do that is the FFmpeg, however we're 100% sure 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, ...money is usually not welcomed but computer equipment usually is).
* 2nd: The source code available must 'fit' in the current MPlayer core; ex. you could give someone the engine of an huge airplane and ask him/her to put that into a small Peugeot-206 car but it just won't fit no matter how hard one tries. The same goes with software, just having the source code is sometimes not enough as sometimes it 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 people who have not thoroughly researched what they're asking for!!!
(We have nothing against the MPlayer-devs, they have good reasons to be very strict, stupid requests should be ignored and can be flamed!).
We recommend you start your research by extensive googling first however you may also want to start with checking sites like multimedia.cx.
PPS!! FYI, other open source projects that work on reverse enginnering audio/video codecs are; gmerlin, libquicktime., xine, and corecodec.
Regards / Team-XBMC
Note! Please do not post codec suggestions/requests in this specific thread!!!, this thread was created to inform, not to discuss, thanks.
Edit: the above statements/explainations was last updated on the 14th of August 2006 and was at that time deamed to be up-to-date.
@Anyone wanting to request new codec formats support, READ THIS FIRST!
Joined: Sep 2003
2004-02-20 17:37 @Anyone wanting to request new codec formats support, READ THIS FIRST! Post: #1
(This post was last modified: 2006-08-14 21:02 by Gamester17.)