Honestly, documentation could indeed be better. But nobody likes writing documentation, isn't it? The Xvid source code itself and in particular the Xvid API ("xvid.h") are quite well documented and documentation can be extracted with doxygen. Also, there's some lean instructions on how to compile the code in the "/doc" folder.
Make sure you have the Windows Platform SDK installed on your development host. This includes the DirectShow SDK, which is needed to compile the Xvid DirectShow filter. Make sure you also compile the DirectShow baseclasses lib (which is in the samples dir of the SDK) because the Xvid filter links against it.
If you seriously want to work on the codec you should first get some background on video coding. Do some read up on the internet how block-based video compression works. Once you feel you have a solid understanding you should begin studying the Xvid source code and take a look at the API documenation. You should also subscribe to the xvid-devel mailing list where you can discuss your ideas with other Xvid developers or post your contributions.
Make sure you have the latest version of nasm installed for your platform: http://nasm.sourceforge.net. If you still get experience issues and you try to compile for a rather new platform/OS you may require the latest vcs version of nasm. Alternatively, you can try yasm instead: http://www.tortall.net/projects/yasm/. If both doesn't help please report your problem at xvid-devel@xvid.org.
Have a look at the INSTALL readme file that comes along with Xvid in the "/doc" folder. It describes how to use the Xvid build scripts to compile Xvid with gcc under Linux or MinGW/CygWin on Windows. Xvid can also be compiled with the Microsoft Visual C++ compiler using the provided project files the "/build/win32" directory. For other compilers you’re pretty much on your own. It should not be very difficult however to make the code compile with a different compiler.
Mainly, picture quality depends on the quality of decisions taken by the encoder. Such decisions include finding good motion vectors and modes for each macroblock, determining the best coding types for each picture and the best quantization parameters per macroblock. Hence, picture quality is mainly influenced by motion estimation algorithms, R-D optimizations and bitrate-control. If you’re interested in improving video quality, you should have a look into these algorithms and try out your new ideas.
First of all: Processing digital video is a demanding task and requires lot more resources than e.g. audio coding. So it’s probably not unexpected at all that Xvid, especially the encoder, does not run fast on your new platform.
If you think it’s running slower than it should the cause could be that Xvid’s assembly optimizations are not active on your platform. A common reason might be that your target platform uses an instruction set not supported by Xvid's hand-tuned assembly optimizations.
In this case you could try writing optimized code for your platform yourself to speed up the performance. Typical bottlenecks for video decoding are the inverse transform, motion compensation and dequantization. For encoding, calculating the sum of absolute differences (SAD) in motion estimation is a well-known hotspot that needs lots of computational resources.
That depends on the platform you develop your application for. On all platforms, you can statically or dymically link against the xvidcore library and interface to it via the Xvid API (refer to the "xvid.h" API header file in your copy of the source code). Under Windows, you can also access Xvid via the Video for Windows (VfW), DirectShow or Media Foundations framework APIs. Under Linux, Xvid has been integrated into MPlayer/MEncoder, FFmpeg or the GStreamer framework. So you may interface with the Xvid codec also through these frameworks.
That depends on your application and your specific goals and requirements. Interfacing via the Xvid API provides you the greatest flexibility and platform independence. You could port your application easily to a new operating system and would just have to recompile the xvidcore library. Access through other interfaces is OS dependent. So VfW access will obviously only work under Windows but could make things simpler and may allow you to more easily support also other codecs besides Xvid from your app.
Yes, but it could be better. The Xvid API is documented in-line in the "xvid.h" header file (it can be extracted with doxygen). Also, the xvid_decraw and xvid_encraw example programs demonstrate the use of pretty much all xvidcore library features.
The Xvid code is released under the terms of the GNU General Public License (GPL). Please refer to the License subsection of this FAQ for more information on the license and its practical implications.
That depends and cannot easily be answered. It depends on the use-case of your application. E.g. if you aim at live broadcast of video, selecting the two-pass mode obviously won't make any sense for you. In general, you should select one of the predefined profiles that comes closest to your use-case and adapt the settings from there. Have a look at the "xvid.h" API header file and corresponding docs for more info on the Xvid de- and encoder options.
Xvid internally operates in YV12 colorspace format. So if any possible you should try to work with this colorspace also in your application (e.g. capture video in YV12 format from a camera or render YV12 video directly to the screen) to avoid unneeded colorspace conversions. Such conversions are costly and reduce overall performance. Also, you should try to avoid unnecessary memcopy of picture data and instead better exchange pointers to your input/output buffers with xvidcore.
Read the API documentation. Also, have a look at the example applications as a reference on how the API can be used and what settings (and defaults) generally make sense. If still in doubt, run some test with different settings on your own to determine which values are good for your use-case.
Xvid has been developed with high quality in mind. Hence, the Xvid encoder is especially good at offline, multi-pass compression yielding output files good for efficient storage or quick transmission over network. A single-pass, real-time capture mode is also implemented in Xvid but optimized for high picture quality rather than low-latency.
The Xvid code is released under the terms of the GNU General Public License (GPL). The GPL is a copyright license that – opposed to other such licenses – grants receivers additional freedoms, like e.g. a redistribution right as well as a right to make modifications to the Xvid code.
There are requirements however: Among others, the GPL requires modified or combined/derived works to be distributed as a whole under the terms of the GPL as well. Refer to the GPL license text, which is included with your copy of the Xvid source code, for more detailed information.
No. Just from the fact that the source code of a software is available you cannot conclude about the license under which it's distributed. Open-source projects may distribute their code under one of many, diverse open-source licenses. Actually, it's rare source code really is released into public domain. Unfortunately, the different license terms behind different open-source projects are often not well reported.
The Xvid code is not public domain. It is copyrighted and published under the GNU GPL license. Refer to the license text for more detailed information. Note that redistribution of Xvid is permitted only under the terms of the GPL. Infringements are prosecuted by the copyright holders as would be the case also for any other copyrighted work.
No. The GPL is a software license and covers the Xvid program code only. The Xvid name and logo are trademarks and registered trademarks worldwide. As a recipient of the Xvid source code, no rights to use the Xvid name or logo are granted to you. If you'd like to use the Xvid name or logo including but not limited to e.g. use it for advertising your software, service or product, you'll need to obtain permission from us prior to any such usage.
If your program calls upon Xvid functionality at run-time it is a derived work and hence, the terms of the GPL apply to the work as a whole including your program. So no, you cannot distribute Xvid together with your proprietary program then. If you want to distribute, you’ll have to publish your program under the GPL as well. This also requires e.g. the provision of the full apps source code. Refer to the GPL license text for more information.
No. It doesn't matter in which way you link to Xvid or what you consider as linking and what not. The GPL doesn't focus on the term 'linking' at all but rather requires that combined/derived works are published as a whole under the terms of the GPL. Basically any two (or more) pieces make up a combined work when they are distributed for use in combination. Hence, if your program calls upon Xvid functionality at run-time it would make up a derived work - no matter how you technically implement the calls to Xvid. If you don't want to publish your program under the GPL then simply refrain from distributing it in combination with Xvid.
A key goal of the Xvid project has always been to trigger the further creation of Free Software. Consequently, Xvid is released under the terms of the GPL to allow free distribution and combination with other GPLed programs – but only GPLed programs. Hence, we do not consider publishing the Xvid source code under any other open-source license than the GPL. It is unfortunately true that there have been also violators who don't respect our copyright and the GPL license. But we strictly prosecute GPL violations. Anyone who deliberately violates the GPL will realize soon enough that it'll get him in trouble.
Yes. Usage, so the act of running a program, is not restricted by the GPL license under which Xvid is published. So you can use the Xvid codec with whatever other program you want. Just distribution of Xvid together with proprietary software is restricted. Refer to the GPL license text for detailed information.
Yes, you can - provided it's really just a media CD and you don't intend to distribute Xvid together with proprietary programs, like e.g. a video player. If you distribute Xvid, make sure to fulfill the requirements of the GPL, which e.g. includes distributing a copy of the GPL text along with Xvid. If you want to distribute a binary version of Xvid, you should add a copy of the matching Xvid source code to your distribution.
You should comply to the requirements of the GPL for redistribution. This e.g. includes providing a copy of the GPL license text and offering a copy of the corresponding Xvid source code in case you distribute a binary version. Refer to the GPL license text for more information.
No, thanks. We've expressed before why we prefer the GPL. Switching to another open-source license than GPL is nothing we would currently consider.
Yes, you can. We created Xvid to be used with other GPLed programs. Just make sure that the app or package you intend to distribute is really licensed as a whole under the GPL or a compatible license (like LGPL). Sometimes, dependencies of an application may be published under a different, incompatible license. This could then pose a problem for combined distribution. If in doubt ask at info@xvid.org.
If you decide to release your program under GPL it'll impose providing access to the full source code of your program. It also means recipients will be granted a right to redistribute your program, to make modifications to it or to create a new work based on your program. For more info read the GPL license text or visit http://www.gnu.org.
The GPL does not restrict the act of running a program. Hence, you can certainly use the Xvid encoder to create video for whatever purpose. As long as you don't distribute Xvid or parts of the Xvid source code you won’t be running into any limitations stemming from the GPL license. You also don't need to obtain any further permission from us.
You can freely distribute it. The output or result from running a program is not covered by the GPL license. Hence, video encoded with Xvid is not subject to the terms of the GPL. Note however that you of course can only distribute videos where you hold the copyrights or where you have permission to distribute from the copyright holders. But that has nothing to do with Xvid and should go without saying...
That depends. You can port the Xvid code to new hardware without requiring any specific license. You are permitted to make modifications to the Xvid source code and running Xvid on your device is not restricted by the GPL, so you may demo your port in-house. As soon as it comes to distribution, you should be aware that all modules you distribute together with Xvid intended for use in combination will be considered a derived work and covered by the terms of the GPL as a whole.
So if you e.g. want to distribute a software player that uses Xvid at run-time for video playback it will be covered as a whole by the GPL. It means that the player application and all other modules (like e.g. other video decoders, demuxers or audio codecs) must be distributed under the terms of the GPL as well. If you can meet these requirements you'll be able to distribute your hardware/software together with Xvid. If you can not or are unsure plese write us at info@xvid.org and let's dicuss your project.