VideoLAN Client API Documentation

Christophe Massiot

Developer
IDEALX S.A.S.
Industrial Computing

Table of Contents
Glossary
1. VLC Overview
1.1. Code modules
1.2. Plug-ins
1.3. Threads
1.3.1. Thread management
1.3.2. Synchronization
1.4. Code conventions
1.4.1. Function naming
1.4.2. Variable naming
1.4.3. A few words about white spaces
2. VLC interface
2.1. A typical VLC run course
2.2. The message interface
2.3. Command line options
2.4. Playlist management
2.5. Module bank
2.6. The interface main loop
2.7. How to write an interface plugin
3. The complex multi-layer input
3.1. What happens to a file
3.2. Stream Management
3.3. Structures exported to the interface
3.4. Methods used by the interface
3.5. Buffers management
3.6. Demultiplexing the stream
4. How to write a decoder
4.1. What is precisely a decoder in the VLC scheme ?
4.2. Decoder configuration
4.3. Packet structures
4.4. The bit stream (input module)
4.5. Built-in decoders
4.6. The MPEG video decoder
4.6.1. Motion compensation plug-ins
4.6.2. IDCT plug-ins
4.6.3. Symmetrical Multiprocessing
5. The video output layer
5.1. Data structures and main loop
5.2. Methods used by video decoders
5.3. How to write a video output plug-in
5.4. How to write a YUV plug-in
6. The audio output layer
6.1. Data exchanges between a decoder and the audio output
6.2. How to write an audio output plugin
A. Ports
A.1. Port steps
A.2. Building
B. Advanced debugging
B.1. Where does it crash ?
B.2. Other problems
C. Project history
C.1. VIA and the Network2000 project
C.2. Foundation of the VideoLAN project
C.3. VideoLAN Client design
C.4. The Opening
D. GNU Free Documentation License
0. PREAMBLE
1. APPLICABILITY AND DEFINITIONS
2. VERBATIM COPYING
3. COPYING IN QUANTITY
4. MODIFICATIONS
5. COMBINING DOCUMENTS
6. COLLECTIONS OF DOCUMENTS
7. AGGREGATION WITH INDEPENDENT WORKS
8. TRANSLATION
9. TERMINATION
10. FUTURE REVISIONS OF THIS LICENSE

Glossary

Warning

Please note that this book is in no way a reference documentation on how DVDs work. Its only purpose is to describe the API available for programmers in VideoLAN Client. It is assumed that you have basic knowledge of what MPEG is. The following paragraph is just here as a reminder :

AC3 : Digital Audio Compression Standard

Specification for coding audio data, used in DVD. The documentation is freely available .

B (bi-directional) picture

Picture decoded from its own data, and from the data of the previous and next (that means in the future) reference pictures (I or P pictures). It is the most compressed picture format, but it is less fault-tolerant.

DVD : Digital Versatile Disc

Disc hardware format, using the UDF file system, an extension of the ISO 9660 file system format and a video format which is an extension of the MPEG-2 specification. It basically uses MPEG-2 PS files, with subtitles and sound tracks encoded as private data and fed into non-MPEG decoders, along with .ifo files describing the contents of the DVD. DVD specifications are very hard to get, and it takes some time to reverse-engineer it. Sometimes DVD are zoned and scrambled, so we use a brute-force algorithm to find the key.

ES : Elementary Stream

Continuous stream of data fed into a decoder, without any multiplexing layer. ES streams can be MPEG video MPEG audio, AC3 audio, LPCM audio, SPU subpictures...

Field picture

Picture split in two fields, even and odd, like television does. DVDs coming from TV shows typically use field pictures.

Frame picture

Picture without even/odd discontinuities, unlike field pictures. DVDs coming from movies typically use frame pictures.

I (intra) picture

Picture independantly coded. It can be decoded without any other reference frame. It is regularly sent (like twice a second) for resynchronization purposes.

IDCT : Inverse Discrete Cosinus Transform

IDCT is a classical mathematical algorithm to convert from a space domain to a frequency domain. In a nutshell, it codes differences instead of coding all absolute pixels. MPEG uses an 2-D IDCT in the video decoder, and a 1-D IDCT in the audio decoder.

LPCM : Linear Pulse Code Modulation

LPCM is a non-compressed audio encoding, available in DVDs.

MPEG : Motion Picture Expert Group

Specification describing a standard syntax of files and streams for carrying motion pictures and sound. MPEG-1 is ISO/IEC 11172 (three books), MPEG-2 is ISO/IEC 13818. MPEG-4 version 1 is out, but this player doesn't support it. It is relatively easy to get an MPEG specification from ISO or equivalent, drafts are even freely available on the Internet.

P (predictive) picture

Picture decoded from its own data and data from a reference picture, which is the last I or P picture received.

PES : Packetized Elementary Stream

A chunk of elementary stream. It often corresponds to a logical boundary of the stream (for instance a picture change), but it is not mandatory. PES carry the synchronization information.

PTS : Presentation Time Stamp

Time at which the content of a PES packet is supposed to be played. It is used for A/V synchronization.

PS : Program Stream

File format obtained by concatenating PES packets and inserting Pack headers and System headers (for timing information). It is the only format described in MPEG-1, and the most used format in MPEG-2.

RGB : Red Green Blue

Picture format where every pixel is calculated in a vector space whose coordinates are red, green, and blue. This is natively used by monitors and TV sets.

SPU : Sub Picture Unit

Picture format allowing to do overlays, such as subtitles or DVD menus.

SCR : System Clock Reference

Time at which the first byte of a particular pack is supposed to be fed to the decoder. VLC uses it to read the stream at the right pace.

SDL : Simple DirectMedia Layer

SDL is a cross-platform multimedia library designed to provide fast access to the video framebuffer and the audio device. Since version 1.1, it features YUV overlay support, which reduces decoding times by a third.

TS : Transport Stream

Stream format constituted of fixed size packets (188 bytes), defined by ISO/IEC 13818-1. PES packets are split among several TS packets. A TS stream can contain several programs. It is used in streaming applications, in particular for satellite or cable broadcasting.

YUV : Luminance/Chrominance

Picture format with 1 coordinate of luminance (black and white) and 2 coordinates of chrominance (red and blue). This is natively used by PAL video system, for backward compatibility with older black and white TV sets. Your eyes distinguish luminance variations much better than chrominance variations, so you can compress them more. It is therefore well suited for image compression, and is used by the MPEG specification. The RGB picture can be obtained from the YUV one via a costly matrix multiply operation, which can be done in hardware by most modern video cards ("YUV acceleration").


Chapter 1. VLC Overview


1.3. Threads


1.3.2. Synchronization

Another key feature of VLC is that decoding and playing are asynchronous : decoding is done by a *_decoder thread, playing is done by audio_output or video_output thread. The design goal is to ensure that an audio or video frame is played exactly at the right time, without blocking any of the decoder threads. This leads to a complex communication structure between the interface, the input, the decoders and the outputs.

Having several input and video_output threads reading multiple files at the same time is permitted, despite the fact that the current interface doesn't allow any way to do it [this is subject to change in the near future]. Anyway the client has been written from the ground up with this in mind. This also implies that a non-reentrant library (including in particular LiViD's libac3) cannot be used.

Presentation Time Stamps located in the system layer of the stream are passed to the decoders, and all resulting samples are dated accordingly. The output layers are supposed to play them at the right time. Dates are converted to microseconds ; an absolute date is the number of microseconds since Epoch (Jan 1st 1970). The mtime_t type is a signed 64-bit integer.

The current date can be retrieved with mdate(). Te execution of a thread can be suspended until a certain date via mwait ( mtime_t date ). You can sleep for a fixed number of microseconds with msleep ( mtime_t delay ).

Warning

Please remember to wake up a little while before the presentation date, if some particular treatment needs to be done (e.g. a YUV transform). For instance in src/video_parser/vpar_synchro.c, track of the average decoding times is kept to ensure pictures are not decoded too late.


1.4. Code conventions


Chapter 2. VLC interface


2.2. The message interface

It is a know fact that printf() functions are not necessarily thread-safe. As a result, one thread interrupted in a printf() call, followed by another calls to it, will leave the program in an undetermined state. So an API must be set up to print messages without crashing.

This API is implemented in two ways. If INTF_MSG_QUEUE is defined in config.h , every printf-like (see below) call will queue the message into a chained list. This list will be printed and flushed by the interface thread once upon an event loop. If INTF_MSG_QUEUE is undefined, the calling thread will acquire the print lock (which prevents two print operations to occur at the same time) and print the message directly (default behaviour).

Functions available to print messages are :


Chapter 3. The complex multi-layer input

The idea behind the input module is to treat packets, without knowing at all what is in it. It only takes a packet, reads its ID, and delivers it to the decoder at the right time indicated in the packet header (SCR and PCR fields in MPEG). All the basic browsing operations are implemented without peeking at the content of the elementary stream.

Thus it remains very generic. This also means you can't do stuff like "play 3 frames now" or "move forward 10 frames" or "play as fast as you can but play all frames". It doesn't even know what a "frame" is. There is no privileged elementary stream, like the video one could be (for the simple reason that, according to MPEG, a stream may contain several video ES).


3.2. Stream Management

The function which has opened the input socket must specify two properties about it :

  1. p_input->stream.b_pace_control : Whether or not the stream can be read at our own pace (determined by the stream's frequency and the host computer's system clock). For instance a file or a pipe (including TCP/IP connections) can be read at our pace, if we don't read fast enough, the other end of the pipe will just block on a write() operation. On the contrary, UDP streaming (such as the one used by VideoLAN Server) is done at the server's pace, and if we don't read fast enough, packets will simply be lost when the kernel's buffer is full. So the drift introduced by the server's clock must be regularly compensated. This property controls the clock management, and whether or not fast forward and slow motion can be done.

  2. p_input->stream.b_seekable : Whether we can do lseek() calls on the file descriptor or not. Basically whether we can jump anywhere in the stream (and thus display a scrollbar) or if we can only read one byte after the other. This has less impact on the stream management than the previous item, but it is not redundant, because for instance cat foo.mpg | vlc - is b_pace_control = 1 but b_seekable = 0. On the contrary, you cannot have b_pace_control = 0 along with b_seekable = 1. If a stream is seekable, p_input->stream.p_selected_area->i_size must be set (in an arbitrary unit, for instance bytes, but it must be the same as p_input->i_tell which indicates the byte we are currently reading from the stream).


3.3. Structures exported to the interface

Let's focus on the communication API between the input module and the interface. The most important file is include/input_ext-intf.h, which you should know almost by heart. This file defines the input_thread_t structure, the stream_descriptor_t and all programs and ES descriptors included (you can view it as a tree).

First, note that the input_thread_t structure features two void * pointers, p_method_data and p_plugin_data, which you can respectivly use for buffer management data and plugin data.

Second, a stream description is stored in a tree featuring program descriptors, which themselves contain several elementary stream descriptors. For those of you who don't know all MPEG concepts, an elementary stream, aka ES, is a continuous stream of video or (exclusive) audio data, directly readable by a decoder, without decapsulation.

This tree structure is illustrated by the following figure, where one stream holds two programs. In most cases there will only be one program (to my knowledge only TS streams can carry several programs, for instance a movie and a football game at the same time - this is adequate for satellite and cable broadcasting).

Warning

For all modifications and accesses to the p_input->stream structure, you must hold the p_input->stream.stream_lock.

ES are described by an ID (the ID the appropriate demultiplexer will look for), a stream_id (the real MPEG stream ID), a type (defined in ISO/IEC 13818-1 table 2-29) and a litteral description. It also contains context information for the demultiplexer, and decoder information p_decoder_fifo we will talk about in the next chapter. If the stream you want to read is not an MPEG system layer (for instance AVI or RTP), a specific demultiplexer will have to be written. In that case, if you need to carry additional information, you can use void * p_demux_data at your convenience. It will be automatically freed on shutdown.

The stream, program and ES structures are filled in by the plugin's pf_init() using functions in src/input/input_programs.c, but are subject to change at any time. The DVD plugin parses .ifo files to know which ES are in the stream; the TS plugin reads the PAT and PMT structures in the stream; the PS plugin can either parse the PSM structure (but it is rarely present), or build the tree "on the fly" by pre-parsing the first megabyte of data.

Warning

In most cases we need to pre-parse (that is, read the first MB of data, and go back to the beginning) a PS stream, because the PSM (Program Stream Map) structure is almost never present. This is not appropriate, though, but we don't have the choice. A few problems will arise. First, non-seekable streams cannot be pre-parsed, so the ES tree will be built on the fly. Second, if a new elementary stream starts after the first MB of data (for instance a subtitle track won't show up during the credits), it won't appear in the menu before we encounter the first packet. We cannot pre-parse the entire stream because it would take hours (even without decoding it).

It is currently the responsibility of the input plugin to spawn the necessary decoder threads. It must call input_SelectES ( input_thread_t * p_input, es_descriptor_t * p_es ) on the selected ES.

The stream descriptor also contains a list of areas. Areas are logical discontinuities in the stream, for instance chapters and titles in a DVD. There is only one area in TS and PS streams, though we could use them when the PSM (or PAT/PMT) version changes. The goal is that when you seek to another area, the input plugin loads the new stream descriptor tree (otherwise the selected ID may be wrong).


3.4. Methods used by the interface

Besides, input_ext-intf.c provides a few functions to control the reading of the stream :


3.5. Buffers management

Input plugins must implement a way to allocate and deallocate packets (whose structures will be described in the next chapter). We basically need four functions :

All functions are given p_input->p_method_data as first parameter, so that you can keep records of allocated and freed packets.


Chapter 4. How to write a decoder


4.3. Packet structures

The input module provides an advanced API for delivering stream data to the decoders. First let's have a look at the packet structures. They are defined in include/input_ext-dec.h.

data_packet_t contains a pointer to the physical location of data. Decoders should only start to read them at p_payload_start until p_payload_end. Thereafter, it will switch to the next packet, p_next if it is not NULL. If the b_discard_payload flag is up, the content of the packet is messed up and it should be discarded.

data_packet_t are contained into pes_packet_t. pes_packet_t features a chained list (p_first) of data_packet_t representing (in the MPEG paradigm) a complete PES packet. For PS streams, a pes_packet_t usually only contains one data_packet_t. In TS streams though, one PES can be split among dozens of TS packets. A PES packet has PTS dates (see your MPEG specification for more information) and the current pace of reading that should be applied for interpolating dates (i_rate). b_data_alignment (if available in the system layer) indicates if the packet is a random access point, and b_discontinuity tells whether previous packets have been dropped.

The structure shared by both the input and the decoder is decoder_fifo_t. It features a rotative FIFO of PES packets to be decoded. The input provides macros to manipulate it : DECODER_FIFO_ISEMPTY, DECODER_FIFO_ISFULL, DECODER_FIFO_START, DECODER_FIFO_INCSTART, DECODER_FIFO_END, DECODER_FIFO_INCEND. Please remember to take p_decoder_fifo->data_lock before any operation on the FIFO.

The next packet to be decoded is DECODER_FIFO_START( *p_decoder_fifo ). When it is finished, you need to call p_decoder_fifo->pf_delete_pes( p_decoder_fifo->p_packets_mgt, DECODER_FIFO_START( *p_decoder_fifo ) ) and then DECODER_FIFO_INCSTART( *p_decoder_fifo ) to return the PES to the buffer manager.

If the FIFO is empty (DECODER_FIFO_ISEMPTY), you can block until a new packet is received with a cond signal : vlc_cond_wait( &p_fifo->data_wait, &p_fifo->data_lock ). You have to hold the lock before entering this function. If the file is over or the user quits, p_fifo->b_die will be set to 1. It indicates that you must free all your data structures and call vlc_thread_exit() as soon as possible.


4.4. The bit stream (input module)

This classical way of reading packets is not convenient, though, since the elementary stream can be split up arbitrarily. The input module provides primitives which make reading a bit stream much easier. Whether you use it or not is at your option, though if you use it you shouldn't access the packet buffer any longer.

The bit stream allows you to just call GetBits(), and this functions will transparently read the packet buffers, change data packets and pes packets when necessary, without any intervention from you. So it is much more convenient for you to read a continuous Elementary Stream, you don't have to deal with packet boundaries and the FIFO, the bit stream will do it for you.

The central idea is to introduce a buffer of 32 bits [normally WORD_TYPE, but 64-bit version doesn't work yet], bit_fifo_t. It contains the word buffer and the number of significant bits (higher part). The input module provides five inline functions to manage it :

All these functions recreate a continuous elementary stream paradigm. When the bit buffer is empty, they take the following word in the current packet. When the packet is empty, it switches to the next data_packet_t, or if unapplicable to the next pes_packet_t (see p_bit_stream->pf_next_data_packet). All this is completely transparent.

To use the bit stream, you have to call p_decoder_config->pf_init_bit_stream( bit_stream_t * p_bit_stream, decoder_fifo_t * p_fifo ) to set up all variables. You will probably need to regularly fetch specific information from the packet, for instance the PTS. If p_bit_stream->pf_bit_stream_callback is not NULL, it will be called on a packet change. See src/video_parser/video_parser.c for an example. The second argument indicates whether it is just a new data_packet_t or also a new pes_packet_t. You can store your own structure in p_bit_stream->p_callback_arg.

Warning

When you call pf_init_bit_stream, the pf_bitstream_callback is not defined yet, but it jumps to the first packet, though. You will probably want to call your bitstream callback by hand just after pf_init_bit_stream.


4.6. The MPEG video decoder

VideoLAN Client provides an MPEG-1, and an MPEG-2 Main Profile @ Main Level decoder. It has been natively written for VLC, and is quite mature. Its status is a bit special, since it is splitted between two logicial entities : video parser and video decoder. The initial goal is to separate bit stream parsing functions from highly parallelizable mathematical algorithms. In theory, there can be one video parser thread (and only one, otherwise we would have race conditions reading the bit stream), along with a pool of video decoder threads, which do IDCT and motion compensation on several blocks at once.

It doesn't (and won't) support MPEG-4 or DivX decoding. It is not an encoder. It should support the whole MPEG-2 MP@ML specification, though some features are still left untested, like Differential Motion Vectors. Please bear in mind before complaining that the input elementary stream must be valid (for instance this is not the case when you directly read a DVD multi-angle .vob file).

The most interesting file is vpar_synchro.c, it is really worth the shot. It explains the whole frame dropping algorithm. In a nutshell, if the machine is powerful enough, we decoder all IPBs, otherwise we decode all IPs and Bs if we have enough time (this is based on on-the-fly decoding time statistics). Another interesting file is vpar_blocks.c, which describes all block (including coefficients and motion vectors) parsing algorithms. Look at the bottom of the file, we indeed generate one optimized function for every common picture type, and one slow generic function. There are also several levels of optimization (which makes compilation slower but certain types of files faster decoded) called VPAR_OPTIM_LEVEL, level 0 means no optimization, level 1 means optimizations for MPEG-1 and MPEG-2 frame pictures, level 2 means optimizations for MPEG-1 and MPEG-2 field and frame pictures.


4.6.2. IDCT plug-ins

Just like motion compensation, IDCT is platform-specific. So we moved it to plugins/idct. This module does the IDCT calculation, and copies the data to the final picture. You need to define seven methods :

Currently we have implemented optimized versions for : MMX, MMXEXT, and AltiVec [doesn't work]. We have two plain C versions, the normal (supposedly optimized) Berkeley version (idct.c), and the simple 1-D separation IDCT from the ISO reference decoder (idctclassic.c).


Chapter 5. The video output layer

5.1. Data structures and main loop

Important data structures are defined in include/video.h and include/video_output.h. The main data structure is picture_t, which describes everything a video decoder thread needs. Please refer to this file for more information. Typically, p_data will be a pointer to YUV planar picture.

Note also the subpicture_t structure. In fact the VLC SPU decoder only parses the SPU header, and converts the SPU graphical data to an internal format which can be rendered much faster. So a part of the "real" SPU decoder lies in src/video_output/video_spu.c.

The vout_thread_t structure is much more complex, but you needn't understand everything. Basically the video output thread manages a heap of pictures and subpictures (5 by default). Every picture has a status (displayed, destroyed, empty...) and eventually a presentation time. The main job of the video output is an infinite loop to : [this is subject to change in the near future]

  1. Find the next picture to display in the heap.

  2. Find the current subpicture to display.

  3. Render the picture (if the video output plug-in doesn't support YUV overlay). Rendering will call an optimized YUV plug-in, which will also do the scaling, add subtitles and an optional picture information field.

  4. Sleep until the specified date.

  5. Display the picture (plug-in function). For outputs which display RGB data, it is often accomplished with a buffer switching. p_vout->p_buffer is an array of two buffers where the YUV transform takes place, and p_vout->i_buffer_index indicates the currently displayed buffer.

  6. Manage events.


5.2. Methods used by video decoders

The video output exports a bunch of functions so that decoders can send their decoded data. The most important function is vout_CreatePicture which allocates the picture buffer to the size indicated by the video decoder. It then just needs to feed (void *) p_picture->p_data with the decoded data, and call vout_DisplayPicture and vout_DatePicture upon necessary.


Chapter 6. The audio output layer


Appendix A. Ports

A.1. Port steps

Basically, porting to a new architecture boils down to follow the following steps :

  1. Building the VLC : That may be the most difficult part, depending on how POSIX the architecture is. You have to produce valid C.

  2. Having video : If your architecture features an X server, it should be straightforward, though you might have problems with xvideo or xshm. Otherwise you can try to use SDL if it is supported, or end up writing your own video output plugin.

  3. Having audio : If your architecture features an OSS compatible DSP or ALSA, you can reuse an existing plugin. Otherwise you will have to write your own audio output plugin.

  4. Accessing DVDs : You are going to need a write access to the DVD device. Every system has specific ioctl() for key negociation with the DVD drive, so we have set up an abstration layer in plugins/dvd/dvd_ioctl.c. You might need to add stuff here. Some operating systems won't give you access to the key negociation (MacOS X), so you will have to write a kernel extension or you will only be able to read unencrypted DVDs. Other operating systems might only give you read access to the DVD device if you are root. Your mileage may vary.

  5. Writing a native interface : If your system doesn't support GTK or Qt, you will have to write a native interface plugin (for instance Aqua or Win32). You may also need to rewrite the video output plugin if you're currently using a slow compatibility layer.

  6. Optimizing : If your architecture features a special set of multimedia instructions (such as MMX) that is not supported by VLC, you may want to write specific optimizations. Heavy calculation parts are : IDCT (see idct plugin), motion compensation (see motion plugin), and YUV (see video output) if you don't use the YUV overlay support of your video board (SDL or XVideo extension).


A.2. Building

This is probably the most complicated part. If your platform is fully POSIX-compliant (such as GNU/Linux), it should be quick, otherwise expect troubles. Known issues are :

VLC should work both on little endian and big endian systems. All load operations should be aligned on the native size of the type, so that it works on exotic processors like Sparc or Alpha. It should work on 64-bit platforms, though it has not been optimized for it. A big boost for them would be to have a WORD_TYPE = u64 in include/input_ext-dec.h, but it is currently broken for unknown reasons.

If you experience run-time problems, see the following appendix and pray for you to have gdb...


Appendix B. Advanced debugging

We never debug our code, because we don't put bugs in. Okay, you want some real stuff. Sam still uses printf() to find out where it crashes. For real programmers, here is a summary of what you can do if you have problems.


Appendix C. Project history

C.1. VIA and the Network2000 project

The whole project started back in 1995. At that time, students of the École Centrale de Paris enjoyed a TokenRing network, managed by the VIA Centrale Réseaux association, and were looking for a solution to upgrade to a modern network. So the idea behind Network2000 was to find a project students would realize that would be interesting, would require a high-quality network, and could provide enough fame so that sponsors would be interested.

Someone came up with the idea of doing television broadcast on the network, so that students could watch TV in their room. This was interesting, mixed a lot of cool technologies, and provided fame because no one had written a free MPEG-2 decoder so far.


C.2. Foundation of the VideoLAN project

3Com, Bouygues and la Société des Amis were interested and financed the project, which was then known after the name of VideoLAN.

The VideoLAN team, in particular Michel Lespinasse (current maintainer of LiViD's mpeg2dec) and Régis Duchesne, started writing code in 1996. By the end of 1997 they had a working client-server solution, but it would crash a lot and was hard to extend.

At that time it was still closed-source and only-for-demo code.


C.3. VideoLAN Client design

In 1998, Vincent Seguin (structure, interface and video output), Christophe Massiot (input and video decoder), Michel Kaempf (audio decoder and audio output) and Jean-Marc Dressler (synchronization) decided to write a brand new player from scratch, called VideoLAN Client (VLC), so that it could be easily open sourced. Of course we based it on code written by our predecessors, but in an advanced structure, described in the first chapter (it hasn't been necessary to change it a lot).

At the same time, Benoît Steiner started the writing of an advanced stream server, called VideoLAN Server (VLS).

Functional test seeds have been released internally in June 1999 (vlc-DR1) and November 1999 (vlc-DR2), and we started large scale tests and presentations. The French audience discovered us at Linux Expo in June 1999, presenting our 20 minutes of Golden Eye (which is now a legend among developers :-). At that time only a network input was possible, file input was added later, but it remained kludgy for a while.

In early 2000, we (especially Samuel Hocevar, who is still a major contributor) started working on DVDs (PS files, AC3, SPU). In the summer 2000, pre-release builds have been seeded (0.2.0 versions), but they still lacked essential features.

In late 2000, Christophe Massiot with the support of his company, IDEALX, rewrote major parts of the input to allow modularization and advanced navigation, and Stéphane Borel worked on a fully-featured DVD plug-in for VLC.


C.4. The Opening

For Linux Expo in February 2001, the Free Software Foundation and IDEALX wanted to make live streaming of the 2001 FSF awards from Paris to New York. VideoLAN was the chosen solution. Finally it couldn't be done live because of bandwidth considerations, but a chain of fully open-source solutions made it possible to record it.

At the same time, the president of the École Centrale Paris officially decided to place the software under GNU General Public Licence, thanks to Henri Fallon, Jean-Philippe Rey, and the IDEALX team.

VideoLAN software is now one of the most popular open source DVD players available, and has contributors all around the world. The last chapter of this appendix is not written yet :-).


Appendix D. GNU Free Documentation License

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.


3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.


4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.


10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.