mirror of
https://github.com/mpv-player/mpv
synced 2025-03-03 04:37:54 +00:00
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.
This commit is contained in:
Uoti Urpala
parent
7c87946c69
commit
f6fb536f87
@ -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%
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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
|
||||
@ -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).
|
||||
@ -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 bitrate needs of
|
||||
future scenes.
|
||||
|
||||
Two-pass encoding solves this problem by encoding the movie twice.
|
||||
During the first pass, statistics are generated regarding the number
|
||||
of bits used by each frame and the quantization level (quality) at
|
||||
which it was encoded. Then, when the second pass begins, the encoder
|
||||
reads these statistics and redistributes the bits from frames where
|
||||
they are in excess to frames that are suffering from low quality.
|
||||
|
||||
In order for the process to work properly, the encoder should be given
|
||||
exactly the same sequence of frames during both passes. This means
|
||||
that the same filters must be used, the same encoder parameters must
|
||||
be used (with the possible exception of bitrate), and the same frame
|
||||
drops and duplications (if any) must take place.
|
||||
|
||||
In theory it's possible to use -oac pcm or -oac copy during the first
|
||||
pass to avoid spending time encoding the audio. However, this can
|
||||
result in slight variations in which frames get dropped or duplicated,
|
||||
so it may be preferable to encode the audio during the first pass as
|
||||
well as the second. This also allows you to examine the final audio
|
||||
bitrate and filesize, and to adjust the audio or video bitrate
|
||||
slightly between passes if you don't meet your target size.
|
||||
|
||||
Here is an example:
|
||||
|
||||
Encoding from an existing AVI file
|
||||
500 kbit/sec MPEG-4 video
|
||||
96 kbit/sec average-bitrate MP3 audio
|
||||
|
||||
mencoder bar.avi -vf scale=448:336 -mc 0 -oac mp3lame -lameopts \
|
||||
abr:br=96 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=500:vpass=1
|
||||
|
||||
mencoder bar.avi -vf scale=448:336 -mc 0 -oac mp3lame -lameopts \
|
||||
abr:br=96 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=500:vpass=2
|
||||
|
||||
If you do not want to overwrite the output from the first pass when
|
||||
you begin the second, you can use the -o option to choose a different
|
||||
output filename. Note the addition of the vpass option in this
|
||||
example. If vpass is not specified, single-pass encoding is performed.
|
||||
If vpass=1, a log file is written with statistics from the first pass.
|
||||
If vpass=2, the log file is read and the second pass is encoded based
|
||||
on those statistics. If you are short on disk space or don't want the
|
||||
extra disk wear from writing the file twice, you can use -o /dev/null
|
||||
during the first pass. However, sometimes it is beneficial to watch
|
||||
the first-pass file before beginning the second pass to make sure
|
||||
nothing went wrong in the encoding.
|
||||
|
||||
Next, an example using Xvid instead of libavcodec:
|
||||
|
||||
Encoding from an existing AVI file
|
||||
500 kbit/sec MPEG-4 video
|
||||
Copying the existing audio stream unmodified
|
||||
|
||||
mencoder foo.avi -vf scale=320:240 -mc 0 -oac copy -ovc xvid \
|
||||
-xvidencopts bitrate=400:pass=1
|
||||
|
||||
mencoder foo.avi -vf scale=320:240 -mc 0 -oac copy -ovc xvid \
|
||||
-xvidencopts bitrate=400:pass=2
|
||||
|
||||
The options used are slightly different, but the process is otherwise
|
||||
the same.
|
||||
@ -1,725 +0,0 @@
|
||||
|
||||
Some important URLs:
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
http://mplayerhq.hu/~michael/codec-features.html <- lavc vs. divx5 vs. xvid
|
||||
http://www.ee.oulu.fi/~tuukkat/mplayer/tests/rguyom.ath.cx/ <- lavc benchmarks, options
|
||||
http://ffdshow.sourceforge.net/tikiwiki/tiki-view_articles.php <- lavc for win32 :)
|
||||
http://www.bunkus.org/dvdripping4linux/index.html <- a nice tutorial
|
||||
http://forum.zhentarim.net/viewtopic.php?p=237 <- lavc option comparison
|
||||
http://www.ee.oulu.fi/~tuukkat/mplayer/tests/readme.html <- series of benchmarks
|
||||
http://thread.gmane.org/gmane.comp.video.mencoder.user/1196 <- free codecs shoutout and recommended encoding settings
|
||||
|
||||
|
||||
================================================================================
|
||||
|
||||
|
||||
FIXING A/V SYNC WHEN ENCODING
|
||||
|
||||
I know this is a popular topic on the list, so I thought I'd share a
|
||||
few comments on my experience fixing a/v sync. As everyone seems to
|
||||
know, mencoder unfortunately doesn't have a -delay option. But that
|
||||
doesn't mean you can't fix a/v sync. There are a couple ways to still
|
||||
do it.
|
||||
|
||||
In example 1, we'll suppose you want to re-encode the audio anyway.
|
||||
This will be essential if your source audio isn't mp3, e.g. for DVD's
|
||||
or nasty avi files with divx/wma audio. This approach makes things
|
||||
much easier.
|
||||
|
||||
Step 1: Dump the audio with mplayer -ao pcm -nowaveheader. There are
|
||||
various options that can be used to speed this up, most notably -vo
|
||||
null, -vc null, and/or -hardframedrop. -benchmark also seemed to help
|
||||
in the past. :)
|
||||
|
||||
Step 2: Figure out what -delay value syncs the audio right in mplayer.
|
||||
If this number is positive, use a command like the following:
|
||||
|
||||
dd if=audiodump.wav bs=1764 skip=[delay] | lame -x - out.mp3
|
||||
|
||||
where [delay] is replaced by your delay amount in hundredths of a
|
||||
second (1/10 the value you use with mplayer). Otherwise, if delay is
|
||||
negative, use a command like this:
|
||||
|
||||
( dd if=/dev/zero bs=1764 skip=[delay] ; cat audiodump.wav ) | lame -x - out.mp3
|
||||
|
||||
Don't include the minus (-) sign in delay. Also, keep in mind you'll
|
||||
have to change the 1764 number and provide additional options to lame
|
||||
if your audio stream isn't 44100/16bit/little-endian/stereo.
|
||||
|
||||
Step 3: Use mencoder to remux your new mp3 file with the movie:
|
||||
|
||||
mencoder -audiofile out.mp3 -oac copy ...
|
||||
|
||||
You can either copy video as-is (with -ovc copy) or re-encode it at
|
||||
the same time you merge in the audio like this.
|
||||
|
||||
Finally, as a variation on this method (makes things a good bit faster
|
||||
and doesn't use tons of temporary disk space) you can merge steps 1
|
||||
and 2 by making a named pipe called "audiodump.wav" (type mkfifo
|
||||
audiodump.wav) and have mplayer write the audio to it at the same time
|
||||
you're running lame to encode.
|
||||
|
||||
Now for example 2. This time we won't re-encode audio at all. Just
|
||||
dump the mp3 stream from the avi file with mplayer -dumpaudio. Then,
|
||||
you have to cut and paste the raw mp3 stream a bit...
|
||||
|
||||
If delay is negative, things are easier. Just use lame to encode
|
||||
silence for the duration of delay, at the same samplerate and
|
||||
samplesize used in your avi file. Then, do something like:
|
||||
|
||||
cat silence.mp3 stream.dump > out.mp3
|
||||
mencoder -audiofile out.mp3 -oac copy ...
|
||||
|
||||
On the other hand, if delay is positive, you'll need to crop off part
|
||||
of the mp3 from the beginning. If it's (at least roughly) CBR this is
|
||||
easy -- just take off the first (bitrate*delay/8) bytes of the file.
|
||||
You can use the excellent dd tool, or just your favorite
|
||||
binary-friendly text editor to do this. Otherwise, you'll have to
|
||||
experiment with cutting off different amounts. You can test with
|
||||
mplayer -audiofile before actually spending time remuxing/encoding
|
||||
with mencoder to make sure you cut the right amount.
|
||||
|
||||
I hope this has all been informative. If anyone would like to clean
|
||||
this message up a bit and make it into part of the docs, feel free. Of
|
||||
course mencoder should eventually just get -delay. :)
|
||||
|
||||
Rich
|
||||
|
||||
|
||||
================================================================================
|
||||
|
||||
|
||||
ENCODING QUALITY - OR WHY AUTOMATISM IS BAD.
|
||||
|
||||
Hi everyone.
|
||||
|
||||
Some days ago someone suggested adding some preset options to mencoder.
|
||||
At that time I replied 'don't do that', and now I decided to elaborate
|
||||
on that.
|
||||
|
||||
Warning: this is rather long, and it involves mathematics. But if you
|
||||
don't want to bother with either then why are you encoding in the
|
||||
first place? Go do something different!
|
||||
|
||||
The good news is: it's all about the bpp (bits per pixel).
|
||||
|
||||
The bad news is: it's not THAT easy ;)
|
||||
|
||||
This mail is about encoding a DVD to MPEG4. It's about the video
|
||||
quality, not (primarily) about the audio quality or some other fancy
|
||||
things like subtitles.
|
||||
|
||||
The first step is to encode the audio. Why? Well if you encode the
|
||||
audio prior to the video you'll have to make the video fit onto one
|
||||
(or two) CD(s). That way you can use oggenc's quality based encoding
|
||||
mode which is much more sophisticated than its ABR based mode.
|
||||
|
||||
After encoding the audio you have a certain amount of space left to
|
||||
fill with video. Let's assume the audio takes 60M (no problem with
|
||||
Vorbis), and you aim at a 700M CD. This leaves you 640M for the video.
|
||||
Let's further assume that the video is 100 minutes or 6000 seconds
|
||||
long, encoded at 25fps (those nasty NTSC fps values give me
|
||||
headaches. Adjust to your needs, of course!). This leaves you with
|
||||
a video bitrate of:
|
||||
|
||||
$videosize * 8
|
||||
$videobitrate = --------------
|
||||
$length * 1000
|
||||
|
||||
$videosize in bytes, $length in seconds, $videobitrate in kbit/s.
|
||||
In my example I end up with $videobitrate = 895.
|
||||
|
||||
And now comes the question: how do I chose my encoding parameters
|
||||
so that the results will be good? First let's take a look at a
|
||||
typical mencoder line:
|
||||
|
||||
mencoder dvd://1 -o /dev/null -oac copy -ovc lavc \
|
||||
-lavcopts vcodec=mpeg4:vbitrate=1000:vhq:vqmin=2:\
|
||||
vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:vpass=1 \
|
||||
-vf crop=716:572:2:2,scale=640:480
|
||||
|
||||
Phew, all those parameters! Which ones should I change? NEVER leave
|
||||
out 'vhq'. Never ever. 'vqmin=2' is always good if you aim for sane
|
||||
settings - like 'normal length' movies on one CD, 'very long movies'
|
||||
on two CDs and so on. vcodec=mpeg4 is mandatory.
|
||||
|
||||
The 'vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01' are parameters
|
||||
suggested by D Richard Felker for non-animated movies, and they
|
||||
improve quality a bit.
|
||||
|
||||
But the two things that have the most influence on quality are
|
||||
vbitate and scale. Why? Because both together tell the codec how
|
||||
many bits it may spend on each frame for each bit: and this is
|
||||
the 'bpp' value (bits per pixel). It's simply defined as
|
||||
|
||||
$videobitrate * 1000
|
||||
$bpp = -----------------------
|
||||
$width * $height * $fps
|
||||
|
||||
I've attached a small Perl script that calculates the $bpp for
|
||||
a movie. You'll have to give it four parameters:
|
||||
a) the cropped but unscaled resolution (use '-vf cropdetect'),
|
||||
b) the encoded aspect ratio. All DVDs come at 720x576 but contain
|
||||
a flag that tells the player wether it should display the DVD at
|
||||
an aspect ratio of 4/3 (1.333) or at 16/9 (1.777). Have a look
|
||||
at mplayer's output - there's something about 'prescaling'. That's
|
||||
what you are looking for.
|
||||
c) the video bitrate in kbit/s and
|
||||
d) the fps.
|
||||
|
||||
In my example the command line and calcbpp.pl's output would look
|
||||
like this (warning - long lines ahead):
|
||||
|
||||
mosu@anakin:~$ ./calcbpp.pl 720x440 16/9 896 25
|
||||
Prescaled picture: 1023x440, AR 2.33
|
||||
720x304, diff 5, new AR 2.37, AR error 1.74% scale=720:304 bpp: 0.164
|
||||
704x304, diff -1, new AR 2.32, AR error 0.50% scale=704:304 bpp: 0.167
|
||||
688x288, diff 8, new AR 2.39, AR error 2.58% scale=688:288 bpp: 0.181
|
||||
672x288, diff 1, new AR 2.33, AR error 0.26% scale=672:288 bpp: 0.185
|
||||
656x288, diff -6, new AR 2.28, AR error 2.17% scale=656:288 bpp: 0.190
|
||||
640x272, diff 3, new AR 2.35, AR error 1.09% scale=640:272 bpp: 0.206
|
||||
624x272, diff -4, new AR 2.29, AR error 1.45% scale=624:272 bpp: 0.211
|
||||
608x256, diff 5, new AR 2.38, AR error 2.01% scale=608:256 bpp: 0.230
|
||||
592x256, diff -2, new AR 2.31, AR error 0.64% scale=592:256 bpp: 0.236
|
||||
576x240, diff 8, new AR 2.40, AR error 3.03% scale=576:240 bpp: 0.259
|
||||
560x240, diff 1, new AR 2.33, AR error 0.26% scale=560:240 bpp: 0.267
|
||||
544x240, diff -6, new AR 2.27, AR error 2.67% scale=544:240 bpp: 0.275
|
||||
528x224, diff 3, new AR 2.36, AR error 1.27% scale=528:224 bpp: 0.303
|
||||
512x224, diff -4, new AR 2.29, AR error 1.82% scale=512:224 bpp: 0.312
|
||||
496x208, diff 5, new AR 2.38, AR error 2.40% scale=496:208 bpp: 0.347
|
||||
480x208, diff -2, new AR 2.31, AR error 0.85% scale=480:208 bpp: 0.359
|
||||
464x192, diff 7, new AR 2.42, AR error 3.70% scale=464:192 bpp: 0.402
|
||||
448x192, diff 1, new AR 2.33, AR error 0.26% scale=448:192 bpp: 0.417
|
||||
432x192, diff -6, new AR 2.25, AR error 3.43% scale=432:192 bpp: 0.432
|
||||
416x176, diff 3, new AR 2.36, AR error 1.54% scale=416:176 bpp: 0.490
|
||||
400x176, diff -4, new AR 2.27, AR error 2.40% scale=400:176 bpp: 0.509
|
||||
384x160, diff 5, new AR 2.40, AR error 3.03% scale=384:160 bpp: 0.583
|
||||
368x160, diff -2, new AR 2.30, AR error 1.19% scale=368:160 bpp: 0.609
|
||||
352x144, diff 7, new AR 2.44, AR error 4.79% scale=352:144 bpp: 0.707
|
||||
336x144, diff 0, new AR 2.33, AR error 0.26% scale=336:144 bpp: 0.741
|
||||
320x144, diff -6, new AR 2.22, AR error 4.73% scale=320:144 bpp: 0.778
|
||||
|
||||
A word for the $bpp. For a fictional movie which is only black and
|
||||
white: if you have a $bpp of 1 then the movie would be stored
|
||||
uncompressed :) For a real life movie with 24bit color depth you
|
||||
need compression of course. And the $bpp can be used to make the
|
||||
decision easier.
|
||||
|
||||
As you can see the resolutions suggested by the script are all
|
||||
dividable by 16. This will make the aspect ratio slightly wrong,
|
||||
but no one will notice.
|
||||
|
||||
Now if you want to decide which resolution (and scaling parameters)
|
||||
to chose you can do that by looking at the $bpp:
|
||||
|
||||
< 0.10: don't do it. Please. I beg you!
|
||||
< 0.15: It will look bad.
|
||||
< 0.20: You will notice blocks, but it will look ok.
|
||||
< 0.25: It will look really good.
|
||||
> 0.25: It won't really improve visually.
|
||||
> 0.30: Don't do that either - try a bigger resolution instead.
|
||||
|
||||
Of course these values are not absolutes! For movies with really lots
|
||||
of black areas 0.15 may look very good. Action movies with only high
|
||||
motion scenes on the other hand may not look perfect at 0.25. But these
|
||||
values give you a great idea about which resolution to chose.
|
||||
|
||||
I see a lot of people always using 512 for the width and scaling
|
||||
the height accordingly. For my (real-world-)example this would be
|
||||
simply a waste of bandwidth. The encoder would probably not even
|
||||
need the full bitrate, and the resulting file would be smaller
|
||||
than my targetted 700M.
|
||||
|
||||
After encoding you'll do your 'quality check'. First fire up the movie
|
||||
and see whether it looks good to you or not. But you can also do a
|
||||
more 'scientific' analysis. The second Perl script I attached counts
|
||||
the quantizers used for the encoding. Simply call it with
|
||||
|
||||
countquant.pl < divx2pass.log
|
||||
|
||||
It will print out which quantizer was used how often. If you see that
|
||||
e.g. the lowest quantizer (vqmin=2) gets used for > 95% of the frames
|
||||
then you can safely increase your picture size.
|
||||
|
||||
> The "counting the quantesizer"-thing could improve the quality of
|
||||
> full automated scripts, as I understand ?
|
||||
|
||||
Yes, the log file analysis can be used be tools to automatically adjust
|
||||
the scaling parameters (if you'd do that you'd end up with a three-pass
|
||||
encoding for the video only ;)), but it can also provide answers for
|
||||
you as a human. From time to time there's a question like 'hey,
|
||||
mencoder creates files that are too small! I specified this bitrate and
|
||||
the resulting file is 50megs short of the target file size!'. The
|
||||
reason is probably that the codec already uses the minimum quantizer
|
||||
for nearly all frames so it simply does not need more bits. A quick
|
||||
glance at the distribution of the quantizers can be enlightening.
|
||||
|
||||
Another thing is that q=2 and q=3 look really good while the 'bigger'
|
||||
quantizers really lose quality. So if your distribution shows the
|
||||
majority of quantizers at 4 and above then you should probably decrease
|
||||
the resolution (you'll definitly see block artefacts).
|
||||
|
||||
|
||||
Well... Several people will probably disagree with me on certain
|
||||
points here, especially when it comes down to hard values (like the
|
||||
$bpp categories and the percentage of the quantizers used). But
|
||||
the idea is still valid.
|
||||
|
||||
And that's why I think that there should NOT be presets in mencoder
|
||||
like the presets lame knows. 'Good quality' or 'perfect quality' are
|
||||
ALWAYS relative. They always depend on a person's personal preferences.
|
||||
If you want good quality then spend some time reading and - more
|
||||
important - understanding what steps are involved in video encoding.
|
||||
You cannot do it without mathematics. Oh well, you can, but you'll
|
||||
end up with movies that could certainly look better.
|
||||
|
||||
Now please shoot me if you have any complaints ;)
|
||||
|
||||
--
|
||||
==> Ciao, Mosu (Moritz Bunkus)
|
||||
|
||||
===========
|
||||
ANOTHER APPROACH: BITS PER BLOCK:
|
||||
|
||||
> $videobitrate * 1000
|
||||
> $bpp = -----------------------
|
||||
> $width * $height * $fps
|
||||
|
||||
Well, I came to similar equation going through different route. Only I
|
||||
didn't use bits per pixel, in my case it was bits per block (BPB). The block
|
||||
is 16x16 because lots of software depends on video width/height being
|
||||
divisable by 16. And because I didn't like this 0.2 bit per pixel, when
|
||||
bit is quite atomic ;)
|
||||
|
||||
So the equation was something like:
|
||||
|
||||
bitrate
|
||||
bpb = -----------------
|
||||
fps * ((width * height) / (16 * 16))
|
||||
|
||||
(width and height are from destination video size, and bitrate is in
|
||||
bits (i.e. 900kbps is 900000))
|
||||
|
||||
This way it apeared that the minimum bits per block is ~40, very
|
||||
good results are with ~50, and everything above 60 is a waste of bandwidth.
|
||||
And what's actually funny is that it was independent of codec used. The
|
||||
results were exactly the same, whether I used DIV3 (with tricky nandub's
|
||||
magick), ffmpeg odivx, DivX5 on Windows or Xvid.
|
||||
|
||||
Surprisingly there is one advantage of using nandub-DIV3 for bitrate
|
||||
starved encoding: ringing almost never apears this way.
|
||||
|
||||
But I also found out, that the quality/BPB isn't constant for
|
||||
drastically different resolutions. Smaller picture (like MPEG1 sizes)
|
||||
need more BPB to look good than say typical MPEG2 resolutions.
|
||||
|
||||
Robert
|
||||
|
||||
|
||||
===========
|
||||
DON'T SCALE DOWN TOO MUCH
|
||||
|
||||
Sometimes I found that encoding to y-scaled only DVD qualty (ie 704 x
|
||||
288 for a 2.85 film) gives better visual quality than a scaled-down
|
||||
version even if the quantizers are significantly higher than for the
|
||||
scaled-down version.
|
||||
Keep in mind that blocs, fuzzy parts and generaly mpeg artefacts in a
|
||||
704x288 image will be harder to spot in full-screen mode than on a
|
||||
512x208 image. In fact I've see example where the same movie looks
|
||||
better compressed to 704x288 with an average weighted quantizer of
|
||||
~3 than the same movie scaled to 576x240 with an average weighted
|
||||
quantizer of 2.4.
|
||||
Btw, a print of the weighted average quantizer would be nice in
|
||||
countquant.pl :)
|
||||
|
||||
Another point in favor of not trying to scale down too much : on hard
|
||||
scaled-down movies, the MPEG codec will need to compress relatively
|
||||
high frequencies rather than low frequencies and it doesn't like that
|
||||
at all. You will see less and less returns while you scale down and
|
||||
scale down again in desesperate need of some bandwidth :)
|
||||
|
||||
In my experience, don't try to go below a width of 576 without closely
|
||||
watching what's going on.
|
||||
|
||||
--
|
||||
Rémi
|
||||
|
||||
===========
|
||||
TIPS FOR ENCODING
|
||||
|
||||
That being said, with video you have some tradeoffs you can make. Most
|
||||
people seem to encode with really basic options, but if you play with
|
||||
single coefficient elimination and luma masking settings, you can save lots
|
||||
of bits, resulting in lower quantizers, which means less blockiness and
|
||||
less ugly noise (ringing) around sharp borders. The tradeoff, however, is
|
||||
that you'll get some "muddiness" in some parts of the image. Play around
|
||||
with the settings and see for yourself. The options I typically use for
|
||||
(non-animated) movies are:
|
||||
|
||||
vlelim=-4
|
||||
vcelim=9
|
||||
lumi_mask=0.05
|
||||
dark_mask=0.01
|
||||
|
||||
If things look too muddy, making the numbers closer to 0. For anime and
|
||||
other animation, the above recommendations may not be so good.
|
||||
|
||||
Another option that may be useful is allowing four motion vectors per
|
||||
macroblock (v4mv). This will increase encoding time quite a bit, and
|
||||
last I checked it wasn't compatible with B frames. AFAIK, specifying
|
||||
v4mv should never reduce quality, but it may prevent some old junky
|
||||
versions of DivX from decoding it (can anyone conform?). Another issue
|
||||
might be increased cpu time needed for decoding (again, can anyone
|
||||
confirm?).
|
||||
|
||||
To get more fair distribution of bits between low-detail and
|
||||
high-detail scenes, you should probably try increasing vqcomp from the
|
||||
default (0.5) to something in the range 0.6-0.8.
|
||||
|
||||
Of course you also want to make sure you crop ALL of the black border and
|
||||
any half-black pixels at the edge of the image, and make sure the final
|
||||
image dimensions after cropping and scaling are multiples of 16. Failing to
|
||||
do so will drastically reduce quality.
|
||||
|
||||
Finally, if you can't seem to get good results, you can try scaling the
|
||||
movie down a bit smaller or applying a weak gaussian blur to reduce the
|
||||
amount of detail.
|
||||
|
||||
Now, my personal success story! I just recently managed to fit a beautiful
|
||||
encode of Kundun (well over 2 hours long, but not too many high-motion
|
||||
scenes) on one cd at 640x304, with 66 kbit/sec abr ogg audio, using the
|
||||
options I described above. So, IMHO it's definitely possible to get very
|
||||
good results with libavcodec (certainly MUCH better than all the idiot
|
||||
"release groups" using DivX3 make), as long as you take some time to play
|
||||
around with the options.
|
||||
|
||||
|
||||
Rich
|
||||
|
||||
============
|
||||
ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART I: LUMA & CHROMA
|
||||
|
||||
|
||||
The l/c in vlelim and vcelim stands for luma (brightness plane) and chroma
|
||||
(color planes). These are encoded separately in all mpeg-like algorithms.
|
||||
Anyway, the idea behind these options is (at least from what I understand)
|
||||
to use some good heuristics to determine when the change in a block is less
|
||||
than the threshold you specify, and in such a case, to just encode the
|
||||
block as "no change". This saves bits and perhaps speeds up encoding. Using
|
||||
a negative value for either one means the same thing as the corresponding
|
||||
positive value, but the DC coefficient is also considered. Unfortunately
|
||||
I'm not familiar enough with the mpeg terminology to know what this means
|
||||
(my first guess would be that it's the constant term from the DCT), but it
|
||||
probably makes the encoder less likely to apply single coefficient
|
||||
elimination in cases where it would look bad. It's presumably recommended
|
||||
to use negative values for luma (which is more noticable) and positive for
|
||||
chroma.
|
||||
|
||||
The other options -- lumi_mask and dark_mask -- control how the quantizer
|
||||
is adjusted for really dark or bright regions of the picture. You're
|
||||
probably already at least a bit familiar with the concept of quantizers
|
||||
(qscale, lower = more precision, higher quality, but more bits needed to
|
||||
encode). What not everyone seems to know is that the quantizer you see
|
||||
(e.g. in the 2pass logs) is just an average for the whole frame, and lower
|
||||
or higher quantizers may in fact be used in parts of the picture with more
|
||||
or less detail. Increasing the values of lumi_mask and dark_mask will cause
|
||||
lavc to aggressively increase the quantizer in very dark or very bright
|
||||
regions of the picture (which are presumably not as noticable to the human
|
||||
eye) in order to save bits for use elsewhere.
|
||||
|
||||
Rich
|
||||
|
||||
===================
|
||||
ABOUT VLELIM, VCELIM, LUMI_MASK AND DARK_MASK PART II: VQSCALE
|
||||
|
||||
OK, a quick explanation. The quantizer you set with vqscale=N is the
|
||||
per-frame quantizer parameter (aka qp). However, with mpeg4 it's
|
||||
allowed (and recommended!) for the encoder to vary the quantizer on a
|
||||
per-macroblock (mb) basis (as I understand it, macroblocks are 16x16
|
||||
regions composed of 4 8x8 luma blocks and 2 8x8 chroma blocks, u and
|
||||
v). To do this, lavc scores each mb with a complexity value and
|
||||
weights the quantizer accordingly. However, you can control this
|
||||
behavior somewhat with scplx_mask, tcplx_mask, dark_mask, and
|
||||
lumi_mask.
|
||||
|
||||
scplx_mask -- raise quantizer on mb's with lots of spacial complexity.
|
||||
Spacial complexity is measured by variance of the texture (this is
|
||||
just the actual image for I blocks and the difference from the
|
||||
previous coded frame for P blocks).
|
||||
|
||||
tcplx_mask -- raise quantizer on mb's with lots of temporal
|
||||
complexity. Temporal complexity is measured according to motion
|
||||
vectors.
|
||||
|
||||
dark_mask -- raise quantizer on very dark mb's.
|
||||
|
||||
lumi_mask -- raise quantizer on very bright mb's.
|
||||
Somewhere around 0-0.15 is a safe range for these values, IMHO. You
|
||||
might try as high as 0.25 or 0.3. You should probably never go over
|
||||
0.5 or so.
|
||||
|
||||
Now, about naq. When you adjust the quantizers on a per-mb basis like
|
||||
this (called adaptive quantization), you might decrease or (more
|
||||
likely) increase the average quantizer used, so that it no longer
|
||||
matches the requested average quantizer (qp) for the frame. This will
|
||||
result in weird things happening with the bitrate, at least from my
|
||||
experience. What naq does is "normalize adaptive quantization". That
|
||||
is, after the above masking parameters are applied on a per-mb basis,
|
||||
the quantizers of all the blocks are rescaled so that the average
|
||||
stays fixed at the desired qp.
|
||||
|
||||
So, if I used vqscale=4 with naq and fairly large values for the
|
||||
masking parameters, I might be likely to see lots of frames using
|
||||
qscale 2,3,4,5,6,7 across different macroblocks as needed, but with
|
||||
the average sticking around 4. However, I haven't actually tested such
|
||||
a setup yet, so it's just speculation right now.
|
||||
|
||||
Have fun playing around with it.
|
||||
|
||||
Rich
|
||||
|
||||
|
||||
================================================================================
|
||||
|
||||
|
||||
TIPS FOR ENCODING OLD BLACK & WHITE MOVIES:
|
||||
|
||||
I found myself that 4:3 B&W old movies are very hard to compress well. In
|
||||
addition to the 4:3 aspect ratio which eats lots of bits, those movies are
|
||||
typically very "noisy", which doesn't help at all. Anyway :
|
||||
|
||||
> After a few tries I am
|
||||
> still a little bit disappointed with the video quality. Since it is a
|
||||
> "dark" movies, there is a lot of black on the pictures, and on the
|
||||
> encoded avi I can see a lot of annoying "mpeg squares". I am using
|
||||
> avifile codec, but the best I think is to give you the command line I
|
||||
> used to encode a preview of the result:
|
||||
|
||||
>
|
||||
> First pass:
|
||||
> mencoder TITLE01-ANGLE1.VOB -oac copy -ovc lavc -lavcopts
|
||||
> vcodec=mpeg4:vhq:vpass=1:vbitrate=800:keyint=48 -ofps 23.976 -npp lb
|
||||
> -ss 2:00 -endpos 0:30 -vf scale -zoom -xy 640 -o movie.avi
|
||||
|
||||
1) keyint=48 is way too low. The default value is 250, this is in *frames*
|
||||
not seconds. Keyframes are significantly larger than P or B frames, so the
|
||||
less keyframes you have, better the overall movie will be. (huh, like Yoda
|
||||
I speak ;). Try keyint=300 or 350. Don't go beyond that if you want
|
||||
relatively precise seeking.
|
||||
|
||||
2) you may want to play with vlelim and vcelim options. This can gives you
|
||||
a significant "quality" boost. Try one of these couples :
|
||||
|
||||
vlelim=-2:vcelim=3
|
||||
vlelim=-3:vcelim=5
|
||||
vlelim=-4:vcelim=7
|
||||
(and yes, there's a minus)
|
||||
|
||||
3) crop & rescale the movie before passing it to the codec. First crop the
|
||||
movie to not encode black bars if there's any. For a 1h40mn movie
|
||||
compressed to a 700 MB file, I would try something between 512x384 and
|
||||
480x320. Don't go below that if you want something relatively sharp when
|
||||
viewed fullscreen.
|
||||
|
||||
4) I would recommend using the Ogg Vorbis audio codec with the .ogm
|
||||
container format. Ogg Vorbis compress audio better than MP3. On a typical
|
||||
old, mono-only audio stream, a 45 kbits/s Vorbis stream is ok. How to
|
||||
extract & compress an audio stream from a ripped DVD (mplayer dvd://1
|
||||
-dumpstream) :
|
||||
|
||||
rm -f audiodump.pcm ; mkfifo -m 600 audiodump.pcm
|
||||
mplayer -quiet -vc null -vo null -aid 128 -ao pcm -nowaveheader stream.dump &
|
||||
oggenc --raw --raw-bits=16 --raw-chan=2 --raw-rate=48000 -q 1 -o audio-us.ogg
|
||||
+audiodump.pcm &
|
||||
wait
|
||||
|
||||
For a nice set of utilities to manager the .ogm format, see Moritz Bunkus'
|
||||
ogmtools (google is your friend).
|
||||
|
||||
5) use the "v4mv" option. This could gives you a few more bits at the
|
||||
expense of a slightly longer encoding. This is a "lossless" option, I mean
|
||||
with this option you don't throw away some video information, it just
|
||||
selects a more precise motion estimation method. Be warned that on some
|
||||
very un-typical scenes this option may gives you a longer file than
|
||||
without, although it's very rare and on a whole film I think it's always a
|
||||
win.
|
||||
|
||||
6) you can try the new luminance & darkness masking code. Play
|
||||
with the "lumi_mask" and "dark_mask" options. I would recommend using
|
||||
something like :
|
||||
lumi_mask=0.07:dark_mask=0.10:naq:
|
||||
lumi_mask=0.10:dark_mask=0.12:naq:
|
||||
lumi_mask=0.12:dark_mask=0.15:naq
|
||||
lumi_mask=0.13:dark_mask=0.16:naq:
|
||||
Be warned that these options are really experimental and the result
|
||||
could be very good or very bad depending on your visualization device
|
||||
(computer CRT, TV or TFT screen). Don't push too hard these options.
|
||||
|
||||
> Second pass:
|
||||
> the same with vpass=2
|
||||
|
||||
7) I've found that lavc gives better results when the first pass is done
|
||||
with "vqscale=2" instead of a target bitrate. The statistics collected
|
||||
seems to be more precise. YMMV.
|
||||
|
||||
> I am new to mencoder, so please tell me any idea you have even if it
|
||||
> obvious. I also tried the "gray" option of lavc, to encode B&W only,
|
||||
> but strangely it gives me "pink" squares from time to time.
|
||||
|
||||
Yes, I've seen that too. Playing the resulting file with "-lavdopts gray"
|
||||
fix the problem but it's not very nice ...
|
||||
|
||||
> So if you could tell me what option of mencoder or lavc I should be
|
||||
> looking at to lower the number of "squares" on the image, it would be
|
||||
> great. The version of mencoder i use is 0.90pre8 on a macos x PPC
|
||||
> platform. I guess I would have the same problem by encoding anime
|
||||
> movies, where there are a lot of region of the image with the same
|
||||
> color. So if you managed to solve this problem...
|
||||
|
||||
You could also try the "mpeg_quant" flag. It selects a different set of
|
||||
quantizers and produce somewhat sharper pictures and less blocks on large
|
||||
zones with the same or similar luminance, at the expense of some bits.
|
||||
|
||||
> This is completely off topic, but do you know how I can create good
|
||||
> subtitles from vobsub subtitles ? I checked the -dumpmpsub option of
|
||||
> mplayer, but is there a way to do it really fast (ie without having to
|
||||
> play the whole movie) ?
|
||||
|
||||
I didn't find a way under *nix to produce reasonably good text subtitles
|
||||
from vobsubs. OCR *nix softwares seems either not suited to the task, not
|
||||
powerful enough or both. I'm extracting the vobsub subtitles and simply use
|
||||
them with the .ogm
|
||||
|
||||
/ .avi :
|
||||
1) rip the DVD to harddisk with "mplayer dvd://1 -dumpstream"
|
||||
2) mount the DVD and copy the .ifo file
|
||||
2) extract all vobsubs to one single file with something like :
|
||||
|
||||
for f in 0 1 2 3 4 5 6 7 8 9 10 11 ; do \
|
||||
mencoder -ovc copy -oac copy -o /dev/null -sid $f -vobsubout sous-titres
|
||||
+-vobsuboutindex $f -ifo vts_01_0.ifo stream.dump
|
||||
done
|
||||
|
||||
(and yes, I've a DVD with 12 subtitles)
|
||||
--
|
||||
Rémi
|
||||
|
||||
|
||||
================================================================================
|
||||
|
||||
|
||||
TIPS FOR SMOKE & CLOUDS
|
||||
|
||||
Q: I'm trying to encode Dante's Peak and I'm having problems with clouds,
|
||||
fog and smoke: They don't look fine (they look very bad if I watch the
|
||||
movie in TV-out). There are some artifacts, white clouds looks as snow
|
||||
mountains, there are things likes hip in the colors so one can see frontier
|
||||
curves between white and light gray and dark gray ... (I don't know if you
|
||||
can understand me, I want to mean that the colors don't change smoothly)
|
||||
In particular I'm using vqscale=2:vhq:v4mv
|
||||
|
||||
A: Try adding "vqcomp=0.7:vqblur=0.2:mpeg_quant" to lavcopts.
|
||||
|
||||
Q: I tried your suggestion and it improved the image a little ... but not
|
||||
enough. I was playing with different options and I couldn't find the way.
|
||||
I suppose that the vob is not so good (watching it in TV trough the
|
||||
computer looks better than my encoding, but it isn't a lot of better).
|
||||
|
||||
A: Yes, those scenes with qscale=2 looks terrible :-(
|
||||
|
||||
Try with vqmin=1 in addition to mpeg_quant:vlelim=-4:vcelim=-7 (and maybe
|
||||
with "-sws 10 -ssf ls=1" to sharpen a bit the image) and read about vqmin=1
|
||||
in DOCS/tech/libavc-options.txt.
|
||||
|
||||
If after the whole movie is encoded you still see the same problem, it will
|
||||
means that the second pass didn't picked-up q=1 for this scene. Force q=1
|
||||
with the "vrc_override" option.
|
||||
|
||||
Q: By the way, is there a special difficult in encode clouds or smoke?
|
||||
|
||||
A: I would say it depends on the sharpness of these clouds / smokes and the
|
||||
fact that they are mostly black/white/grey or colored. The codec will do
|
||||
the right thing with vqmin=2 for example on a cigarette smoke (sharp) or on
|
||||
a red/yellow cloud (explosion, cloud of fire). But may not with a grey and
|
||||
very fuzzy cloud like in the chocolat scene. Note that I don't know exactly
|
||||
why ;)
|
||||
|
||||
A = Rémi
|
||||
|
||||
|
||||
================================================================================
|
||||
|
||||
|
||||
TIPS FOR TWEAKING RATECONTROL
|
||||
|
||||
(For the purpose of this explanation, consider "2nd pass" to be any beyond
|
||||
the 1st. The algorithm is run only on P-frames; I- and B-frames use QPs
|
||||
based on the adjacent P. While x264's 2pass ratecontrol is based on lavc's,
|
||||
it has diverged somewhat and not all of this is valid for x264.)
|
||||
|
||||
Consider the default ratecontrol equation in lavc: "tex^qComp".
|
||||
At the beginning of the 2nd pass, rc_eq is evaluated for each frame, and
|
||||
the result is the number of bits allocated to that frame (multiplied by
|
||||
some constant as needed to match the total requested bitrate).
|
||||
|
||||
"tex" is the complexity of a frame, i.e. the estimated number of bits it
|
||||
would take to encode at a given quantizer. (If the 1st pass was CQP and
|
||||
not turbo, then we know tex exactly. Otherwise it is calculated by
|
||||
multiplying the 1st pass's bits by the QP of that frame. But that's not
|
||||
why CQP is potentially good; more on that later.)
|
||||
"qComp" is just a constant. It has no effect outside the rc_eq, and is
|
||||
directly set by the vqcomp parameter.
|
||||
|
||||
If vqcomp=1, then rc_eq=tex^1=tex, so 2pass allocates to each frame the
|
||||
number of bits needed to encode them all at the same QP.
|
||||
If vqcomp=0, then rc_eq=tex^0=1, so 2pass allocates the same number of
|
||||
bits to each frame, i.e. CBR. (Actually, this is worse than 1pass CBR in
|
||||
terms of quality; CBR can vary within its allowed buffer size, while
|
||||
vqcomp=0 tries to make each frame exactly the same size.)
|
||||
If vqcomp=0.5, then rc_eq=sqrt(tex), so the allocation is somewhere
|
||||
between CBR and CQP. High complexity frames get somewhat lower quality
|
||||
than low complexity, but still more bits.
|
||||
|
||||
While the actual selection of a good value of vqcomp is experimental, the
|
||||
following underlying factors determine the result:
|
||||
Arguing towards CQP: You want the movie to be somewhere approaching
|
||||
constant quality; oscillating quality is even more annoying than constant
|
||||
low quality. (However, constant quality does not mean constant PSNR nor
|
||||
constant QP. Details are less noticeable in high-motion scenes, so you can
|
||||
get away with somewhat higher QP in high-complexity frames for the same
|
||||
perceived quality.)
|
||||
Arguing towards CBR: You get more quality per bit if you spend those bits
|
||||
in frames where motion compensation works well (which tends to be
|
||||
correlated with "tex"): A given artifact may stick around several seconds
|
||||
in a low-motion scene, and you only have to fix it in one frame to improve
|
||||
the quality of the whole sequence.
|
||||
|
||||
Now for why the 1st pass ratecontrol method matters:
|
||||
The number of bits at constant quant is as good a measure of complexity as
|
||||
any other simple formula for the purpose of allocating bits. But it's not
|
||||
perfect for predicting which QP will produce the desired number of bits.
|
||||
Bits are approximately inversely proportional to QP, but the exact scaling
|
||||
is non-linear, and depends on the amount of detail/noise, the complexity of
|
||||
motion, the quality of previous frames, and other stuff not measured by the
|
||||
ratecontrol. So it predicts best when the QP used for a given frame in the
|
||||
2nd pass is close to the QP used in the 1st pass. When the prediction is
|
||||
wrong, lavc needs to distribute the surplus or deficit of bits among future
|
||||
frames, which means that they too deviate from the planned distribution.
|
||||
Obviously, with vqcomp=1 you can get the 1st pass QPs very close by using
|
||||
CQP, and with vqcomp=0 a CBR 1st pass is very close. But with vqcomp=0.5
|
||||
it's more ambiguous. The accepted wisdom is that CBR is better for
|
||||
vqcomp=0.5, mostly because you then don't have to guess a QP in advance.
|
||||
But with vqcomp=0.6 or 0.7, the 2nd pass QPs vary less, so a CQP 1st pass
|
||||
(with the right QP) will be a better predictor than CBR.
|
||||
|
||||
To make it more confusing, 1pass CBR uses the same rc_eq with a different
|
||||
meaning. In CBR, we don't have a real encode to estimate from, so "tex" is
|
||||
calculated from the full-pixel precision motion-compensation residual.
|
||||
While the number of bits allocated to a given frame is decided by the rc_eq
|
||||
just like in 2nd pass, the target bitrate is constant (instead of being the
|
||||
sum of per-frame rc_eq values). So the scaling factor (which is constant in
|
||||
2nd pass) now varies in order to keep the local average bitrate near the
|
||||
CBR target. So vqcomp does affect CBR, though it only determines the local
|
||||
allocation of bits, not the long-term allocation.
|
||||
|
||||
--Loren Merritt
|
||||
@ -1,32 +0,0 @@
|
||||
Due to a lack of Windows developers, it is a good idea to allow Linux
|
||||
developers to do at least some basic check of their code.
|
||||
This HOWTO explains how to set up MinGW cross-compilation under Debian.
|
||||
|
||||
First, you need to install the "mingw32" package and get a MPlayer SVN
|
||||
checkout.
|
||||
|
||||
Next, you need quite a lot of dependencies. Since this is for testing and
|
||||
not actually use, the easiest way is to use this package:
|
||||
http://natsuki.mplayerhq.hu/~reimar/mpl_mingw32.tar.bz2
|
||||
NOTE that this is likely to be quite out-dated and might include packages
|
||||
with security issues, so do not use it to build binaries for real use.
|
||||
|
||||
After extracting this package into the MPlayer source-tree,
|
||||
you only need to run the included linux-mingw.sh to configure (it just runs
|
||||
./configure --host-cc=cc --target=i686-mingw32msvc --cc=i586-mingw32msvc-cc
|
||||
--windres=i586-mingw32msvc-windres --ranlib=i586-mingw32msvc-ranlib
|
||||
--with-extraincdir="$PWD/osdep/mingw32"
|
||||
--with-extralibdir="$PWD/osdep/mingw32"
|
||||
--with-freetype-config="$PWD/osdep/mingw32/ftconf") and then run make.
|
||||
|
||||
You should be able to run the generated binary with Wine, if you want to.
|
||||
|
||||
The steps as command-lines:
|
||||
|
||||
sudo apt-get install mingw32
|
||||
svn co svn://svn.mplayerhq.hu/mplayer/trunk MPlayer-mingw
|
||||
cd MPlayer-mingw
|
||||
wget http://natsuki.mplayerhq.hu/~reimar/mpl_mingw32.tar.bz2
|
||||
tar -xjf mpl_mingw32.tar.bz2
|
||||
sh linux-mingw.sh
|
||||
make
|
||||
@ -1,230 +0,0 @@
|
||||
------------------------------
|
||||
How to build an MPlayer mirror
|
||||
------------------------------
|
||||
|
||||
This document might be inacurate or even incomplete, please
|
||||
send feedback + corrections to the mplayer-mirror mailing list.
|
||||
|
||||
About this document
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Mirroring MPlayer is quite easy but requires a few steps to be taken
|
||||
and a few things taken care of. This document describes these steps
|
||||
in detail so that anyone wishing to build an official or an unofficial
|
||||
mirror can do that without much trouble.
|
||||
|
||||
|
||||
A note on performance issues
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A few of the commands used here will generate some load on our main server.
|
||||
Too many clients executing them at once will overload our server and cause
|
||||
a performance degradation for all our users. Thus we kindly ask you to be
|
||||
considerate about what you do. We do not want to restrict mirroring to a
|
||||
few select people, but this requires everyone using the system described
|
||||
here to behave.
|
||||
|
||||
|
||||
Outline of the mirroring system
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The mirroring system uses rsync to transfer the data and to perform
|
||||
updates. A script (update_mplayer_rsync) is provided to call the rsync
|
||||
client with the right set of parameters. This script should be run
|
||||
periodically via cron.
|
||||
Additionally, official mirrors should set up an ssh account so that
|
||||
updates can be triggered when important changes on the main server
|
||||
are performed.
|
||||
Mirrors should provide their data over HTTP or FTP or both. Each official
|
||||
mirror will be assigned a mirror number (wwwXXX.mplayerhq.hu or
|
||||
ftpXXX.mplayerhq.hu where XXX is the mirror number). This mirror
|
||||
number determines the hostname over which it can be reached directly.
|
||||
|
||||
All mirrors are put into our DNS round-robin for the www.mplayerhq.hu and
|
||||
ftp.mplayerhq.hu names and should be set up to respond to these names as well.
|
||||
|
||||
|
||||
Requirements
|
||||
~~~~~~~~~~~~
|
||||
The requirements for any (official) mirror are:
|
||||
1) rsync installed and some way to run the sync script periodicaly (eg cron)
|
||||
2) subscribing to the mplayer-mirror mailing list (see below)
|
||||
|
||||
The requirements for a full website mirror are:
|
||||
1) 500MB of free disk space (for the ftp and homepage directories).
|
||||
2) A network connection with about 5Mbit/s sustained bandwidth.
|
||||
3) A simple webserver that allows redirections and virtual server,
|
||||
no PHP or CGI needed as all pages are static.
|
||||
|
||||
The requirements for a full ftp mirror are:
|
||||
1) 500MB of free disk space (for the ftp directory).
|
||||
2) (No bandwidth data for a ftp only server available)
|
||||
|
||||
|
||||
Getting the data, mirroring script and cron setup
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The mirroring script is located in our Subversion repository at
|
||||
|
||||
svn://svn.mplayerhq.hu/mplayer/trunk/DOCS/tech/mirrors/update_mplayer_rsync
|
||||
|
||||
or on the web at
|
||||
|
||||
http://svn.mplayerhq.hu/*checkout*/mplayer/trunk/DOCS/tech/mirrors/update_mplayer_rsync
|
||||
|
||||
This script requires a working `rsync` client. The handling of the
|
||||
lock file is done by using `lockfile` from the procmail package.
|
||||
Using a lock file is recommended but not necessary. The temporary file
|
||||
generation is handled by `mktemp` which is available from
|
||||
http://www.mktemp.org/mktemp/ .
|
||||
|
||||
The script contains a few configuration variables at the beginning that
|
||||
can and should be set:
|
||||
PATH: The $PATH to be used within the script (recommended).
|
||||
LOCK: The full path to the lock file to be used (/var/lock/mplayer-mirror-lock
|
||||
or something similar, recommended).
|
||||
MIRROR_ROOT: The root of the mirror. This is the directory where all files
|
||||
are downloaded to (required).
|
||||
MAILADR: The mail address where reports should be sent to (required).
|
||||
TMPDIR: The directory where temporary files should be created.
|
||||
If you set this explicitly, you have to uncomment the export below
|
||||
(defaults to /tmp if not set).
|
||||
|
||||
Install this script and set the variables according to your setup. Then run
|
||||
it once to get the first checkout of the mirror. This will require (at the
|
||||
time of this writing - 2006-06) about 500MB of disk space.
|
||||
You should get two directories in your $MIRROR_ROOT: homepage and MPlayer.
|
||||
The former containing the HTML pages for the mirror and the latter the
|
||||
downloadable files.
|
||||
|
||||
If this worked out OK, you should set up a cron job that periodically updates
|
||||
the files. If you run an official mirror you should run the script every
|
||||
6h to 12h (6h recommended). If you do not run an official mirror, you should
|
||||
not run the script more often than once a day. Please use an "odd" time
|
||||
to run the script when it is unlikely that any other cron job is running.
|
||||
Bad times are e.g. full hours, or minutes that are divisible by 5.
|
||||
An example crontab line would look like this:
|
||||
---
|
||||
17 1,8,13,19 * * * /path/to/update_mplayer_rsync
|
||||
---
|
||||
(please change the minute and hours to something random)
|
||||
|
||||
You can change the rest of the script as you see fit, although it is not
|
||||
recommended. Please DO NOT CHANGE the options of the rsync commands.
|
||||
Especially DO NOT REMOVE the -t and -W options. These prevent calculating
|
||||
checksums on the server side which are very expensive.
|
||||
|
||||
|
||||
Setting up an SSH account for update triggers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Official mirrors should provide an ssh-based trigger to run the update script
|
||||
on request. This makes it possible to distribute releases and other important
|
||||
files immediately to all mirrors.
|
||||
|
||||
The setup does not need a special user other than the one as which the update
|
||||
script is run and does not allow running any other command.
|
||||
|
||||
First you need to create an ssh key pair by running:
|
||||
---
|
||||
ssh-keygen -t dsa -C MPHQ_rsync_trigger -f www#_sshkey
|
||||
---
|
||||
(replace the '#' by your mirror number)
|
||||
|
||||
You should send the private key to us by mail and specify the host and
|
||||
user to be used. Please use a private mail of one of the admins and
|
||||
DO NOT send the private key to the mirror mailing list.
|
||||
|
||||
The public key should be placed in the ~/.ssh/authorized_keys file of the
|
||||
user running the updates. To restrict the ssh key to only one command place
|
||||
the following directives at the beginning of the line with the key:
|
||||
from="*.mplayerhq.hu",command="<path_to_update_mplayer_rsync>"
|
||||
e.g.:
|
||||
---
|
||||
from="*.mplayerhq.hu",command="/path/to/update_mplayer_rsync" ssh-dss AAAA
|
||||
B3NzaC1kc3MAAAEBAI20yhE3/bRjzojUhhMz4DHnGhcJUiPWOfoP9CygnFOYOxJTFlxgqM3iJiHWRxgK
|
||||
FJ/Uw40eV9K4Ww4fp2pe1guXJzKna8+6vBXaPPVEVxSyaxgtt4Xt3zpUuCnNljgArcEhwcNyOyH2RVln
|
||||
yhyxsrKhuq5ZoNHD3caBGjZu3eOR2atPGS1NOdeN/hytIoh8T8DicPqPI29yWX9yAjnHv6wdPutwMLu6
|
||||
[...]
|
||||
n0Fs3CJY6/1UpgDGH7VPey0SdpJEDewltRLA+buP++2vJD/NUOeGzcRydo2NdZ1wiiaytXxkaec928JC
|
||||
NABTeBh6NKAg4vnPvcRLKEBVdSrar/fARSbOmf3HOcsw3uZoAIE9jDGhnMKcnXfHjPZ2tZP9CHs6Wo4n
|
||||
yDOxIfDZmJ7VJqMRc6//p5k81pkkGvawbPA63StI/Dkv/648l4XONuJc2z5gaUdjrTA8TsD/VJGiGcHl
|
||||
mlGj3IWCBz7e4+XB3L64kFZwLCYN8kwDUAaHq4EtcMVOnQ== MPHQ_rsync_trigger
|
||||
---
|
||||
(lines split for readability)
|
||||
|
||||
|
||||
Setting up a webserver
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Set up Apache or whatever web server you prefer. We just have static pages,
|
||||
so no fancy configuration is necessary. However, we need a few aliases so that
|
||||
links on our pages work correctly. /MPlayer and /DOCS should redirect to the
|
||||
directory with the downloadable files.
|
||||
|
||||
Here is an example stanza to paste into your Apache configuration:
|
||||
|
||||
<VirtualHost www#.mplayerhq.hu>
|
||||
DocumentRoot /path/to/htdocs
|
||||
Options FollowSymLinks Indexes
|
||||
Alias /MPlayer /path/to/MPlayer
|
||||
Alias /DOCS /path/to/MPlayer/DOCS
|
||||
AddDefaultCharset off
|
||||
</VirtualHost>
|
||||
|
||||
<VirtualHost www.mplayerhq.hu>
|
||||
DocumentRoot /path/to/htdocs
|
||||
Options FollowSymLinks Indexes
|
||||
Alias /MPlayer /path/to/MPlayer
|
||||
Alias /DOCS /path/to/MPlayer/DOCS
|
||||
AddDefaultCharset off
|
||||
</VirtualHost>
|
||||
|
||||
The AddDefaultCharset directive is necessary because newer versions of Apache
|
||||
appear to default to defining a standard charset. This breaks our documentation
|
||||
translations, which are written in different encodings.
|
||||
|
||||
The second VirtualHost is necessary for the DNS round-robin address.
|
||||
To check whether this VirtualHost works, you can add a temporary entry into
|
||||
your /etc/hosts file:
|
||||
|
||||
1.2.3.4 www.mplayerhq.hu
|
||||
|
||||
Replace the IP address by the real IP address of your mirror. Do not forget to
|
||||
remove the entry after you finish testing.
|
||||
|
||||
|
||||
Webserver checklist
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
After setting up the web server, please verify that the following things work
|
||||
both for your mirror address (www#.mplayerhq.hu) and the DNS round-robin
|
||||
address (www.mplayerhq.hu):
|
||||
|
||||
- The virtual host is reachable by its address.
|
||||
- The MPlayer and DOCS subdirectories work.
|
||||
- The man pages and documentation are served with the correct content-type.
|
||||
Try Russian or Chinese, you will notice breakage immediately.
|
||||
|
||||
|
||||
Setting up an FTP server
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Any FTP server will do. We use vsftpd, it is fast and secure. The setup is
|
||||
similar to the web server setup. The FTP server should listen on both its mirror
|
||||
address (ftp#.mplayerhq.hu) and the DNS round-robin address (ftp.mplayerhq.hu).
|
||||
All our mirrors are public, so you should allow anonymous access.
|
||||
|
||||
You should have the same directory layout as we do on our server, so there
|
||||
should be a subdirectory named 'MPlayer' (notice the capitals) that contains
|
||||
the downloadable files.
|
||||
|
||||
|
||||
Mailing list
|
||||
~~~~~~~~~~~~
|
||||
|
||||
All official mirror admins are required to subscribe to the mplayer-mirror
|
||||
mailing list. It's used to coordinate the efforts and distribute information
|
||||
among all admins. It is also very low traffic. Please use the webinterface
|
||||
on http://lists.mplayerhq.hu/mailman/listinfo/mplayer-mirror to subscribe.
|
||||
Please do not top-post on this mailing list.
|
||||
@ -1,37 +0,0 @@
|
||||
#!/bin/sh
|
||||
# MPlayer mirroring script
|
||||
# $Id$
|
||||
|
||||
PATH=<set_path_if_necessary>
|
||||
LOCK=<path_to_lockfile>
|
||||
MIRROR_ROOT=<path_to_mirror_root>
|
||||
MAILADR=<report_mail_to_adr>
|
||||
|
||||
#TMPDIR = /tmp
|
||||
#export TMPDIR
|
||||
|
||||
TMPFILE=$(mktemp -t mplayer.XXXXXXXXXXX)
|
||||
|
||||
# Check to see if another sync is in progress
|
||||
if lockfile -! -l 43200 -r 0 "$LOCK"; then
|
||||
echo Unable to start mirroring MPlayer, lock file exists.
|
||||
exit 1
|
||||
fi
|
||||
trap "rm -f $LOCK > /dev/null 2>&1" exit
|
||||
|
||||
cd $MIRROR_ROOT
|
||||
|
||||
echo "************ rsyncing homepage ************" >> $TMPFILE
|
||||
rsync -pxlrHtWv --delete --delete-after rsync.mplayerhq.hu::homepage/ \
|
||||
homepage >> $TMPFILE 2>&1
|
||||
|
||||
echo "************ rsyncing MPlayer ************" >> $TMPFILE
|
||||
rsync -pxlrHtWv --delete --delete-after --exclude '/benchmark' \
|
||||
--exclude '/old_stuff' --exclude '/tests' rsync.mplayerhq.hu::ftp/ \
|
||||
MPlayer >> $TMPFILE 2>&1
|
||||
|
||||
x=$(wc -l $TMPFILE | awk '{print $1}')
|
||||
if [ "$x" -ne "10" ]; then
|
||||
mailx -s "MPlayer mirror" $MAILADR < $TMPFILE
|
||||
fi
|
||||
rm -f $TMPFILE
|
||||
@ -1,28 +0,0 @@
|
||||
MPlayer's Dump Stream Formats
|
||||
=============================
|
||||
|
||||
Designed by Alex & Arpi
|
||||
|
||||
The file starts with a variable size header:
|
||||
--------------------------------------------
|
||||
|
||||
32-bit Stream format fourcc (MPVS or MPAS)
|
||||
MPVS = MPlayer Video Stream
|
||||
MPAS = MPlayer Audio Stream
|
||||
8-bit Demuxer type (AVI,MOV,ASF,REAL,...)
|
||||
8-bit Flags (marks dumped headers)
|
||||
Values: 0x1: WAVEFORMATEX
|
||||
0x2: Audio extra codec data
|
||||
0x4: BITMAPINFOHEADER
|
||||
0x8: QT's ImageDesc
|
||||
0x16: indicates 32-bit chunk size before every data chunk
|
||||
16-bit Length of headers
|
||||
|
||||
There's strict rule in the follow-up of the codec-headers.
|
||||
Depending on flags,
|
||||
|
||||
Data chunks:
|
||||
------------
|
||||
|
||||
32-bit Optional 32-bit chunk size
|
||||
... Data
|
||||
@ -1,86 +0,0 @@
|
||||
draft of new OSD engine:
|
||||
========================
|
||||
written by A'rpi
|
||||
including ideas from mailing list from Jiri Svoboda, Tobias Diedrich,
|
||||
Artur Zaprzala, Michael Niedermayer, Felix Buenemann, LGB
|
||||
|
||||
requirements:
|
||||
- be able to do partial rendering, within a given bounding box
|
||||
useful when parts of the OSD are outside of the image and has to be
|
||||
updated only when OSD changes, or even has different colorspace
|
||||
|
||||
- text should be rendered in 2-pass way: 1. alpha 2. pixels
|
||||
so char's alpha won't overwrite previous char, and may be faster
|
||||
|
||||
- OSD elements should be cached - so rendering once into the cache and
|
||||
reuse this while it's unchanged
|
||||
|
||||
- color support (colorspace could be YA, YUVA, RGB)
|
||||
|
||||
- change brightness, saturation, hue of chars ???
|
||||
|
||||
- way to disable alphablending, and use black outline (FAST_OSD now)
|
||||
|
||||
- respect movie and monitor aspect, so OSD is rendered/scaled correctly
|
||||
eg. for SVCD/anamorphic DVD with hardware scaling (now OSD is squashed)
|
||||
|
||||
- develop some text-based apps: osdterm, osdzilla etc ;)
|
||||
|
||||
Ok. The basic idea of my design is using 'OSD objects', a data structure
|
||||
in a 1 (or 2?) way linked list.
|
||||
There would be different object types, sharing type-dependent data in a
|
||||
union. The basic types: box, text, symbol, progressbar, group.
|
||||
|
||||
Group would be a special type, grouping other OSD objects together,
|
||||
with a common x,y and boundingbox. Useful for grouping symbol+progrbar
|
||||
or multiline subtitle text.
|
||||
|
||||
Each object could have flags, for example:
|
||||
- visible (set if we should display it)
|
||||
- color (set if it's YUVA not YA)
|
||||
- cached (set when there is a cached rendered variant)
|
||||
- bbox updated (should be set when recalc bbox, reset when change params)
|
||||
- several flags to control positioning. for example, x;y could be
|
||||
absolute coordinates, or percent. flags to set left/center/right alignment...
|
||||
- start and end timestamp, to automagically set/reset visible flag
|
||||
|
||||
OK, my first draft:
|
||||
|
||||
typedef struct mp_osd_obj_s {
|
||||
struct mp_osd_obj_s* next;
|
||||
unsigned char type;
|
||||
unsigned char alignment; // 2 bits: x;y percentages, 2 bits: x;y relative to parent; 2 bits: alignment left/right/center
|
||||
unsigned short flags;
|
||||
int x,y; // coords
|
||||
unsigned char color[4]; // YUVA
|
||||
mp_osd_bbox_t bbox; // bounding box
|
||||
unsigned int start,duration; // PTS
|
||||
union {
|
||||
struct {
|
||||
int x1,y1,x2,y2;
|
||||
} line;
|
||||
struct {
|
||||
int x,y,w,h;
|
||||
} rect;
|
||||
struct {
|
||||
char* text;
|
||||
mp_font_t* font;
|
||||
} text;
|
||||
struct {
|
||||
int symbol; // unicode
|
||||
mp_font_t* font;
|
||||
} symbol;
|
||||
struct {
|
||||
float value;
|
||||
mp_font_t* font;
|
||||
} pbar;
|
||||
struct {
|
||||
int w,h;
|
||||
unsigned char* image;
|
||||
unsigned int* palette;
|
||||
} spu; // FIXME!
|
||||
struct {
|
||||
struct mp_osd_obj_s* children;
|
||||
} group;
|
||||
} params;
|
||||
} mp_osd_obj_t;
|
||||
@ -1,119 +0,0 @@
|
||||
Sending patches:
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Note: We know our rules place a burden on you, but rest assured that
|
||||
maintaining a big and complex software project is even harder, so please
|
||||
accept our rules. We cannot afford to spend our time fixing buggy, broken or
|
||||
outdated patches. The closer you follow our rules the higher is the probability
|
||||
that your patch will be included.
|
||||
|
||||
0. Do not send complete files. These need to be diffed by hand to see the
|
||||
changes, which makes reviews harder and less likely to occur. Besides as
|
||||
soon as one of the files changes, your version becomes harder to apply,
|
||||
thus reducing its chances of being accepted.
|
||||
|
||||
1. Always make patches for Subversion HEAD. The README describes how to check
|
||||
out Subversion and daily snapshots are available from our download page.
|
||||
We do not accept patches for releases or outdated Subversion revisions.
|
||||
|
||||
2. Make unified diffs ('svn diff' or 'diff -Naur'). Unified diffs can be
|
||||
applied easily with 'patch'. This is much harder with other diff types.
|
||||
Besides, unified diffs are more readable and thus easier to review.
|
||||
|
||||
3. Create the diff from the root of the MPlayer source tree, this makes the
|
||||
diff easier to apply as it saves the step of searching for and changing
|
||||
to the correct directory.
|
||||
|
||||
4. Test the functionality of your patch. We'll *refuse* it if it breaks
|
||||
something, even if it extends other features!
|
||||
|
||||
5. Read your patch. We'll *refuse* it if it changes indentation of the
|
||||
code or if it does tab/space conversion or other cosmetic changes!
|
||||
|
||||
NOTE: If you already wrote some code and did cosmetic changes, you can
|
||||
use 'diff -uwbBE' to help you remove them. Don't forget to check the
|
||||
patch to make sure diff didn't ignore some important change and remove
|
||||
any remaining cosmetics!
|
||||
To use these options directly with svn, use this command:
|
||||
svn diff --diff-cmd diff -x -uwbBE
|
||||
|
||||
6. Comment parts that really need it (tricky side-effects etc).
|
||||
Always document string operations! Comment on what you are doing
|
||||
and why it is safe. This makes it easy to review and change your
|
||||
code if needed. Commenting trivial code not required.
|
||||
Comments must be English!
|
||||
|
||||
7. If you implement new features, add or change command line switches or
|
||||
modify the behavior of existing features, please do not forget to also
|
||||
update the documentation. The documentation maintainers will assist you
|
||||
in doing this. Updating the English documentation is enough. If you
|
||||
speak several languages you are of course welcome to update some of the
|
||||
translations as well.
|
||||
|
||||
8. If you make independent changes, try to send them as separate patches
|
||||
in separate mails. Likewise, if your patch is very big, try splitting
|
||||
it into several self-contained pieces. Each part can then be reviewed
|
||||
and committed separately. Logical units should stay together, though,
|
||||
i.e. do not send a patch for every file or directory you change.
|
||||
|
||||
9. Send your patch to the mplayer-dev-eng mailing list as attachment with
|
||||
the subject line:
|
||||
'[PATCH] very short description of the patch'.
|
||||
In the mail, describe in a few sentences what you change and why.
|
||||
The subject line is very important if you do not want your patch to get
|
||||
lost in the noise. We need the uppercase [PATCH] to be able to search
|
||||
for unapplied patches, so please use it.
|
||||
Do not send your patch as a reply to some other unrelated mail, compose
|
||||
a new message, otherwise it will probably get overlooked.
|
||||
Do not compress your patch unless it is larger than 80k or if you know
|
||||
that your mailer messes up (reformats) text attachments. It only makes
|
||||
handling the patch more difficult. If you have to compress your patch,
|
||||
use either bzip2, gzip or zip to compress it, not a different format.
|
||||
You have to subscribe to mplayer-dev-eng since we blocked postings from
|
||||
non-subscribers after spam problems and because patches get reviewed by
|
||||
the developers on the list. We want you to be available for discussing
|
||||
your code, you might be asked to make modifications before we accept it.
|
||||
Don't worry, mplayer-dev-eng is not high traffic and you can subscribe
|
||||
but unset the "Mail delivery" option so that you can post without getting
|
||||
any mails.
|
||||
Do not upload the patch to a web or FTP site, send it directly to the
|
||||
mailing list. The fewer steps it takes us to get at the patch the higher
|
||||
the likelihood for it to get reviewed and applied. If your patch is so
|
||||
big you cannot send it by mail, try splitting it into smaller pieces.
|
||||
|
||||
10. Give us a few days to react. We try to review patches as fast as possible,
|
||||
but unfortunately we are constantly overloaded with work, be it MPlayer-
|
||||
related or from our day to day lives. If your patch seems to be ignored,
|
||||
send a reminder asking for opinions as a reply to the original patch and
|
||||
mention that you got ignored. We are interested in your work and will
|
||||
eventually either accept it or reject it with an explanation of what we
|
||||
disliked about your patch. We will often ask you to make changes to your
|
||||
patch to make it acceptable. Implement them if you want to see your patch
|
||||
applied and send the update to the mailing list. Remember that updates and
|
||||
reminders must be sent as replies to the original patch to preserve proper
|
||||
mail threading.
|
||||
|
||||
11. Do not immediately ask for Subversion write access. If you have contributed
|
||||
one or more nice, acceptable patches and they need maintaining or you want
|
||||
to be an MPlayer developer, you'll get Subversion write access.
|
||||
|
||||
12. For consistency reasons, all option names must use '-' instead of '_'.
|
||||
|
||||
13. If you make a nontrivial contribution and wish to be mentioned in the
|
||||
AUTHORS file, include that in your patch.
|
||||
|
||||
14. Do not use printf for console output, use our own mp_msg functions instead.
|
||||
For the output to be translated (which includes all messages of level
|
||||
MSGL_HINT and below), put the strings in help/help_mp-en.h. If you change
|
||||
strings, remove the occurrences of these strings from the translations.
|
||||
There may be (compilation) trouble if outdated translations remain in place
|
||||
and translators will pick up changes more easily if they see a new message
|
||||
that has to be translated.
|
||||
|
||||
15. If you send a modified or updated version of your patch, resend the
|
||||
complete patch. It is very time-consuming and error-prone to piece
|
||||
together patches that are distributed over several mails.
|
||||
Please always resend patches as replies to the original mail to keep
|
||||
the thread with the discussion together.
|
||||
|
||||
Thank you!
|
||||
@ -1,60 +0,0 @@
|
||||
How to make an MPlayer release
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
preparations:
|
||||
- Announce release target date on dev-eng and #mplayerdev
|
||||
- Ask the DOCS maintainers to commit their final changes, check if
|
||||
all docs are up to date, etc.
|
||||
- Verify man page, remove obsolete options, mention new ones.
|
||||
- Ask translation maintainers to update their help_mp*.h file.
|
||||
- Update the ChangeLog file (according to Subversion log), ask other developers
|
||||
to verify their parts, etc. Ask Diego to spellcheck it.
|
||||
- Consult at -dev-eng about unstable parts of the code which should be
|
||||
disabled for the release.
|
||||
- Find a codename for the release
|
||||
|
||||
create the release tree:
|
||||
- tag Subversion with release name
|
||||
- Add a VERSION file with the release version to the root of the source tree.
|
||||
- update release.sh script with version number
|
||||
***the following steps are done automatically by release.sh script***
|
||||
- checkout the mplayer src tree
|
||||
- check out FFmpeg subdirs
|
||||
- remove obsolete DOCS translations, help files
|
||||
|
||||
- build the HTML docs from XML sources, then clean up:
|
||||
make html-chunked; make releaseclean
|
||||
|
||||
release the tree:
|
||||
cd ..
|
||||
mv main MPlayer-0.90rc5
|
||||
tar -cf MPlayer-0.90rc5.tar MPlayer-0.90rc5
|
||||
bzip2 -9 MPlayer-0.90rc5.tar
|
||||
***end of part done by release.sh**
|
||||
|
||||
test it (download to your local machine, extract, compile, run)
|
||||
- compilers: gcc 4.x, gcc 3.x, gcc 2.95, MinGW, Cygwin
|
||||
- architectures: PPC, AMD64, x86 with MMX[2], SSE[2], 3DNow
|
||||
- OS: Linux, BSD, Windows, Mac OS X
|
||||
|
||||
copy to FTP:
|
||||
cp MPlayer-0.90rc5.tar.bz2 /home/ftp/MPlayer/releases/
|
||||
cp ChangeLog-0.90rc5 and update ChangeLog symlink
|
||||
md5sum MPlayer-0.90rc5.tar.bz2 > MPlayer-0.90rc5.tar.bz2.md5
|
||||
|
||||
move the older (pre)release(s) (except the last one before the current one)
|
||||
to ../OLD_stuff/ dir
|
||||
|
||||
Somehow get Diego to write a news entry for the release, and update the
|
||||
source file of dload.html and commit it. Test it, it's sometimes buggy
|
||||
(broken links etc). Also, update translated versions of dload.html.
|
||||
|
||||
Send a message to mplayer-announce mailing list.
|
||||
|
||||
Add the new release version to bugzilla page.
|
||||
|
||||
Update release version in #mplayer topic
|
||||
|
||||
Update project page on Freshmeat
|
||||
|
||||
Done.
|
||||
@ -1,89 +0,0 @@
|
||||
HOW TO TEST SNOW
|
||||
----------------
|
||||
|
||||
Snow is an experimental wavelet-based codec made by the FFmpeg developers,
|
||||
and while it is still in heavy development, it is already giving very good
|
||||
results.
|
||||
Be very careful though, as the format of the bitstream produced might
|
||||
change, do not rely on it to store videos that you value.
|
||||
For this reason, MEncoder will not encode without 'vstrict=-2' on the
|
||||
command line.
|
||||
|
||||
|
||||
OPTIONS RECOGNIZED BY SNOW
|
||||
|
||||
* vqscale=<0.0-255.0>
|
||||
Encoding quality, sane range 1-10. 0 is lossless.
|
||||
May be fractional.
|
||||
A given quality in snow needs a somewhat lower qscale than the same
|
||||
quality in MPEG-4.
|
||||
|
||||
* vpass=<1-3>
|
||||
Activates internal two (or more) pass mode.
|
||||
|
||||
* vbitrate=<value>
|
||||
Specify bitrate of 1pass CBR or 2pass ABR. default: 800 kbit/s.
|
||||
This is not very accurate for short videos.
|
||||
|
||||
* lmin, lmax, vqcomp, vratetol, vrc_eq, vrc_override
|
||||
Generic multipass ratecontrol options, subject to the same suggestions
|
||||
as in other codecs.
|
||||
lmin=1 can be useful for medium to high bitrates (see vqscale).
|
||||
|
||||
* cmp, subcmp, mbcmp
|
||||
Set the comparison function, default: 0 (SAD).
|
||||
useful values = 0 (SAD), 1 (SSD), 2 (SATD),
|
||||
11 (5/3 wavelet), 12 (9/7 wavelet).
|
||||
SAD is fastest and lowest quality.
|
||||
SSD is the only function that makes correct decisions about intra vs
|
||||
inter (mbcmp) when using fast motion estimation, but is not the best for
|
||||
the actual search (cmp, subcmp).
|
||||
The wavelet functions (use the one that matches pred) are best quality,
|
||||
especially with vme=8, but are very slow.
|
||||
SATD is a good balance.
|
||||
You can add 256 to any of the options to enable chroma motion
|
||||
estimation for that comparison (e.g. mbcmp=257 for SSD with chroma),
|
||||
but it doesn't seem to help much for the moment.
|
||||
|
||||
* pred=<0-2>
|
||||
Wavelet type.
|
||||
0 = 9/7 wavelet, default.
|
||||
1 = 5/3 wavelet.
|
||||
2 = 13/7 wavelet.
|
||||
9/7 is probably better for for lossy coding, and 5/3 for lossless.
|
||||
NOTE: 9/7 wavelet doesn't work with lossless mode.
|
||||
|
||||
* qpel
|
||||
Refines motion estimation, default: off.
|
||||
This setting always helps compressibility, but costs some CPU time
|
||||
both while encoding and decoding.
|
||||
|
||||
* v4mv
|
||||
Allows smaller motion partitions, default: off.
|
||||
v4mv is theoretically good, but in practice isn't really working yet.
|
||||
The current MB decision algorithm doesn't make very good use of this:
|
||||
It improves quality, but also increases bitrate. (You could get
|
||||
more quality per bitrate by reducing quantizer instead.)
|
||||
|
||||
* vme=<4|8>
|
||||
The default EPZS (4) is the same as in other formats.
|
||||
Snow also supports iterative motion estimation (8), which jointly
|
||||
optimizes adjacent blocks to make the most of OBMC. This significantly
|
||||
improves compression, but is very slow.
|
||||
Iterative ME currently does not perform scenecut detection, so should
|
||||
be used only in the second pass of a two pass encode.
|
||||
|
||||
* refs=<1-8>
|
||||
Allows each block to choose which of several reference frames to
|
||||
motion compensate from. Default: 1. Larger values always improve
|
||||
compression, but cost lots of CPU-time when encoding and extra
|
||||
memory when decoding.
|
||||
|
||||
In short:
|
||||
The best options in almost all cases are
|
||||
vcodec=snow:vstrict=-2:vpass=1:vbitrate=$B:pred=0:cmp=2:subcmp=2:mbcmp=1:qpel
|
||||
vcodec=snow:vstrict=-2:vpass=2:vbitrate=$B:pred=0:cmp=12:subcmp=12:mbcmp=1:qpel:vme=8:refs=8
|
||||
|
||||
Decent, fast options are
|
||||
vcodec=snow:vstrict=-2:vpass=1:vbitrate=$B:pred=0:cmp=1:subcmp=1:mbcmp=1
|
||||
vcodec=snow:vstrict=-2:vpass=2:vbitrate=$B:pred=0:cmp=2:subcmp=2:mbcmp=1:refs=2
|
||||
@ -1,138 +0,0 @@
|
||||
________________________________________
|
||||
HOW TO DO A GOOD TRANSLATION FOR MPLAYER
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We always welcome new translations, but please be aware that
|
||||
translations are not just one time jobs. They have to be maintained
|
||||
in order to be useful. Otherwise they quickly get outdated and become
|
||||
obsolete, useless cruft. That said, we would be happy if you could
|
||||
maintain a new documentation translation.
|
||||
|
||||
Experience shows that translations work best when done by teams. Not only
|
||||
can the workload be shared, but there is also the chance to review the
|
||||
translation. So if possible try to find more people to help out with
|
||||
translating.
|
||||
|
||||
Furthermore, if you take over an unmaintained translation, bring the existing
|
||||
parts up-to-date before translating new ones. Outdated information is worse
|
||||
than missing information. For console messages and the XML documentation,
|
||||
missing parts are automatically replaced by the English versions.
|
||||
|
||||
Documentation related discussions happen on the MPlayer-DOCS mailing list,
|
||||
while documentation translation related discussions happen on the
|
||||
MPlayer-translations mailing list. If you want to maintain a translation
|
||||
you should subscribe to both, as the English documentation Subversion
|
||||
changelogs, which you need to keep the translation up to date, are sent
|
||||
to MPlayer-DOCS. You can subscribe here:
|
||||
|
||||
http://lists.mplayerhq.hu/mailman/listinfo/mplayer-docs
|
||||
http://lists.mplayerhq.hu/mailman/listinfo/mplayer-translations
|
||||
|
||||
Send updates and patches to this mailing list or directly to the translation
|
||||
coordination maintainer, see DOCS/tech/MAINTAINERS for details.
|
||||
|
||||
Translations of MPlayer documentation consist of 3 parts in descending
|
||||
order of importance:
|
||||
|
||||
0) homepage
|
||||
1) console messages (help/help_mp-XX.h)
|
||||
2) man page
|
||||
3) XML documentation
|
||||
|
||||
Not all parts are available in all languages. Keeping existing parts up-to-date
|
||||
should have precedence over adding newly translated content. It is perfectly
|
||||
acceptable to work on only a subset of these parts, but please follow the above
|
||||
order of importance nonetheless.
|
||||
|
||||
Now on to some more detailed instructions...
|
||||
|
||||
general:
|
||||
~~~~~~~~
|
||||
|
||||
Please note that the help_mp files and the XML documentation are both encoded
|
||||
in UTF-8. Editing these files in a program which uses a different encoding
|
||||
will result in breaking console messages and HTML.
|
||||
|
||||
Translations are for documentation what porting is for code. Many more eyes
|
||||
see it and get to find mistakes. If you stumble over mistakes, inaccuracies,
|
||||
clumsy wording, spelling/grammar errors or if you notice that something is
|
||||
incomplete, please let us know, we'll fix it. Patches are more than welcome,
|
||||
of course. Do not, however, change the translation first, please get your
|
||||
update into the English version first.
|
||||
|
||||
If you have Subversion write access and commit a translation update, use
|
||||
something like "synced with rXXX" as first line of the commit message so
|
||||
that it is possible to tell with a glance at the Subversion log or ViewVC
|
||||
if the translation is outdated and which revision of the English master
|
||||
file it is equivalent to.
|
||||
|
||||
If you make (spelling/wording/consistency/etc) changes to a file without
|
||||
adapting parts that changed in the English master file, leave the sync
|
||||
tag as it is.
|
||||
|
||||
|
||||
homepage:
|
||||
~~~~~~~~~
|
||||
|
||||
Get the homepage from Subversion with
|
||||
|
||||
svn checkout svn://svn.mplayerhq.hu/homepage/trunk/ homepage
|
||||
|
||||
or browse the sources online at
|
||||
|
||||
http://svn.mplayerhq.hu/homepage/trunk/
|
||||
|
||||
The homepage uses design template files that are combined with the content
|
||||
files to form the final HTML pages. To build the HTML pages, type 'make' in
|
||||
the root of the homepage source directory.
|
||||
|
||||
|
||||
console messages:
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can find the latest versions of the help_mp-XX.h files in Subversion or
|
||||
here:
|
||||
|
||||
http://svn.mplayerhq.hu/mplayer/trunk/help/
|
||||
|
||||
help_mp-en.h is the master file that you should use as a base for translations.
|
||||
If you are adopting an already existing translation, please check it from top
|
||||
to bottom once. Later it should suffice to just translate missing messages.
|
||||
Additionally, please make sure that your translated messages fit on an 80
|
||||
character wide display to avoid overflowing output.
|
||||
|
||||
TOOLS/mphelp_check.py is a small tool to check translated files. It will report
|
||||
conflicting arguments, strings not present in the master file and (optionally)
|
||||
strings missing from the translation. Running it as
|
||||
|
||||
TOOLS/mphelp_check.py help/help_mp-en.h help/help_mp-XX.h
|
||||
|
||||
will output errors to the screen, just substitute XX with your language code.
|
||||
Adding the -missing option to the command line as in
|
||||
|
||||
TOOLS/mphelp_check.py -missing help/help_mp-en.h help/help_mp-XX.h
|
||||
|
||||
will additionally print untranslated messages to the screen.
|
||||
|
||||
If you do not translate all messages at once, please do not leave untranslated
|
||||
messages in your translated file, just leave them out instead. The MPlayer
|
||||
build system automatically checks for missing messages and uses the English
|
||||
ones instead. This has the added advantage of providing the latest versions of
|
||||
the English messages, since English messages in translations may be outdated.
|
||||
Furthermore, running help_diff.sh on your translated file will immediately show
|
||||
missing messages, which eases further translation.
|
||||
|
||||
If no messages are missing, please add a line similar to
|
||||
|
||||
/* Synced with help_mp-en.h rXXX */
|
||||
|
||||
to the file header, replacing XXX with the revision of help_mp-en.h that your
|
||||
translation is in sync with. This way we can easily tell if the translation
|
||||
is up to date or not.
|
||||
|
||||
|
||||
XML documentation:
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you make changes to the XML documentation, doublecheck that the
|
||||
documentation still builds by running 'make' in the DOCS/xml/ subdirectory.
|
||||
@ -1,181 +0,0 @@
|
||||
|
||||
If wishes were fishes, we'd all cast nets ...
|
||||
|
||||
|
||||
|
||||
Documentation:
|
||||
|
||||
* continue MEncoder tutorial
|
||||
|
||||
* review manual page again
|
||||
|
||||
* split manual page
|
||||
|
||||
* update and rewrite the XML documentation
|
||||
|
||||
* check documentation for completeness
|
||||
|
||||
* write documentation HOWTO/rules document
|
||||
|
||||
* write -lavdopts documentation
|
||||
|
||||
* continue ipod/embedded device encoding guide
|
||||
|
||||
* document channels.conf syntax
|
||||
|
||||
* ability for multiple languages/locales in one binary
|
||||
|
||||
Small improvements:
|
||||
|
||||
* vo_mga should completely blank the screen like fbdev and tdfxfb
|
||||
(maybe there should be an option - some people seem to like it the
|
||||
way it is, but then fbdev should also behave like this..)
|
||||
|
||||
* Debian package creates mplayer.conf.1 .2 ...
|
||||
|
||||
* Make the output windows remember their positions when resizing to
|
||||
double size.
|
||||
|
||||
* Ability to resize to full size/double size/triple (or half) size
|
||||
upon key presses.
|
||||
|
||||
* real mute support, not just setting volume to 0
|
||||
|
||||
* add help suboption to -lavcopts vcodec=/acodec=, -lavfopts format=,
|
||||
-subcp, and anything else that needs it.
|
||||
|
||||
* ability to cycle switch_aspect
|
||||
|
||||
* ability to rename vo_jpeg,vo_gif,vo_png output filename
|
||||
|
||||
Cleanup:
|
||||
|
||||
* integrate dvdnav into mplayer structure
|
||||
|
||||
* integrate libmpdvdkit2 into mplayer structure (message system and
|
||||
command line options)
|
||||
|
||||
* remove all obsolete code, options, files etc
|
||||
|
||||
* Restructure configure and fix CPU flags supported but not shown.
|
||||
|
||||
* Port libmpdemux demuxers to libavformat or write your own from scratch.
|
||||
libmpdemux is considered deprecated and should eventually be removed.
|
||||
As of 2008-01-28, the following demuxers are missing from libavformat:
|
||||
|
||||
- TiVo (ty streams, not TiVo To Go)
|
||||
- VIVO
|
||||
- VQF
|
||||
- XMMS
|
||||
- libnemesi
|
||||
- SL support for MPEG-TS
|
||||
|
||||
|
||||
Filters:
|
||||
|
||||
* get filters to work in more colorspaces
|
||||
|
||||
* eq filter should support RGB in addition to YUV
|
||||
|
||||
* move filters into ffmpeg
|
||||
|
||||
* autocrop filter
|
||||
|
||||
* insert af volnorm during playback
|
||||
|
||||
* allow frame insertion & removal in video filters (with timestamps)
|
||||
|
||||
* xinerama video filter that splits movie to 2 screens (like zr)
|
||||
|
||||
* mixing of multiple videos (picture in picture, review shmem patch)
|
||||
|
||||
* video watermark/logo filter (apply vf_overlay patch?)
|
||||
|
||||
* fade to black filter
|
||||
|
||||
* crossfade filter (audio and video)
|
||||
|
||||
Enhancements:
|
||||
|
||||
* support for VirtualDub and Winamp plugins (apply af_wadspa patch!)
|
||||
|
||||
* implement xawtv config file parser (for channels, etc)
|
||||
|
||||
* G400 2nd head through mga_vid ;)
|
||||
|
||||
* do more things automagically
|
||||
|
||||
* guess correct DVD title
|
||||
|
||||
* SYUV and paletted RGB support in swscaler
|
||||
|
||||
* implement Plextor compatible SCSI VCD reading
|
||||
|
||||
* DXVA / DXVA2 -vo for Windows
|
||||
|
||||
* GDI -vo for older windows versions
|
||||
|
||||
* hardware MPEG encoding support (Ati cards)
|
||||
|
||||
* make -ass-use-margins work on widescreen video only! (not 4/3 video)
|
||||
(automagically put subtitles in black bars)
|
||||
|
||||
* nsc playlist support
|
||||
|
||||
* implement Jack Transport API
|
||||
|
||||
* Stream quality selection, possibly based on available bandwidth.
|
||||
Currently only available for MMS-over-HTTP (libmpdemux/asf_streaming.c).
|
||||
|
||||
* MOD playback (via libmodplug?) - bug #434
|
||||
|
||||
* allow multiple -dump* options at the same time - bug #70
|
||||
|
||||
* scale osd when video window changes size
|
||||
|
||||
* get -ass working in mencoder
|
||||
|
||||
* rotate/position osd
|
||||
|
||||
* support all image formats in mf:// (psd, jpeg2000)
|
||||
|
||||
* make -noborder work with all video outputs
|
||||
|
||||
Difficult stuff:
|
||||
|
||||
* RE all closed source codecs (Voxware, VIVO, MVI2, MSS1/MSS2, ...)
|
||||
|
||||
* support for Bink codec
|
||||
|
||||
* write something like mptv to replace xawtv
|
||||
|
||||
* write/adapt a C implementation of live555 RTSP
|
||||
|
||||
* unify live555 and Real RTSP
|
||||
|
||||
* real mmsu:// support
|
||||
|
||||
* top notch DVD navigation like a hardware player
|
||||
|
||||
* write mpdump application to handle all -dump* options
|
||||
|
||||
* modular MEncoder with audio encoding API
|
||||
|
||||
* multiple audio stream output in Mencoder
|
||||
|
||||
* support for pausing/resuming of encoding in MEncoder
|
||||
|
||||
* DRM support (divx.com, Real.com, iTunes)
|
||||
|
||||
* variable-fps output support for MEncoder
|
||||
|
||||
* smooth stream switching / multiple file caching to avoid the small skip
|
||||
between files when playing multiple files
|
||||
|
||||
* reverse playback
|
||||
|
||||
* more directshow filter/muxer support
|
||||
|
||||
* encode and display video at the same time
|
||||
|
||||
* write mpimage for displaying pictures
|
||||
Loading…
Reference in New Issue
Block a user