DOCS/tech/: remove several obsolete files

Some of the files contain some usable stuff, but overall they're
obsolete enough that it's better to remove the current versions.

17 files changed, 0 insertions, 2544 deletions

diff --git a/DOCS/tech/TODO b/DOCS/tech/TODO
deleted file mode 100644
index cc3c3e2ef4..0000000000
--- a/DOCS/tech/TODO
+++ /dev/null
@@ -1,93 +0,0 @@
-TODO:
-=====
-
-SVN CLEANUP work:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- remove -vf yuy2, yvu9
-- change build & install stuff (cross-lib dependency etc)
-  - re-design makefile dependency system
-- start using the ffmpeg patch tracker (roundup)
-- check if these still matter & fix & apply the needed patches:
-  - MPlayer-0.90rc2.rawyuv.diff - raw YUV (I420) video 'encoder'
-    (checks requires for stride==width, and aligned planes)
-  - bte.diff - something input plugin (uses fork() )
-  - lavc_statsfile_errorchecking-patch - handle errors writing to logfile
-  - fastermemcpy.diff - cacheline-size dependent optimizations
-  - fire-x86-runtime-options.diff - en/disable (force) cpu features runtime
-    (needs to be integrated with --runtime-cpu-detection en/disabled modes)
-  - mga_vid_laced.diff - buggy interlace support into mga_vid
-  - patch_sortsub_disable-1.3x.diff - remove --disable-sortsub
-  - mplayer-0.90rc3-fixfbdev.patch - ugly hack to fix multiple file & -vo fbdev
-  - fix and apply dvd menu patches.
-- review and implement draw_slice() support in video filters
-- remove vidix/ and use external vidix
-
-FOR THE NEXT RELEASE:
-~~~~~~~~~~~~~~~~~~~~~~
-- fix vo_svga vs. -vf scale - DONE?
-- Re: [MPlayer-cvslog] CVS: main/libvo vo_vesa.c,1.82,1.83
-  This patch makes mplayer unusable in console mode, always leaves the
-  console in graphic mode.
-- Dec 19: [BUG] mencoder+mp3lame creates desynced AVI (<=22Khz support missing)
-- finish testing /old-incoming/ samples
-- fix partial -dr + ffmpeg + B frames (different stride per frame)
-- implementing 8bpp support in vo_x11.c
-- cleanup qtaudio/qtvideo (move globals to context)
-- cleanup DMO interfaces
-- Port GUI code to plain gtk without using X functions (any volunteers??? we really need help here)
-
-FOR THE v1.00 RELEASE:
-~~~~~~~~~~~~~~~~~~~~~~
-
-cruft removal:
-- remove support for skins directories using the obsolete name 'Skin'
-
-DVB:
-- display OSD and subtitles using DVB card's OSD
-
-avi demuxer: (needs rewrite)
-- implement hardcore bruteforce avi re-sync for broken files (-forceidx)
-- fix for growing avi files (movi_end pos > stream->end_pos)
-- implement forward seeking in avi streams with no index
-
-mencoder:
-- add ogg/vorbis audio encoder
-- stop/resume
-
-DOCS:
-- merge iive's XvMC docs into video.xml
-- enhance and merge the FAQ with the wiki FAQ
-- split man page into mplayer.1 and mencoder.1
-
-
-FUTURE:
-~~~~~~~
-
-demuxer:
-- demux_mpg: support for VDR's index files for more accurate seeking
-  - finish evo support
-- implement seeking for YUV4MPEG_2_
-
-decoders:
-- fix DLL loading problems
-  - vfw: pegasusm, pegasusl, pegasusmwv, 3ivX, alaris, vcr1, pim1, rricm, mvi1, mvi2
-  - dshow: morgands
-  - qtvideo and qtaudio: all crashing codecs
-    - update qt binary codec to latest version
-
-other:
-- dvd server
-- mga_vid crtc2 fix
-- X11 Render support into DGA for OSD (from the DOCS;)
-
-DOCS:
-- finish encoding for embedded devices howto
-
-stream:
-- native or nemesi rtsp support
-
-remove externals:
-- remove tremor when ffvorbis has integer-only decoder.
-- remove libmpeg2 when ffmpeg12 is faster
-- remove mp3lib when ffmp3 is faster
-- remove libfaad2 after soc aac is 100%
diff --git a/DOCS/tech/binary-packaging.txt b/DOCS/tech/binary-packaging.txt
deleted file mode 100644
index 6cc485ef2b..0000000000
--- a/DOCS/tech/binary-packaging.txt
+++ /dev/null
@@ -1,207 +0,0 @@
-                ________________________________________________
-                 How to make good binary package(s) of MPlayer?
-                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-                       by Dominik 'Rathann' Mierzejewski
-
-About this document
-~~~~~~~~~~~~~~~~~~~
-
-With the release of MPlayer 0.90pre9, all licensing issues have been
-eliminated and all code is licensed under the GPL, which allows
-independent packagers to create and distribute binary packages. At first,
-this was discouraged by some of the developers, but the users' demand for
-ready-to-use binary packages convinced some people to create them.
-Unfortunately, many currently available packages are crippled, include
-their own obsolete config files or are mispackaged in some other way. This
-document aims to establish a common set of packaging guidelines so that
-proper official binary packages for various Linux distributions and other
-operating systems can be maintained.
-
-
-Conventions
-~~~~~~~~~~~
-Whenever you see "MUST", it means that following the mentioned guideline
-is required. Whenever you see "SHOULD", it means that following the
-guideline is highly recommended, but not required.
-
-
-Minimum feature set
-~~~~~~~~~~~~~~~~~~~
-Due to MPlayer design, it is impossible to simply include all possible
-features and enable or disable them at runtime. That is why packagers
-SHOULD avoid "dependency hell" by retaining a reasonable, limited default
-feature set. After some discussion with other developers, we agreed that
-the following features MUST be included in any official binary package:
-
-* audio/video output
-  - fbdev
-  - JPEG/PNG/TGA
-  - (X)MGA
-  - OSS
-  - tdfxfb
-  - (c/x)vidix
-  - X11/Xvideo
-
-* codecs
-  - FAAD(internal)
-  - libavcodec(internal)
-  - native codecs (libmpeg2/mp3lib)
-  - Vorbis Tremor codec(internal)
-  - RealPlayer codecs support (*)
-  - Win32/VfW/DShow/QT codecs support (*)
-  - XAnim codecs support (*)
-
-* general:
-  - FreeType fonts support
-  - HTML documentation
-  - large file support
-  - man page(s)
-
-* input/demuxers:
-  - DVD(libdvdread4/libdvdnav)
-  - streaming
-  - Matroska(internal)
-  - (S)VCD
-  - tv(v4l/v4l2)
-
-(*) if available for your OS/hardware
-
-Including other features, like LIVE.COM streaming or JACK support, is
-acceptable. They SHOULD, however, be build-time configurable, with the
-default build configuration containing the above set.
-
-It seems there are some packages in the wild which lack included docs.
-This is VERY BAD, as it forces users to look for outside support when most
-of the common problems are easy to solve and are already described in the
-docs, thus increasing the number of repeated posts in MPlayer mailing
-lists. Binary packages MUST include both the man page and HTML
-documentation. Translated versions SHOULD be included, even if your
-package management system does not provide specific support for
-internationalization.
-
-Libavcodec MUST always be in the latest development version and it SHOULD
-be linked statically into the mplayer binary, because MPlayer requires a
-recent libavcodec snapshot. It is acceptable to use a shared (again, recent)
-version of libavcodec, but you must be aware that this disables some of
-MPlayer's functions (for example, some postprocessing filters) and sacrifices
-speed.
-
-Support for binary codecs SHOULD be present to the extent that the combination
-of operating system and CPU architecture permits, but it MUST NOT result in a
-hard dependency on a binary codecs package. MPlayer is fully functional without
-external binary codecs. If you package binary codecs yourself, package the
-essential codecs package, not the all codecs package.
-
-Bitmap fonts are deprecated, don't package them. Use scalable (Type1/TrueType)
-fonts instead.
-
-
-File locations
-~~~~~~~~~~~~~~
-In general, you SHOULD follow your distribution guidelines. For example,
-for Red Hat and Fedora RPMs I am using FHS-compliant paths:
-
-/etc/mplayer/                   system-wide configs
-/usr/bin/                       binaries
-/usr/lib/codecs/                binary codecs
-/usr/lib64/codecs/              binary codecs on 64bit Linux
-/usr/share/doc/mplayer-version/ docs
-/usr/share/man/man1/            man page
-/usr/share/man/XX/man1/         translated man page
-
-You MUST NOT include the codecs.conf file in your package. It is useful
-only for development purposes and often causes obscure problems for users.
-
-Please avoid using the deprecated paths for binary codecs (/usr/lib/win32/)
-and skins (/usr/share/mplayer/Skin/).
-
-
-One package or many packages?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Although it is tempting to simply provide a single all-in-one package,
-I think it is best to split MPlayer into several packages. It may be
-a little more troublesome for less clueful users, but it allows you to
-install only what you need. This is the layout I am using for Red Hat and
-Fedora RPMs:
-
-mencoder         contains MEncoder binary (mencoder)
-mplayer          contains MPlayer binary config files, man pages and
-                 documentation;
-mplayer-codecs-* contain binary codecs available from MPlayer's site
-
-There is no strict policy for now, just use your common sense.
-
-
-Compilation
-~~~~~~~~~~~
-While it is acceptable to provide packages optimized for specific CPUs,
-you MUST provide at least one "lowest common denominator" package set
-that will work on all CPUs. This means it MUST be configured with the
---enable-runtime-cpudetection option. Building for specific CPUs requires
-disabling this option, but try to make sure that users cannot accidentally
-install a package not suitable for their CPU. With RPMs, for example, this
-is handled automatically, when building with the "--target arch" rpm option.
-
-Compiler flags MUST be set to either configure-generated CFLAGS or something
-as close to them as possible.
-
-Users MUST be able to rebuild your source package without hand-editing on
-any system with the same distribution installed. Remember to disable
-(--disable-xxx) any optional features, because MPlayer's configure script
-autodetects most of them. This ensures that binary package builds are
-deterministic -- that is, provided they have at least the required
-development packages installed, two different people using the same
-distribution will get binaries with the same dependencies.
-
-You SHOULD provide an option to rebuild the package with full debug
-information enabled (by passing --enable-debug=3 to ./configure and
-disabling any stripping of binaries and libs during the build process).
-For example my source RPM can be rebuilt with a "--with debug" option, which
-does just that, making it easier to supply gdb information along with any
-bug reports, while retaining all benefits of using binary packages.
-
-
-Modifications
-~~~~~~~~~~~~~
-
-You MUST modify `mplayer -v` output so that it is clear that a user is
-using your binary package, by patching version.h and modifying the version
-string inside. Suggested convention is to include distribution name and,
-possibly, the signature of the packager or the repository. For example:
-
-original:
- MPlayer 1.0pre5-3.3.2 (C) 2000-2004 MPlayer Team
-modified:
- MPlayer 1.0pre5-Fedora-GS-3.3.2 (C) 2000-2004 MPlayer Team
- MPlayer 1.0pre5-Mandrake-PLF-3.2.3 (C) 2000-2004 MPlayer Team
- MPlayer 1.0pre5-Solaris-3.4.0 (C) 2000-2004 MPlayer Team
-
-If you patch MPlayer, send your patches to us! We will try to integrate them.
-Furthermore, we're often able to come up with a cleaner or more general
-solution to your problem.
-
-If you have modified configuration files or similar, please patch the official
-one instead of copying it into your package. This way you will automatically
-pick up changes we make to it.
-
-Do not override video and audio output selection in the system-wide config
-file. MPlayer will try to pick the best VO and AO itself and fall back
-gracefully. If you want to give priority to some AO, add a comma at the end
-of the line so that MPlayer can still fall back on others, for example:
-ao=alsa,
-
-Tips and tricks
-~~~~~~~~~~~~~~~
-To provide man pages for all MPlayer suite binaries (mplayer, mencoder), you
-can use man-links instead of regular symbolic links.
-Creating a mencoder man page linked to mplayer is as simple as:
-
-  echo ".so mplayer.1" >> mencoder.1
-
-A similar trick can be used for "man gmplayer". This avoids problems with
-gzipped man pages and symbolic links.
-
-Newer Red Hat and Fedora distributions keep localized man pages encoded in
-UTF-8. If your distribution does the same, make sure you convert MPlayer's
-translated man pages to UTF-8 so that man mplayer works for locales other
-than English.
diff --git a/DOCS/tech/code-documentation.txt b/DOCS/tech/code-documentation.txt
deleted file mode 100644
index 9213a79715..0000000000
--- a/DOCS/tech/code-documentation.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-Code documentation guidelines
-=============================
-
-About this guide
-----------------
-
-Due to the ever increasing complexity and size of MPlayer it became quite hard
-to maintain the code and add new features. Part of this problem is the lack
-of proper documentation what the code in question does and how it is doing it.
-To tackle this problem every part of MPlayer should follow these guidelines
-on what and how code should be documented.
-
-
-Doxygen
--------
-
-MPlayer uses doxygen for its code documentation. It generates HTML files
-which contain specially tagged comment lines from the code including
-cross references. To generate it type `make doxygen` in the source root
-directory. It will generate the files in DOCS/tech/doxygen. To clear them
-again, you can use `make doxygen_clean`.
-For further information about doxygen and its sources please have a look
-at their website: http://doxygen.sf.net
-
-
-What should be documented?
---------------------------
-
-- every function, no matter whether it is globally or just locally used
-  * what the function does
-  * all parameters and return values of the function and their valid ranges
-  * all side effects (to passed parameters, globals etc)
-  * all assumptions made within the function
-
-- global, file local and important variables
-  * what it is used for
-  * its valid range
-  * where it is set (optional)
-  * where validity checking is done (optional, mandatory for variables which
-    are set by something external, e.g. user parameters, file information etc)
-
-- #define, typedefs, structs
-  * all global definitions
-  * all local definitions whose use is not immediately clear by their name
-    (as a rule of thumb, it's better to document too much than not enough)
-  * all dependencies
-
-- non-trivial parts of the code
-  * tricky parts
-  * important parts
-  * special side effects
-  * assumptions of the code
-  * string operations and why they are safe
-
-- workarounds
- * why they are needed
- * how they work
- * what side effects they have
-
-If you are unsure whether a comment is needed or not, add one.
-
-
-How should it be documented?
-----------------------------
-
-All comments should be in correct and clear English. Any other language is
-not allowed. The language used should be kept simple as the code will be
-read mostly by non-native speakers. For function and variable documentation,
-a style usable by doxygen should be used. See section 3 "Documenting the code"
-of the doxygen manual for an introduction. A very short overview follows:
-
-Doxygen includes only special comments in the documentation, those are:
-
-/// This is a line used by doxygen.
-
-/** this one, too */
-
-/** these
-here
-of
-course,
-too */
-
-//! this form can be also used
-
-// This line isn't included in doxygen documentation.
-
-/* Neither is this. */
-
-Doxygen comments should come before the definition:
-
-/** description */
-int a_variable;
-
-However, you can use '<' to describe things AFTER they are defined, like this:
-
-int some_var; ///< description
-#define foo(x) (x + 2) /**< returns x plus 2 */
-
-There are a couple of special tags for doxygen:
-
-\brief <one line text>
-   Gives a brief description of a function.
-\param <parameter> <text>
-   Describes a specific <parameter>.
-\return <text>
-   Describes the return value.
-\a <word>
-   Mark next word as a reference to a parameter.
-\e <word>
-   Use italic font for the next word.
-\b <word>
-   Use bold font for the next word.
-\c <word>
-   Use typewriter font for the next word.
-\sa <references>
-   Adds a section with crossreferences.
-\bug <text>
-   Describe a known bug.
-\todo <text>
-   Add a todo list.
-\attention <text>
-   Add a section for something that needs attention.
-\warning <text>
-   Add a section for a warning.
-\anchor <refname>
-   Set an invisible anchor which can be used to create a link with \ref.
-\ref <refname> [<text>]
-   Add a link to <refname>.
-
-For a complete list of tags please read section 20 "Special commands" of the
-doxygen manual.
diff --git a/DOCS/tech/codec-devel.txt b/DOCS/tech/codec-devel.txt
deleted file mode 100644
index bc968c9499..0000000000
--- a/DOCS/tech/codec-devel.txt
+++ /dev/null
@@ -1,207 +0,0 @@
-A Guide To Developing MPlayer Codecs
-by Mike Melanson (melanson at pcisys dot net)
-updated to libmpcodecs arch by A'rpi
-
-SEE ALSO: libmpcodecs.txt !!!
-
-NOTE: If you want to implement a new native codec, please add it to
-libavcodec. libmpcodecs is considered mostly deprecated, except for wrappers
-around external libraries and codecs requiring binary support.
-
-Introduction
-------------
-I've developed a number of open source decoders for the MPlayer project,
-for both audio and video data. As such, I feel I'm qualified to document a
-few notes about developing new codecs for the codebase.
-
-As always, the best way to learn how to incorporate a new codec is to
-study a bunch of existing code. This document is supplementary material to
-the code, meant to give some tips, pointers, and a general roadmap.
-
-A note about terminology: "Codec" stands for coder/decoder (or
-compressor/decompressor, if you prefer). The term refers to a module that
-can both encode and decode data. However, this document focuses primarily
-on incorporating decoders. Still, the terms "decoder" and "codec" are
-often used interchangeably.
-
-Necessary Materials
--------------------
-So you've decided that you want to implement a new decoder for
-MPlayer. There are a few things you will need:
-
-- Knowledge of the codec to be implemented: You will need to know the data
-format of the chunks that MPlayer will pass to you. You will need to know
-how to take apart the data structures inside. You will need to know the
-algorithmic operations that need to be performed on the data in order to
-reconstruct the original media.
-
-- Sample media: Preferably, lots of it. You will need media encoded in
-your data format and stored in a media file format that MPlayer knows how
-to parse (these include AVI, ASF, MOV, RM, VIVO, among others). If the
-encoded data is stored in a media file format that MPlayer doesn't
-understand, then you will either need to somehow convert the format to a
-media file format that the program does understand, or write your own
-MPlayer file demuxer that can handle the data. Writing a file demuxer
-is beyond the scope of this document.
-        Try to obtain media that stresses all possible modes of a
-decoder. If an audio codec is known to work with both mono and stereo
-data, search for sample media of both types. If a video codec is known to
-work at 7 different bit depths, then, as painful as it may be, do what you
-can to obtain sample media encoded for each of the 7 bit depths.
-
-- Latest Subversion snapshot: It's always useful to develop code for the very
-latest development version of MPlayer. Be sure to update your local Subversion
-copy often.
-
-- General programming knowledge, working Linux development environment: I
-would hope that these items would go without saying, but you never know.
-
-Typical Development Cycle
--------------------------
-1) Set up basic infrastructure
-First things first, there's a big song and dance to go through in order to
-let the MPlayer program know that you have a new codec to incorporate.
-
-First, modify your local copy of codecs.conf. It may be system-shared or
-in your home directory. Add a new entry for your codec. If it's an open
-source codec, it would be a good idea to place the new entry with the rest
-of the open source codecs. When you're confident that you have the entry
-right, be sure to add it to etc/codecs.conf in your workspace. See the
-file codecs.conf.txt for a detailed description of the format of this
-file. Create a new audiocodec or videocodec block with the proper info,
-FOURCCs/format numbers, output formats, and a unique driver name. Remember
-the driver name.
-
-Next, create a new source file which contains the main decoding function
-that MPlayer will call to decode data. Eventually, you may have multiple
-files which comprise your decoder, but let's start simple here.
-For audio codecs, see ad_sample.c skeleton. For video, choose one of the
-existing vd_*.c files which you think is close to your codec in behaviour.
-
-Next, modify the Makefile so that it will compile your new source file.
-Also, add your codec to the array in ad.c (for audio) or vd.c (for video).
-
-Next, compile the project and see if you have everything correct so far.
-
-Next, you want to make sure that the encoded data is making it to your
-decoding function in the first place. This may sound like a trivial
-exercise, but there are a lot of things that can go wrong (and I've
-watched most of them go wrong in my experience). At the beginning of your
-skeleton decoder function, enter the following code:
-  int i;
-  for (i = 0; i < 16; i++)
-    printf ("%02X ", input[i]);
-  printf ("\n");
-When you compile and run MPlayer, your decoder function will print the
-first 16 bytes of each data chunk that it receives. Open the sample media
-in a hex editor and reconcile what you see on the screen with what
-you find in the file. If the decoder is printing the first 16 bytes of
-each block, that's a good sign that you're ready to move on to step
-2. Otherwise, you need to figure out why the data isn't getting to your
-decoder. Is your decoder even being invoked? If not, why not?
-
-2) Develop the decoder
-Go for it. Remember to make it work, first, then make it work fast. Some
-specific tips:
-
-What output formats should you support in your decoder? Whatever makes
-sense. YUV output is always preferable over RGB output. Generally, if a
-codec uses a YUV data as its source data, you will be able to decode a
-frame of YUV data. If a codec takes RGB data as its input, as many older
-video codecs do, then there's no point in supporting YUV output; just
-output as many RGB formats as possible.
-
-The most preferred output format for video data is YV12. This is because
-MPlayer supports a multitude of hardware devices that can display, scale,
-and filter this type of data directly. MPlayer also has a bunch of
-optimized conversion functions that can convert YV12 data to any other
-type of output data.
-
-If you do take the RGB output route, you should be aware that MPlayer
-actually orders packed RGB data as BGR. If you're decoding into a BGR24
-buffer, the output will look like:
-  B G R B G R B G R B ...
-If you're decoding into a BGR32 buffer, there will need to be an
-additional (unused) byte after each BGR triplet:
-  B G R - B G R - B G ...
-
-Make liberal use of sanity checks. Start by including the file mp_msg.h at
-the start of your decoder. Then you can use the mp_msg() function as you
-would a normal printf() statement. Whenever your decoder notices a strange
-bit of data or an odd condition, print a message such as:
-  mp_msg(MSGT_DECVIDEO, MSGL_WARN, "Odd data encountered: %d\n", data);
-Obviously, you should make the message a little more
-descriptive, for your benefit. MSGL_WARN is a good message level for this
-type of information. Look in mp_msg.h for all of the error levels. You can
-even make MPlayer bail out completely by using MSGL_FATAL, but that should
-never be necessary at the data decoder level.
-
-What conditions should trigger a warning? Anything, and I mean *anything*
-out of the ordinary. Many chunks of compressed video data contain headers
-with data such as width, height, and chunk size. Reconcile these fields
-with the parameters passed into the decoding function (if you set it up to
-take those parameters). Such data should match up. If it doesn't, issue a
-warning and make an executive decision in the code about which data to
-believe (personally, I always lend more weight to the data that was passed
-into the decoder function, than the data that comes from the container file's
-header). If there's supposed to be a magic number embedded in, or computed
-from, the chunk's header, issue a warning if it isn't correct.
-
-Whenever you're about the index into a memory array with an index that
-could theoretically be out of range, then test that the index is in range,
-no matter how tedious it seems. Accessing outside of your memory range is,
-after all, the number 1 cause of segmentation faults. Never trust that all
-the data passed to you will be correct. If an array index suddenly winds
-up out of range, it's probably best to issue a warning about it and bail
-out of the decoder (but not the whole application).
-
-Writing all of these warning statements may seem insipid, but consider
-that if you don't do it when you start writing your decoder, you'll
-probably end up doing it later on when your decoder isn't working properly
-and you need to figure out why (believe me, I know).
-
-3) Debug and test the decoder
-If you're extremely lucky, the decoder will work the first time. If you're
-very lucky, it will work after you've reviewed your code a few times and
-corrected a few obvious programming mistakes. Realistically, you will
-write the decoder, review it many times and fix many obvious and subtle
-programming errors, and still have to go through an elaborate debug
-process in order to get the decoder to a minimally functional state.
-
-Big hint: Ask for all warnings. You know, the -Wall option in
-gcc? It's very useful to develop your codec while running in debug
-mode. In order to compile MPlayer with debug support (which includes -Wall
-for all gcc operations), use the --enable-debug option when configuring
-the project. Pay attention to all warnings and make it a goal to get
-rid of every single one. I'll never forget when the compiler warned me
-that there was no point in clamping a signed 16-bit variable within a
-signed 16-bit range (the calculation to be clamped was supposed to be
-stored in a signed 32-bit variable and then stored in the signed 16-bit
-variable). I sat stunned for a moment, feeling like I had just dodged a
-bullet as I knew that would have taken me hours to debug that kind of
-mistake.
-
-4) Contribute decoder to codebase
-Create a patch with the "diff -u" format and email it to the MPlayer
-development team for approval. You will likely need to diff the following
-files:
-- Makefile
-- etc/codecs.conf
-- ad.c or vd.c
-Of course, you will need to include your newly-created file(s):
-vd_<name>.c -OR- ad_<name>.c. If you contribute enough decoders, the
-development team may even grant you write privileges to the Subversion
-repository.
-
-5) Wait for bug reports to start rolling in
-You may think you're finished when you release the codec and if you're
-extremely lucky, you will be right. However, it's more likely that people
-will start throwing all kinds of oddball media at your decoder that it
-never counted on. Cheer up; take comfort in knowing that people are
-testing your code and attempting to use it as a real world
-application. Download the problem media that people upload to the MPlayer
-FTP site and get back to work, implementing fixed code that addresses the
-issues. Contribute more patches and encourage people to hammer on your
-decoder even more. This is how you make your decoder rock-solid.
-
-EOF
diff --git a/DOCS/tech/dvdnav-howto.txt b/DOCS/tech/dvdnav-howto.txt
deleted file mode 100644
index 4bba42d975..0000000000
--- a/DOCS/tech/dvdnav-howto.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-How to compile MPlayer with support for dvdnav:
-
-Since the versions of dvdnav and dvdread generally shipped with most Linux
-distributions are outdated and unmaintained remove any traces of dvdnav and
-dvdread from your computer (something like the command below should suffice):
-$ rm -rf /usr/lib/libdvdnav* /usr/lib/libdvdread* /usr/include/dvdnav* \
-         /usr/include/dvdread* /usr/local/lib/libdvdnav* \
-         /usr/local/lib/libdvdread* /usr/local/include/dvdnav* \
-         /usr/local/include/dvdread* /usr/bin/dvdnav-config \
-         /usr/local/bin/dvdnav-config
-
-Now download dvdnav from MPHQ libdvdread and libdvdnav (in this order) :
-$ svn co svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread libdvdread
-$ cd libdvdread
-$ ./autogen.sh && ./configure && make
-(or, if you feel brave and want to help us improve the new build system)
-$ ./configure2 && make
-install it as root with
-$ make install
-
-$ svn co svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdnav libdvdnav
-$ cd libdvdnav
-$ ./autogen.sh && ./configure && make
-(or, if you feel brave and want to help us improve the new build system)
-$ ./configure2 && make
-install it as root with
-$ make install
-
-From within the MPlayer source tree run
-$ ./configure --disable-dvdread-internal
-followed by your preferred parameters.
-Be warned that you *MUST* disable MPlayer's internal copy of dvdread or something
-- most likely - won't work as expected (if at all).
-After configure is run it should say that support for dvdnav and dvdread was
-enabled. If not, investigate the dvdnav and dvdread sections in config.log
-and try to understand what went wrong. If you can't solve the problem yourself
-post the two sections to mplayer-users.
-
-Notice: Audio and subtitle language selection by means of menus doesn't work yet.
-Nonetheless they can be switched as usual at any time during
-playback by pressing '#' and 'j' (or the keys you chose to override those two
-bindings).
diff --git a/DOCS/tech/encoding-guide.txt b/DOCS/tech/encoding-guide.txt
deleted file mode 100644
index 0393bcbb5f..0000000000
--- a/DOCS/tech/encoding-guide.txt
+++ /dev/null
@@ -1,138 +0,0 @@
-Topics:
-
-
-I. Preparing to encode
-   1. Identifying source material and framerate
-   2. Selecting the quality you want
-   3. Constraints for efficient encoding
-   4. Cropping and scaling
-   5. Choosing resolution and bitrate
-
-II. Containers and codecs
-   1. Where the movie will be played
-   2. Constraints of DVD, SVCD, and VCD
-   3. Limitations of AVI container
-
-III. Basic MEncoder usage
-   1. Selecting codecs & format
-   2. Selecting input file or device
-   3. Loading video filters
-   4. Notes on A/V sync
-
-IV. Encoding procedures
-   1. Encoding progressive video
-   2. Two-pass encoding
-   3. Encoding interlaced video
-   4. Deinterlacing
-   5. Inverse telecine
-   6. Capturing TV input
-   7. Dealing with mixed-source content
-   8. Low-quality & damaged sources
-
-V. Optimizing encoding quality
-   1. Noise removal
-   2. Pure quality-gain options
-   3. Questionable-gain options
-   4. Advanced MPEG-4 features
-
-
-
-
-II. Containers and codecs
-
-II.1. Where the movie will be played
-
-Perhaps the most important factor to choosing the format in which you
-will encode your movie is where you want to be able to play it.
-Usually this involves a tradeoff between quality and features, since
-the formats supported by the widest variety of players are also the
-worst in regards to compression.
-
-If you want to be able to play your encode on standalone/set-top
-players, your primary choices are DVD, VCD, and SVCD. There are also
-extensions such as KVCD and XVCD which violate the standards but work
-on many players and deliver higher quality. Modern players are
-beginning to support MPEG-4 ("DivX") movies in AVI and perhaps other
-containers as well, but these are often buggy and require you to
-restrict your encodes to certain subsets of the full MPEG-4
-functionality.
-
-If you wish to be able to share your movies with Windows or Macintosh
-users, without them having to install additional software, your
-choices are very limited. The ancient MPEG-1 format with MP2 or PCM
-audio is probably the only choice that is universally supported.
-Interoperability with Windows/Mac also comes into play when deciding
-how to encode and whether to scale to preserve aspect, since popular
-media player applications for these systems do not honor the aspect
-ratio encoding stored in MPEG-4 avi files.
-
-
-
-IV.2. Two-pass encoding
-
-The complexity (and thus the number of bits) required to compress the
-frames of a movie can vary greatly from one scene to another. Modern
-video encoders can adjust to these needs as they go and vary the
-bitrate. However, they cannot exceed the requested average bitrate for
-long stretches of time, because they do not know the bit