RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity

DOCS: remove files documenting removed/rewritten functionality 

Most of these are a waste of time. Some (like slave.txt) have been
rewritten in rst.

The remaining files aren't that useful, but probably do no harm.
This commit is contained in:
wm4 2013-02-03 15:32:21 +01:00
parent df0312b694
commit 19ed132c8a
12 changed files with 0 additions and 3267 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1142
DOCS/OUTDATED-tech/Doxyfile
View File

File diff suppressed because it is too large Load Diff

158
DOCS/OUTDATED-tech/colorspaces.txt
View File

@ -1,158 +0,0 @@
In general
==========
There are planar and packed modes.
- Planar mode means: You have 3 separate images, one for each component,
each image 8 bits/pixel. To get the real colored pixel, you have to
mix the components from all planes. The resolution of planes may differ!
- Packed mode means: you have all components mixed/interleaved together,
so you have small "packs" of components in a single, big image.
There are RGB and YUV colorspaces.
- RGB: Red, Green and Blue components. Used by analog VGA monitors.
- YUV: Luminance (Y) and Chrominance (U,V) components. Used by some
video systems, like PAL. Also most M(J)PEG/DCT based codecs use this.
With YUV, they used to reduce the resolution of U,V planes:
The most common YUV formats:
FOURCC: bpp: IEEE: plane sizes: (w=width h=height of original image)
444P 24 YUV 4:4:4 Y: w * h U,V: w * h
YUY2,UYVY 16 YUV 4:2:2 Y: w * h U,V: (w/2) * h [MJPEG]
YV12,I420 12 YUV 4:2:0 Y: w * h U,V: (w/2) * (h/2) [MPEG, H.263]
411P 12 YUV 4:1:1 Y: w * h U,V: (w/4) * h [DV-NTSC, CYUV]
YVU9,IF09 9 YUV 4:1:0 Y: w * h U,V: (w/4) * (h/4) [Sorenson, Indeo]
The YUV a:b:c naming style means: for <a> samples of Y there are <b> samples
of UV in odd lines and <c> samples of UV in even lines.
conversion: (some cut'n'paste from www and maillist)
RGB to YUV Conversion:
Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128
Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
YUV to RGB Conversion:
B = 1.164(Y - 16) + 2.018(U - 128)
G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128)
R = 1.164(Y - 16) + 1.596(V - 128)
In both these cases, you have to clamp the output values to keep them in
the [0-255] range. Rumour has it that the valid range is actually a subset
of [0-255] (I've seen an RGB range of [16-235] mentioned) but clamping the
values into [0-255] seems to produce acceptable results to me.
Julien (sorry, I can't recall his surname) suggests that there are
problems with the above formula and proposes the following instead:
Y = 0.299R + 0.587G + 0.114B
Cb = U'= (B-Y)*0.565
Cr = V'= (R-Y)*0.713
with reciprocal versions:
R = Y + 1.403V'
G = Y - 0.344U' - 0.714V'
B = Y + 1.770U'
Note: This formula doesn't contain the +128 offsets of U,V values!
Conclusion:
Y = luminance, the weighted average of R G B components. (0=black 255=white)
U = Cb = blue component (0=green 128=grey 255=blue)
V = Cr = red component (0=green 128=grey 255=red)
Huh. The planar YUV modes.
==========================
The most misunderstood thingie...
In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it
doesn't matter what the order of the planes in the memory is:
for mp_image_t and libvo's draw_slice():
planes[0] = Y = luminance
planes[1] = U = Cb = blue
planes[2] = V = Cr = red
Note: planes[1] is ALWAYS U, and planes[2] is V, the FOURCC
(YV12 vs. I420) doesn't matter here! So, every codec using 3 pointers
(not only the first one) normally supports YV12 and I420 (=IYUV), too!
But there are some codecs (VfW, dshow) and vo drivers (xv) ignoring the 2nd
and 3rd pointer that use only a single pointer to the planar YUV image. In
this case we must know the right order and alignment of planes in the memory!
from the webartz fourcc list:
YV12: 12 bpp, full sized Y plane followed by 2x2 subsampled V and U planes
I420: 12 bpp, full sized Y plane followed by 2x2 subsampled U and V planes
IYUV: the same as I420
YVU9: 9 bpp, full sized Y plane followed by 4x4 subsampled V and U planes
Huh 2. RGB vs. BGR ?
====================
The 2nd most misunderstood thingie...
You know, there are Intel and Motorola, and they use different byteorder.
There are also others, like MIPS or Alpha, but all follow either Intel
or Motorola byteorder.
Unfortunately, the packed colorspaces depend on CPU byteorder. So, RGB
on Intel and Motorola means different order of bytes.
In MPlayer, we have constants IMGFMT_RGBxx and IMGFMT_BGRxx.
Unfortunately, some codecs and vo drivers follow Intel, some follow Motorola
byteorder, so they are incompatible. We had to find a stable base, so long
time ago I've chosen OpenGL, as it's a wide-spreaded standard, and it well
defines what RGB is and what BGR is. So, MPlayer's RGB is compatible with
OpenGL's GL_RGB on all platforms, and the same goes for BGR - GL_BGR.
Unfortunately, most of the x86 codecs call our BGR RGB, so it sometimes
confuses developers.
memory order: name
lowest address .. highest address
RGBA IMGFMT_RGBA
ARGB IMGFMT_ARGB
BGRA IMGFMT_BGRA
ABGR IMGFMT_ABGR
RGB IMGFMT_RGB24
BGR IMGFMT_BGR24
order in an int name
most significant .. least significant bit
8A8R8G8B IMGFMT_BGR32
8A8B8G8R IMGFMT_RGB32
5R6G5B IMGFMT_BGR16
5B6G5R IMGFMT_RGB16
1A5R5G5B IMGFMT_BGR15
1A5B5G5R IMGFMT_RGB15
The following are palettized formats, the palette is in the second plane.
When they come out of the swscaler (this can be different when they
come from a codec!), their palette is organized in such a way
that you actually get:
3R3G2B IMGFMT_BGR8
2B3G3R IMGFMT_RGB8
1R2G1B IMGFMT_BGR4_CHAR
1B2G1R IMGFMT_RGB4_CHAR
1R2G1B1R2G1B IMGFMT_BGR4
1B2G1R1B2G1R IMGFMT_RGB4
Depending upon the CPU being little- or big-endian, different 'in memory' and
'in register' formats will be equal (LE -> BGRA == BGR32 / BE -> ARGB == BGR32)
Practical coding guide:
The 4, 8, 15, and 16 bit formats are defined so that the portable way to
access them is to load the pixel into an integer and use bitmasks.
The 24 bit formats are defined so that the portable way to access them is
to address the 3 components as separate bytes, as in ((uint8_t *)pixel)[0],
((uint8_t *)pixel)[1], ((uint8_t *)pixel)[2].
When a 32-bit format is identified by the four characters A, R, G, and B in
some order, the portable way to access it is by addressing the 4 components
as separate bytes.
When a 32-bit format is identified by the 3 characters R, G, and B in some
order followed by the number 32, the portable way to access it is to load
the pixel into an integer and use bitmasks.
When the above portable access methods are not used, you will need to write
2 versions of your code, and use #if HAVE_BIGENDIAN to choose the correct
one.

129
DOCS/OUTDATED-tech/dr-methods.txt
View File

@ -1,129 +0,0 @@
DIRECT RENDERING METHODS -- by A'rpi
======================== (based on a mail to -dev-eng)
Ok. It seems none of you really knows what direct rendering means...
I'll try to explain now! :)
At first, there are 2 different way, both called direct rendering.
The main point is the same, but they work different.
method 1: decoding directly to externally provided buffers.
so, the codec decodes macroblocks directly to the buffer provided by the
caller. as this buffer will be read later (for MC of next frame) it's not
a good idea to place such buffers in slow video ram. but.
there are many video out drivers using buffers in system ram, and using some
way of memcpy or DMA to blit it to video ram at display time.
for example, Xv and X11 (normal and Shm too) are such thingie.
XImage will be a buffer in system ram (!) and X*PutImage will copy it to
video ram. Only nvidia and ati rage128 Xv drivers use DMA, others just
memcpy it. Also some opengl drivers (including Matrox) uses DMA to copy from
texsubimage to video ram.
The current mplayer way mean: codec allocates some buffer, and decode image
to that buffer. then this buffer is copied to X11's buffer. then Xserver
copies this buffer to video ram. So one more memcpy than required...
direct rendering can remove this extra memcpy, and use Xserver's memory
buffers for decoding buffer. Note again: it helps only if the external
buffer is in fast system ram.
method 2: decoding to internal buffers, but blit after each macroblocks,
including optional colorspace conversion.
advantages: it can blit into video ram, as it keeps the copy in its internal
buffers for next frame's MC. skipped macroblocks won't be copied again to
video ram (except if video buffer address changes between frames -> hw
double/triple buffering)
Just avoiding blitting of skipped MBs mean about 100% speedup (2 times
faster) for low bitrate (<700kbit) divxes. It even makes possible to watch
VCD resolution divx on p200mmx with DGA.
how does it work? the codec works as normally, decodes macroblocks into its
internal buffer. but after each decoded macroblock, it immediatelly copies
this macroblock to the video ram. it's in the L1 cache, so it will be fast.
skipped macroblocks can be skipped easily -> less vram write -> more speedup.
but, as it copies directly to video ram, it must do colorspace conversion if
needed (for example divx -> rgb DGA), and cannot be used with scaling.
another interesting question of such direct rendering is the planar formats.
Eugene K. of Divx4 told me that he experienced worse performance blittig
yv12 blocks (copied 3 blocks to 3 different (Y,U,V) buffers) than doing
(really unneeded) yv12->yuy2 conversion on-the-fly.
so, divx4 codec (with -vc divx4 api) converts from its internal yv12 buffer
to the external yuy2.
method 2a:
libmpeg2 already uses simplified variation of this: when it finish decoding a
slice (a horizontal line of MBs) it copies it to external (video ram) buffer
(using callback to libvo), so at least it copies from L2 cache instead of
slow ram. for non-predictive (B) frames it can re-use this cached memory
for the next slice - so it uses less memory and has better cache utilization:
it gave me 23% -> 20% VOB decoding speedup on p3. libavcodec supports
per-slice callbacks too, but no slice-memory reusing for B frames yet.
method 2b:
some codecs (indeo vfw 3/4 using IF09, and libavcodec) can export the 'bitmap'
of skipped macroblocks - so libvo driver can do selective blitting: copy only
the changed macroblocks to slow vram.
so, again: the main difference between method 1 and 2:
method1 stores decoded data only once: in the external read/write buffer.
method2 stores decoded data twice: in its internal read/write buffer (for
later reading) and in the write-only slow video ram.
both methods can make big speedup, depending on codec behaviour and libvo
driver. for example, IPB mpegs could combine these, use method 2 for I/P
frames and method 1 for B frams. mpeg2dec does already this.
for I-only type video (like mjpeg) method 1 is better. for I/P type video
with MC (like divx, h263 etc) method 2 is the best choice.
for I/P type videos without MC (like FLI, CVID) could use method 1 with
static buffer or method 2 with double/triple buffering.
i hope it is clear now.
and i hope even nick understand what are we talking about...
ah, and at the end, the abilities of codecs:
libmpeg2,libavcodec: can do method 1 and 2 (but slice level copy, not MB level)
vfw, dshow: can do method 2, with static or variable address external buffer
odivx, and most native codecs like fli, cvid, rle: can do method 1
divx4: can do method 2 (with old odivx api it does method 1)
xanim: they currently can't do DR, but they exports their
internal buffers. but it's very easy to implement menthod 1 support,
and a bit harder but possible without any rewrite to do method 2.
so, dshow and divx4 already implements all requirements of method 2.
libmpeg2 and libavcodec implements method 1 and 2a (lavc 2b too)
anyway, in the ideal world, we need all codecs support both methods.
anyway 2: in ideal world, there are no libvo drivers having buffer in system
ram and memcpy to video ram...
anyway 3: in our really ideal world, all libvo driver has its buffers in
fast sytem ram and does blitting with DMA... :)
============================================================================
MPlayer NOW! -- The libmpcodecs way.
libmpcodecs replaced old draw callbacks with mpi (mplayer image) struct.
steps of decoding with libmpcodecs:
1. codec requests an mpi from libmpcodecs core (vd.c)
2. vd creates an mpi struct filled by codec's requirements (size, stride,
colorspace, flags, type)
3. vd asks libvo (control(VOCTRL_GET_IMAGE)), if it can provide such buffer:
- if it can -> do direct rendering
- it it can not -> allocate system ram area with memalign()/malloc()
Note: codec may request EXPORT buffer, it means buffer allocation is
done inside the codec, so we cannot do DR :(
4. codec decodes one frame to the mpi struct (system ram or direct rendering)
5. if it isn't DR, we call libvo's draw functions to blit image to video ram
current possible buffer setups:
- EXPORT - codec handles buffer allocation and it exports its buffer pointers
used for opendivx, xanim and libavcodec
- STATIC - codec requires a single static buffer with constant preserved content
used by codecs which do partial updating of image, but doesn't require reading
of previous frame. most rle-based codecs, like cvid, rle8, qtrle, qtsmc etc.
- TEMP - codec requires a buffer, but it doesn't depend on previous frame at all
used for I-only codecs (like mjpeg) and for codecs supporting method-2 direct
rendering with variable buffer address (vfw, dshow, divx4).
- IP - codec requires 2 (or more) read/write buffers. it's for codecs supporting
method-1 direct rendering but using motion compensation (ie. reading from
previous frame buffer). could be used for libavcodec (divx3/4,h263).
IP buffer stays from 2 (or more) STATIC buffers.
- IPB - similar to IP, but also have one (or more) TEMP buffers for B frames.
it will be used for libmpeg2 and libavcodec (mpeg1/2/4).
IPB buffer stays from 2 (or more) STATIC buffers and 1 (or more) TEMP buffer.

383
DOCS/OUTDATED-tech/libmpcodecs.txt
View File

@ -1,383 +0,0 @@
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.
The libMPcodecs API details, hints - by A'rpi
==================================
See also: colorspaces.txt, codec-devel.txt, dr-methods.txt, codecs.conf.txt
The VIDEO path:
===============
[MPlayer core]
| (1)
______V______ (2) /~~~~~~~~~~\ (3,4) |~~~~~~|
| | -----> | vd_XXX.c | -------> | vd.c |
| dec_video | \__________/ <-(3a)-- |______|
| | -----, ,.............(3a,4a).....:
~~~~~~~~~~~~~ (6) V V
/~~~~~~~~\ /~~~~~~~~\ (8)
| vf_X.c | --> | vf_Y.c | ----> vf_vo.c / ve_XXX.c
\________/ \________/
| ^
(7) | |~~~~~~| : (7a)
`-> | vf.c |...:
|______|
Short description of video path:
1. MPlayer/MEncoder core requests the decoding of a compressed video frame:
calls dec_video.c::decode_video().
2. decode_video() calls the video codec previously selected in init_video().
(vd_XXX.c file, where XXX == vfm name, see the 'driver' line of codecs.conf)
3. The codec should initialize the output device before decoding the first
frame. It may happen in init() or at the middle of the first decode(), see
3a. It means calling vd.c::mpcodecs_config_vo() with the image dimensions,
and the _preferred_ (meaning: internal, native, best) colorspace.
NOTE: This colorspace may not be equal to the colorspace that is actually
used. It's just a _hint_ for the colorspace matching algorithm and mainly
used as input format of the converter, but _only_ when colorspace
conversion is required,
3a. Selecting the best output colorspace:
The vd.c::mpcodecs_config_vo() function will go through the outfmt list
defined by the 'out' lines in codecs.conf and query both vd (codec) and
vo (output device/filter/encoder) if the format is supported or not.
For the vo, it calls the query_format() function of vf_XXX.c or ve_XXX.c.
It should return a set of feature flags, the most important ones for this
stage are: VFCAP_CSP_SUPPORTED (colorspace supported directly or by
conversion) and VFCAP_CSP_SUPPORTED_BY_HW (colorspace supported
WITHOUT any conversion).
For the vd (codec), control() with VDCTRL_QUERY_FORMAT will be called.
If it does not implement VDCTRL_QUERY_FORMAT, (i.e. answers CONTROL_UNKNOWN
or CONTROL_NA), it is assumed to be CONTROL_TRUE (colorspace supported)!
So, by default, if the list of supported colorspaces is constant and does
not depend on the actual file/stream header, then it is enough to list the
formats in codecs.conf ('out' field) and not implement VDCTRL_QUERY_FORMAT.
This is the case for most codecs.
If the supported colorspace list depends on the file being decoded, list
the possible out formats (colorspaces) in codecs.conf and implement the
VDCTRL_QUERY_FORMAT to test the availability of the given colorspace for
the given video file/stream.
The vd.c core will find the best matching colorspace, depending on the
VFCAP_CSP_SUPPORTED_BY_HW flag (see vfcap.h). If no match can be found,
it will try again with the 'scale' filter inserted between vd and vo.
If this is unsuccessful, it will fail :(
4. Requesting buffer for the decoded frame:
The codec has to call mpcodecs_get_image() with proper imgtype & imgflag.
It will find the optimal buffering setup (preferred stride, alignment etc)
and return a pointer to the allocated and filled up mpi (mp_image_t*) struct.
The 'imgtype' controls the buffering setup, i.e. STATIC (just one buffer that
'remembers' its content between frames), TEMP (write-only, full update),
EXPORT (memory allocation is done by the codec, not recommended) and so on.
The 'imgflags' set up the limits for the buffer, i.e. stride limitations,
readability, remembering content etc. See mp_image.h for the short
description. See dr-methods.txt for the explanation of buffer
importing and mpi imgtypes.
Always try to implement stride support! (stride == bytes per line)
If no stride support, then stride==bytes_per_pixel*image_width.
If you have stride support in your decoder, use the mpi->stride[] value
for the byte_per_line for each plane.
Also take care of other imgflags, like MP_IMGFLAG_PRESERVE and
MP_IMGFLAG_READABLE, MP_IMGFLAG_COMMON_STRIDE and MP_IMGFLAG_COMMON_PLANE!
The file mp_image.h contains flag descriptions in comments, read it!
Ask for help on dev-eng, describing the behavior of your codec, if unsure.
4.a. buffer allocation, vd.c::mpcodecs_get_image():
If the requested buffer imgtype!=EXPORT, then vd.c will try to do
direct rendering, i.e. ask the next filter/vo for the buffer allocation.
It's done by calling get_image() of the vf_XXX.c file.
If it was successful, the imgflag MP_IMGFLAG_DIRECT will be set, and one
memcpy() will be saved when passing the data from vd to the next filter/vo.
See dr-methods.txt for details and examples.
5. Decode the frame, to the mpi structure requested in 4., then return the mpi
to decvideo.c. Return NULL if the decoding failed or skipped the frame.
6. decvideo.c::decode_video() will now pass the 'mpi' to the next filter (vf_X).
7. The filter's (vf_X) put_image() then requests a new mpi buffer by calling
vf.c::vf_get_image().
7.a. vf.c::vf_get_image() will try to get direct rendering by asking the
next filter to do the buffer allocation (calls vf_Y's get_image()).
If it fails, it will fall back on normal system memory allocation.
8. When we're past the whole filter chain (multiple filters can be connected,
even the same filter multiple times) then the last, 'leaf' filters will be
called. The only difference between leaf and non-leaf filters is that leaf
filters have to implement the whole filter API.
Currently leaf filters are: vf_vo.c (wrapper over libvo) and ve_XXX.c
(video encoders used by MEncoder).
Video Filters
=============
Video filters are plugin-like code modules implementing the interface
defined in vf.h.
Basically it means video output manipulation, i.e. these plugins can
modify the image and the image properties (size, colorspace, etc) between
the video decoders (vd.h) and the output layer (libvo or video encoders).
The actual API is a mixture of the video decoder (vd.h) and libvo
(video_out.h) APIs.
main differences:
- vf plugins may be "loaded" multiple times, with different parameters
and context - it's new in MPlayer, old APIs weren't reentrant.
- vf plugins don't have to implement all functions - all functions have a
'fallback' version, so the plugins only override these if wanted.
- Each vf plugin has its own get_image context, and they can interchange
images/buffers using these get_image/put_image calls.
The VIDEO FILTER API:
=====================
filename: vf_FILTERNAME.c
vf_info_t* info;
pointer to the filter description structure:
const char *info; // description of the filter
const char *name; // short name of the filter, must be FILTERNAME
const char *author; // name and email/URL of the author(s)
const char *comment; // comment, URL to papers describing algorithm etc.
int (*open)(struct vf_instance *vf,char* args);
// pointer to the open() function:
Sample:
vf_info_t vf_info_foobar = {
"Universal Foo and Bar filter",
"foobar",
"Ms. Foo Bar",
"based on algorithm described at http://www.foo-bar.org",
open
};
The open() function:
open() is called when the filter is appended/inserted in the filter chain.
It'll receive the handler (vf) and the optional filter parameters as
char* string. Note that encoders (ve_*) and vo wrapper (vf_vo.c) have
non-string arg, but it's specially handled by MPlayer/MEncoder.
The open() function should fill the vf_instance_t structure with the
implemented functions' pointers (see below).
It can optionally allocate memory for its internal data (vf_priv_t) and
store the pointer in vf->priv.
The open() function should parse (or at least check syntax of) parameters,
and fail (return 0) on error.
Sample:
static int open(vf_instance_t *vf, char* args)
{
vf->query_format = query_format;
vf->config = config;
vf->put_image = put_image;
// allocate local storage:
vf->priv = malloc(sizeof(struct vf_priv_s));
vf->priv->w =
vf->priv->h = -1;
if(args) // parse args:
if(sscanf(args, "%d:%d", &vf->priv->w, &vf->priv->h)!=2) return 0;
return 1;
}
Functions in vf_instance:
NOTE: All these are optional, their function pointer is either NULL or points
to a default implementation. If you implement them, don't forget to set
vf->FUNCNAME in your open() !
int (*query_format)(struct vf_instance *vf, unsigned int fmt);
The query_format() function is called one or more times before the config(),
to find out the capabilities and/or support status of a given colorspace (fmt).
For the return values, see vfcap.h!
Normally, a filter should return at least VFCAP_CSP_SUPPORTED for all supported
colorspaces it accepts as input, and 0 for the unsupported ones.
If your filter does linear conversion, it should query the next filter,
and merge in its capability flags. Note: You should always ensure that the
next filter will accept at least one of your possible output colorspaces!
Sample:
static int query_format(struct vf_instance *vf, unsigned int fmt)
{
switch(fmt){
case IMGFMT_YV12:
case IMGFMT_I420:
case IMGFMT_IYUV:
case IMGFMT_422P:
return vf_next_query_format(vf,IMGFMT_YUY2) & (~VFCAP_CSP_SUPPORTED_BY_HW);
}
return 0;
}
For the more complex case, when you have an N -> M colorspace mapping matrix,
see vf_scale or vf_format for examples.
int (*config)(struct vf_instance *vf,
int width, int height, int d_width, int d_height,
unsigned int flags, unsigned int outfmt);
The config() is called to initialize/configure the filter before using it.
Its parameters are already well-known from libvo:
width, height: size of the coded image
d_width, d_height: wanted display size (usually aspect corrected w/h)
Filters should use width, height as input image dimension, but the
resizing filters (crop, expand, scale, rotate, etc) should update
d_width/d_height (display size) to preserve the correct aspect ratio!
Filters should not rely on d_width, d_height as input parameters,
the only exception is when a filter replaces some libvo functionality
(like -vf scale with -zoom, or OSD rendering with -vf expand).
flags: the "good" old libvo flag set:
0x01 - force fullscreen (-fs)
0x02 - allow mode switching (-vm)
0x04 - allow software scaling (-zoom)
0x08 - flipping (-flip)
(Usually you don't have to worry about flags, just pass it to next config.)
outfmt: the selected colorspace/pixelformat. You'll receive images in this
format.
Sample:
static int config(struct vf_instance *vf,
int width, int height, int d_width, int d_height,
unsigned int flags, unsigned int outfmt)
{
// use d_width/d_height if not set by the user:
if (vf->priv->w == -1)
vf->priv->w = d_width;
if (vf->priv->h == -1)
vf->priv->h = d_height;
// initialize your filter code
...
// OK now config the rest of the filter chain, with our output parameters:
return vf_next_config(vf,vf->priv->w,vf->priv->h,d_width,d_height,flags,outfmt);
}
void (*uninit)(struct vf_instance *vf);
Okay, uninit() is the simplest, it's called at the end. You can free your
private buffers etc here.
int (*put_image)(struct vf_instance *vf, mp_image_t *mpi);
Ah, put_image(). This is the main filter function, it should convert/filter/
transform the image data from one format/size/color/whatever to another.
Its input parameter is an mpi (mplayer image) structure, see mp_image.h.
Your filter has to request a new image buffer for the output, using the
vf_get_image() function. NOTE: Even if you don't want to modify the image,
just pass it to the next filter, you have to either
- not implement put_image() at all - then it will be skipped
- request a new image with type==EXPORT and copy the pointers
NEVER pass the mpi as-is, it's local to the filters and may cause trouble.
If you completely copy/transform the image, then you probably want this:
dmpi = vf_get_image(vf->next,mpi->imgfmt, MP_IMGTYPE_TEMP,
MP_IMGFLAG_ACCEPT_STRIDE, vf->priv->w, vf->priv->h);
It will allocate a new image and return an mp_image structure filled by
buffer pointers and stride (bytes per line) values, in size of vf->priv->w
times vf->priv->h. If your filter cannot handle stride, then leave out
MP_IMGFLAG_ACCEPT_STRIDE. Note that you can do this, but it isn't recommended,
the whole video path is designed to use strides to get optimal throughput.
If your filter allocates output image buffers, then use MP_IMGTYPE_EXPORT
and fill the returned dmpi's planes[], stride[] with your buffer parameters.
Note, it is not recommended (no direct rendering), so if you can, use
vf_get_image() for buffer allocation!
For other image types and flags see mp_image.h, it has comments.
If you are unsure, feel free to ask on the dev-eng mailing list. Please
describe the behavior of your filter, and its limitations, so we can
suggest the optimal buffer type + flags for your code.
Now that you have the input (mpi) and output (dmpi) buffers, you can do
the conversion. If you didn't notice yet, mp_image has some useful info
fields. They may help you a lot creating if() or for() structures:
flags: MP_IMGFLAG_PLANAR, MP_IMGFLAG_YUV, MP_IMGFLAG_SWAPPED
helps you to handle various pixel formats in single code.
bpp: bits per pixel
WARNING! It's number of bits _allocated_ to store a pixel,
it is not the number of bits actually used to keep colors!
So it's 16 for both 15 and 16 bit color depth, and is 32 for
32bpp (actually 24 bit color depth) mode!
It's 1 for 1bpp, 9 for YVU9, and is 12 for YV12 mode. Get it?
For planar formats, you also have chroma_width, chroma_height and
chroma_x_shift, chroma_y_shift too, they specify the chroma subsampling
for YUV formats:
chroma_width = luma_width >> chroma_x_shift;
chroma_height = luma_height >> chroma_y_shift;
If you're done, call the rest of the filter chain to process your output
image:
return vf_next_put_image(vf,dmpi);
Ok, the rest is for advanced functionality only:
int (*control)(struct vf_instance *vf, int request, void* data);
You can control the filter at runtime from MPlayer/MEncoder/dec_video:
#define VFCTRL_QUERY_MAX_PP_LEVEL 4 /* test for postprocessing support (max level) */
#define VFCTRL_SET_PP_LEVEL 5 /* set postprocessing level */
#define VFCTRL_SET_EQUALIZER 6 /* set color options (brightness,contrast etc) */
#define VFCTRL_GET_EQUALIZER 8 /* get color options (brightness,contrast etc) */
#define VFCTRL_DRAW_OSD 7
void (*get_image)(struct vf_instance *vf, mp_image_t *mpi);
This is for direct rendering support, works the same way as in libvo drivers.
It makes in-place pixel modifications possible.
If you implement it (vf->get_image!=NULL), then it will be called to do the
buffer allocation. You SHOULD check the buffer restrictions (stride, type,
readability etc) and if everything is OK, then allocate the requested buffer
using the vf_get_image() function and copying the buffer pointers.
NOTE: You HAVE TO save the dmpi pointer, as you'll need it in put_image()
later on. It is not guaranteed that you'll get the same mpi for put_image() as
in get_image() (think of out-of-order decoding, get_image is called in decoding
order, while put_image is called for display) so the only safe place to save
it is in the mpi struct itself: mpi->priv=(void*)dmpi;
void (*draw_slice)(struct vf_instance *vf, unsigned char** src,
int* stride, int w,int h, int x, int y);
It's the good old draw_slice callback, already known from libvo.
If your filter can operate on partial images, you can implement this one
to improve performance (cache utilization).
Ah, and there are two sets of capability/requirement flags (vfcap.h type)
in vf_instance_t, used by the default query_format() implementation, and by
the automatic colorspace/stride matching code (vf_next_config()).
// caps:
unsigned int default_caps; // used by default query_format()
unsigned int default_reqs; // used by default config()
BTW, you should avoid using global or static variables to store filter instance
specific stuff, as filters might be used multiple times and in the future even
multiple streams might be possible.
The AUDIO path:
===============
TODO!!!

283
DOCS/OUTDATED-tech/manpage.txt
View File

@ -1,283 +0,0 @@
========================================
A documentation about MPlayer's man page
========================================
About the documentation
-----------------------
Yes it's true: This is the documentation of the documentation (man page).
This guide should be used as a reference for questions about the man page
structure. It's not a strict guide but we recommend following it to get a
uniform man page.
What belongs in the man page?
-----------------------------
- option descriptions (all)
- usage (options, configuration files, controls)
- basic examples
What doesn't belong in the man page?
------------------------------------
- instructions for installation, encoding and similar processes
- detailed evaluations or hints
- tutorials, guides
How should patches look like?
-----------------------------
Follow the rules in patches.txt, they apply to the man page, too.
Exceptions are:
- Cosmetic patches are allowed but should be done separately from the real
changes, be marked as cosmetic changes and shouldn't change the general
style without reasons/permissions.
- The same applies to spell checking.
How do I create an HTML, text or other version of the man page?
---------------------------------------------------------------
The man page was more or less designed for groff as it is the main tool for
it. Therefore only groff produces acceptable results without changes.
Additionally, the SS variable should be set to either very low or very high
values to produce a better groff HTML output (Due to a bug of groff2html?).
A setting of 4 should look readable. Here's an overview again:
- groff:
groff is the "official" tool to convert man pages. To get good results you
need a recent version (1.18.2).
groff -mman -Thtml mplayer.1 > mplayer.1.html
groff -mman -Tlatin1 -rLL=78n mplayer.1 | col -bxp > mplayer.1.txt
The groff man page lists other output formats to use with -T.
Unfortunately groff is not able to handle UTF-8 input as of version 1.19.2.
groff-utf8 is a wrapper that works around these deficiencies:
http://www.haible.de/bruno/packages-groff-utf8.html
- man2html:
You can view it through a CGI script:
http://localhost/cgi-bin/man2html?mplayer
The output is unusable as the script doesn't seem to support the macro
definitions. Maybe manually changing all leads to acceptable results.
- rman:
rman -f html mplayer.1 > man_page.rman.html
The output is ugly as rman doesn't understand many of the macros used.
- troffcvt:
troff2html -man mplayer.1 > man_page.tcvt.html
The (good) output is similar to groff but simplified...
The structure
-------------
The option descriptions are divided into sections. Inside a section options are
alphabetically sorted. The sections are:
(Header)
not visible, copyright and author information
(Macro definitions)
not visible, some macro definitions
NAME
The man page is used for both mplayer and mencoder.
SYNOPSIS
a description of MPlayer's playtree
DESCRIPTION
a general description of MPlayer, MEncoder, GMPlayer and their features
INTERACTIVE CONTROL
description of MPlayer's input system and interactive controls
USAGE
some general notes about usage
CONFIGURATION FILES
description of the configuration file format
GENERAL OPTIONS
General options that are common to both MPlayer and MEncoder.
PLAYER OPTIONS (MPLAYER ONLY)
user interface option descriptions (MPlayer only)
DEMUXER/STREAM OPTIONS
demuxer and stream layer option descriptions
OSD/SUBTITLE OPTIONS
This section is special in that it contains all subtitle and OSD option
descriptions even if they might belong to one of the other sections. It
was created because of its size.
AUDIO OUTPUT OPTIONS (MPLAYER ONLY)
audio output layer (ao) option descriptions (MPlayer only)
AUDIO OUTPUT DRIVERS (MPLAYER ONLY)
audio output driver description (ao)
VIDEO OUTPUT OPTIONS (MPLAYER ONLY)
video output layer (vo) option descriptions (MPlayer only)
VIDEO OUTPUT DRIVERS (MPLAYER ONLY)
video output driver description (vo)
DECODING/FILTERING OPTIONS
decoding/filtering layer options (ad, vd, pl)
VIDEO FILTERS
video filter description (vf)
GENERAL ENCODING OPTIONS (MENCODER ONLY)
Encoding option descriptions (ve) (MEncoder only).
CODEC SPECIFIC ENCODING OPTIONS (MENCODER ONLY)
Codec specific option descriptions (lavc,divx4,xvid,lame) (MEncoder only).
FILES
a list and description of all installed/used files/directories
EXAMPLES OF MPLAYER USAGE
basic examples, again: no long descriptions/processes
EXAMPLES OF MENCODER USAGE
basic examples, again: no long descriptions/processes
BUGS
AUTHORS
The man page/groff format
-------------------------
Just read this and RTFS:
man 7 roff
http://www.tldp.org/HOWTO/mini/Man-Page.html
man 7 man
man 7 groff
"Style" guidelines
------------------
This section was kept simple but there are certain guidelines/rules to get a
uniform man page. The best way is to read (and understand) the source.
General:
- No line should contain more than 79 characters.
- used commands: .TH, .SH, .TP, .IP, .PP, .[R]B, .I, .br, .RS, .RE, .na,
.nh, .ad, .hy, macro definitions, comments and some more
- Don't forget the quotation marks around expressions, etc...
- Each new sentence should start on a line of its own.
- There is a typographical difference between a hyphen, a minus and an
en-dash or em-dash. For the man page this means that you should put a
backslash before a '-' if it denotes a range (1\-10), an option (\-fs),
stdin (\-), a dash (mplayer \- movie player) or a minus (\-1). Use just
'-' if it is a hyphen (A-V).
- Don't start a line with "'" or ".", nroff treats them specially.
- To quickly check a manual page for markup errors, just run
man DOCS/man/XX/mplayer.1 > /dev/null
Option descriptions:
- Options should be in alphabetical order.
- Option and/or suboption parameters should be short, descriptive and put
in angular brackets (e.g. \-vo <driver>).
- If the option has a parameter in a certain range, specify it right after
the option (e.g. \-subpos <0\-100>).
- Optional things should be put in square brackets ([]).
- Obsolete options are followed by (OBSOLETE), beta options by
(BETA CODE), etc.
- MPlayer-only options in a section which isn't marked this way
are followed by (MPlayer only).
- Add references to other options if they belong to each other, e.g.
'(\-vo zr only)' or '(also see \-alang)' or are commonly used together.
- If a nontrivial default parameter exists, mention it, e.g. (default: 24).
- Put examples and notes at the end of the description (before suboptions).
- The end of the suboptions _always_ has to be followed by a paragraph
(BUG).
- For flag options just document the non-default one of \-XXX and \-noXXX.
If the option is not a flag, describe both, one below the other (this is
an exception to the alphabetical order).
Macro definitions (see beginning of man page):
- .SS starting value of the suboption column
- .IPs Add new suboption (we use .TP for normal options and .IP for
the rest).
- .RSs begin of suboptions, end with .RE
- .RSss begin of suboptions in a suboption
- .REss end of suboptions in a suboption
Options, suboptions, examples structure:
- Normal options (note the '<' and '>'):
[...]
.TP
.B \-option <parameter>
description
[...]
- Long suboptions:
[...]
description. Available options are:
.
.RSs
.IPs "subopt1=<value>"
description1
.IPs "subopt2=<value>"
description2
[...]
.IPs "last subopt=<value>"
last description
.RE
.
[...]
- Short suboptions:
[...]
description. Available options are:
.PD 0
.RSs
.IPs "subopt1=<value>"
description1
.IPs "subopt2=<value>"
description2
[...]
.IPs "last subopt=<value>"
last description
.RE
.PD 1
.
[...]
- Suboptions in suboptions:
[...]
.IPs "subopt1=<value>"
description1
.RSss
subsubopt1: description1
.br
subsubopt2: description2
[...]
.REss
[...]
- Examples:
[...]
.I EXAMPLE:
.PD 0
.RSs
.IP "\-option used parameters"
description
[...]
.RE
.PD 1
.
[...]

22
DOCS/OUTDATED-tech/realcodecs/TODO
View File

@ -1,22 +0,0 @@
TODO:
- more docs are coming as I find the time to write them down
- use RV20toYUV420Free()
- audio support - nearly DONE (look below)
- internet streaming support
- searching - we need to take care of the audio interleaving -
haven't taken steps to locate audio key frames (does such thing
exist?)
- some media files can't be played (mplayer crashes/fails) because
it asks for decoded audio data, but the buffer in the audio
demuxer packets are empty/missing. It seems that the necessary
audio packets haven't been decoded completely (incomplete interleaving)
the audio stream packets may get mixed with video stream packet - DONE ???
- put variables for audio streaming inside real_priv_t
- audio support for other formats than COOK - use a switch
(like -forcereal) to activate it - no switch needed, win32 codecs
doens't work (it was a nonworking attempt)
- postprocessing support (see rp8 preferences->performance->cpu usage,
also statistics->streams->video->POST FILTER: ON
(i've found that custommessage calls differ wiht pp on/off, but adding
these calls to mplayer didn't make a pixel difference between outputs)

155
DOCS/OUTDATED-tech/realcodecs/audio-codecs.txt
View File

@ -1,155 +0,0 @@
all audio codecs (cook,atrk,14_4,28_8,dnet,sipr) have the same interface,
but i have only analyzed the cook codec
audio properties (hex)
00 short text/description of the format (bitrate, when to use)
01 bitrate (bits/s) //avg. bytes/sec output
02 ulong: ?
ulong: samples per second
ushort: bits/sample
ushort: number of channels
03 same as 02 //constant 2
04 long description
05 constant 1 (always?)
06 ulong: block align (input frame size for RADecode)
07 string: minimum player version
08 n/a
09 n/a
0A n/a
0B n/a
0C n/a
0D ?
0E ? leaf size
0F ?
10 ?
11 ?
12 ?
13 min. output buffer size? max. number of samples?
14 ?
functions:
ulong result=RAOpenCodec2(ra_main_t *raMain);
ulong result=RAInitDecoder(ra_main_t *raMain, ra_init_struct *raInit);
struct ra_init_struct {
ulong sample_rate;
ushort bits_per_sample; // unused by RAInitDecoder
ushort number_of_channels;
ushort unknown1; // 0
ushort unknown2; // also unused (100)
ulong leaf_size; // leaf size (used for interleaving, but
// exists in audio stream description header (ASDH))
ulong block_align; // packet size
ulong bits_per_sample; // unused (always 16)
char *ext_data; // 16 bytes located at the end of the
// ASDH
};
There are some information missing that you usually need for playback,
like bits per sample (the fileds aren't read by RAInitDecoder()). These
are hard coded in the "flavors", i.e. the sub formats. A flavor is an entry
in the list of available format variations like bitrate, number of channels,
decoding algorithm, and so on.We can get those information with the
following command:
void *GetRAFlavorProperty(ra_main_t *raMain, ulong flavor, ulong property,
short *property_length_in_bytes);
returns property data for a specific data
This is not important, because it's just a read only function.
These flavor properties don't seem to exist in
ulong RADecode(ra_main_t *raMain, char *input_buffer,
ulong input_buffer_size, char *output_buffer,
ulong *decoded_bytes, ulong p6=-1);
RAFreeDecoder(ra_main_t *);
RACloseCodec(ra_main_t *);
ulong RASetFlavor(ra_main_t *ra_main, ulong flavor);
Set the flavor of the stream.
a flavor is an entry in the list of available format variations like
bitrate, number of channels, decoding algorithm, and so on
audio data storage:
-------------------
With Real Audio V5 (or earlier?), the audio streams can be interleaved,
i.e. the stream is striped amongst several data packets. The packets
(which have a fixed size packet_len) are split up into a fixed number
of num_parts equally sized parts - I call them leaves in lack of
better name. The leaves have the size leaf_size = packet_len / num_parts.
To create a bunch of packets, you need 2*num_parts stream packets.
The first part of the first stream packet is stored in leaf number 0,
the first part of the second into leaf number num_parts, the one of the
next one into leaf number 1 etc. The following part of a stream packet
is stored 2*num_packets behind the current part of the same stream packet.
In short words: when you have a matrix with the leaves as the values,
it's a transposition in conjunction with a permutation.
packet | leaf | stream packet, part no.
-------+---------------+------------------------
0 | 0 | (0,0)
0 | 1 | (2,0)
. | . | .
. | . | .
0 | num_parts-1 | (2*num_parts-2,0)
0 | num_parts | (1,0)
0 | num_parts+1 | (3,0)
. | . | .
. | . | .
0 | 2*num_parts-1 | (2*num_parts-1,0)
1 | 0 | (0,1)
. | . | .
. | . | .
sequence of calls:
------------------
RAOpenCodec2()
RAInitDecoder()
RASetFlavor()
RAGetFlavorProperty(0xE)
sequence of RADecode()s
once a RAGetFlavorProperty(0xE) after some RADecode()s
and occasionally the following sequence:
RAGetFlavorProperty(0)
RAGetFlavorProperty(7)
which is rather pointless because they only return
cleartext audio descriptions
RAFreeDecoder()
RACloseCodec()
RAFlush(ra_main_t *raMain, char *output_buffer, ulong *retval)
will be called when seeking
output_buffer points to the output buffer from the last
decode operation.
retval is unknown, returning always 0x18 in a specific sample
-> further investigation needed

58
DOCS/OUTDATED-tech/realcodecs/streaming.txt
View File

@ -1,58 +0,0 @@
In the RV30 format, another encapsulated data layer for the video stream
has been introduced. In lack of a name I'll call them sub packets, the
normal packets which exist in RV10 I'll call - well - packets. The stream
of bytes which is put in one memory block is named block.
The format extension has been * by wild guessing and comparing the
received data between the original viewer and the demuxer.
Every packet may contain one or more sub packets, and one block may
be contained inside one or more adjacent (sub) packets.
A sub packet (fragment) starts with a small header (two letters are one byte):
aa(bb)[cccc{gggg}dddd{eeee}ff]
aa: indicates the type of header
the 2MSB indicate the header type (mask C0)
C0: the [] part exists, but not () -> whole packet (not fragmented)
00, 80: the data block is encapsulated inside multiple packets.
bb contains the sequence number, beginning with 1.
80 indicates the last sub packet containing data for the
current block. no C0 or 40 sub packet follows until
the block has been finished with a 80 sub packet.
No packet with another stream than the current video stream
is inside the sub packet chain, at least I haven't seen
such case - the demuxer will shout in this case.
40: [] does not exist, the meaning of bb is unknown to me
data follows to the end of the packet
mask 3F: unknown
bb: sub-seq - mask 0x7f: the sequence number of the _fragment_
mask 0x80: unknown, seems to alternating between 00 and 80
cccc: mask 3FFF: _total_ length of the packet
mask C000: unknown, seems to be always 4000
when it's all 0000, it indicates value >=0x4000, you should read {gggg}
and use all 16 bits of it. dunno what happens when length>=65536...
dddd: when it's 0, {} exists (only in this case)
mask 3FFF: offset of fragment inside the whole packet. it's counted
from the beginning of the packet, except when hdr&0x80,
hten it's relative to the _end_ of the packet, so it's
equal to fragment size!
mask C000: like cccc, except the first case (always 4000)
when it's all 0000, it indicates value >=0x4000, you should read {eeee}
and use all 16 bits of it. dunno what happens when length>=65536...
ff: sequence number of the assembled (defragmented) packets, beginning with 0
NOTE: the demuxer should build a table of the subpacket offsets relative to the
start of whole packet, it's required by the rv20/rv30 video decoders.
packet header:
ushort unknown
ulong blocksize
ushort streamid
uchar reserved
uchar flags 1=reliable, 2=keyframe

185
DOCS/OUTDATED-tech/realcodecs/video-codecs.txt
View File

@ -1,185 +0,0 @@
The work has been based on the RV30 codec, but since RV20 has the same
interface, it might work for it as well.
error codes (the software uses redmond originated error codes)
1. internal code (1-10)
2. result
0 00000000 success
1 80004005 E_FAIL
2 8007000E E_OUTOFMEMORY
3,9 80004001 E_NOTIMPL
4,5 80070005 E_ACCESSDENIED
6 80004003 E_POINTER
7,10 80070057 E_INVALIDREG
8 80040FC1 (or 1FC?: CO_E_OBJISREG) - never occurred here
I think the only relevant file is the decoder drv[23].so.6.0
The rv[23]0 ones are just for streaming. We do this ourselves.
The codec consists of several functions. The relevant ones are:
RV20toYUV420Init()
RV20toYUV420Transform()
RV20toYUV420CustomMessage()
RV20toYUV420Free()
The others are irrelevant (seems to me). HiveMessage doesn't manipulate
anything and is only called in the beginning.
result=RV20toYUV420Init(struct init_data *, struct rvyuvMain **);
struct init_data {
short constant=0xb;
short width, height;
short 0, 0, 0;
ulong format1;
long 1;
ulong format2;
};
format1 and format2 are stored in the .rm file's stream headers.
(format1>>16)&3 seems to be a sub-codec id/selector, at least for rv30
it's the only difference between low and high bitrate files.
result=RV20toYUV420Transform(char *input_stream, char *output_data,
struct transin *, struct transout *, struct rvyuvMain *);
struct transin {
ulong length_of_input_data;
ulong null;
ulong num_sub_packets_in_block_minus_one;
ulong *sub_packets_list;
ulong another_null;
ulong timestamp_from_stream;
};
struct transout {
ulong flag1; // ((var_94&2!=0)&&(result==0))?1:0
ulong flag2; // 4 LBS from var_94
ulong zero;
ulong width, height;
};
The length of output_stream is 1.5*width*height (I420 planar yuv 4:2:0).
input_stream is the exact data from the data block for one frame.
sub_packets_list is a list of num_sub_packets pairs of long values, in form:
1, 0,
1, offset_2nd,
1, offset_3rd,
1, offset_4th,
...
where offset_* are the offsets or sub-packets relative to input_stream.
result=RV20toYUV420CustomMessage(ulong *msg, struct rvyuvMain *);
Messages used by RV30:
A message is a triplet (cmd,val,ext) of ulong.
NOTE:
rv30 only requires the (0x24,2|3,{w,h,w,h}) message. others can be left out!
rv20 only requires the (0x11,2,0) message in rp8, before each transform call.
(3,2,0)
returns always(?) an error, since a global variable inside the codec
(which points to a function similar to custommessage), is always NULL
(0x11,0|1|2,0)
val=0|1: sets intern2 to val, when intern1 is non-zero
return 3 when intern1 is zero and val is 1
else returns 0
val=2: return intern2
what does intern[1,2] mean?
(0x12,...)
used by rv20, function unknown, can be ignored
(0x1e,2|3,1)
calls a subroutine and returns the result, purpose has to be detemined
(0x24,subcodec,{...})
copies 4 dwords to rvyuvMain+07c: { width, height, 0, 0 }
subcodec must be 2 (low-bitrate) or 3 (high-bitrate) for rv30.
the codec type (low vs high) can be determined from 1+((format1>>16)&3)
for rv20, this call should be ignored! (makes codec crashing)
(0x1c,a,b) - called inside transform
to be analyzed
(105,...)
used by rv20, function unknown, can be ignored
structure of rvyuvMain:
-----------------------
DWORDS (the entries are not always constant)
there are two w/h pairs at 05C. the first is the size of the
unscaled video stream, the second possibly image size
000 1 6 3 1
010 1 0 AEBFC0D1(magic) 0
020 0 ptr->? 0 0
030 0 0 ->rvyuvMain+0x050 ?
040 width height 0x17 0x479
050 ->rvyuvMain 0x17 0x17 width
060 height width height 0
070 0 1 0 0
080 0 0xb w h
090 w h 0 0
0A0 1 0xb0(w?) 0x58 0x58
0B0 ptr->? 0 0 1
0C0 0x32 1 0 0
0D0 0 0 0 0
0E0 0 0 0 0
0F0 0 0 0 0
100 0 0 0 0
110 p p p p p are pointers to several function, for
120 p p p p example to the actual public functions
130 p p p p (except init, the others are some kind of
140 p p p p interfaces)
150 p 0 0 0
160 0 0x2000 1 0
170 0 0 0 0
180 1 1 0 0
190 0 0 0 0
1A0 0 0 0 0
1B0 1 0 ptr->? ptr->?
1C0 1 0 0 0
1D0 0 0 0 0
1E0 0 0 0 0
...
Order of calls:
---------------
Init
(0x11,0,0)
(0x24,2,{...})
[
(3,2,0)->80004001
(0x11,1,0)
(0x1e,3,1)
Transform (internally calls (0x1c,x,y))
(11,2,0)
]
Free

592
DOCS/OUTDATED-tech/slave.txt
View File

@ -1,592 +0,0 @@
SLAVE MODE PROTOCOL
-------------------
The -slave option switches on slave mode, in which MPlayer works as a backend
for other programs. Instead of intercepting keyboard events, MPlayer will read
commands separated by a newline (\n) from stdin.
To try slave mode out by hand, run
mplayer -slave -quiet <movie>
and type slave commands into the console window.
You can also use a fifo file (named pipe):
mkfifo </tmp/fifofile>
mplayer -slave -input file=</tmp/fifofile> <movie>
Most slave mode commands are equivalent to command line options, though not
necessarily under the same name. Detailed descriptions can be found in the
man page.
NOTE: the following paragraph is mostly obsolete; tricky pause handling
was required in old MPlayer versions where all commands unpaused by default.
Now running commands does not require leaving pause state any more, and
the prefixes described here should not be required in normal use.
All commands can be prefixed with one of "pausing ", "pausing_keep ", or
"pausing_toggle ". "pausing " tells MPlayer to pause as soon as possible
after processing the command. "pausing_keep " tells MPlayer to do so only if
it was already in paused mode. "pausing_toggle " tells MPlayer to do so
only if it was not already in paused mode. Please note that "as soon as
possible" can be before the command is fully executed.
As a temporary hack, there is also the _experimental_ "pausing_keep_force "
prefix, with which MPlayer will not exit the pause loop at all.
Like this you can avoid the "frame stepping" effect of "pausing_keep "
but most commands will either not work at all or behave in unexpected ways.
For "set_mouse_pos" and "key_down_event", "pausing_keep_force" is the default
since other values do not make much sense for them.
Various tips and tricks (please help expand it!):
- To ensure the user can't control MPlayer "behind your back" use
something like -input nodefault-bindings -noconfig all
Available commands ('mplayer -input cmdlist' will print a list):
af_add <filter_arguments_list> (comma separated list of audio filters with parameters)
(experimental) Load the given list of audio filters.
af_clr
(experimental) Unload all loaded audio filters.
af_cmdline <filter_name> <filter_arguments>
(experimental) Send new command-line options to a filter with the given name.
af_del <filter_name_list> (comma separated list of audio filter's names)
(experimental) Unload the first occurrence of the filters, if loaded.
af_switch <filter_arguments_list> (comma separated list of audio filters with parameters)
(experimental) Remove all the audio filters and replace them with the given list.
alt_src_step <value> (ASX playlist only)
When more than one source is available it selects the next/previous one.
audio_delay <value> [abs]
Set/adjust the audio delay.
If [abs] is not given or is zero, adjust the delay by <value> seconds.
If [abs] is nonzero, set the delay to <value> seconds.
[brightness|contrast|gamma|hue|saturation] <value> [abs]
Set/adjust video parameters.
If [abs] is not given or is zero, modifies parameter by <value>.
If [abs] is non-zero, parameter is set to <value>.
<value> is in the range [-100, 100].
capturing [value]
Toggle/set capturing the primary stream like -dumpstream.
Requires the -capture parameter to be given.
change_rectangle <val1> <val2>
Change the position of the rectangle filter rectangle.
<val1>
Must be one of the following:
0 = width
1 = height
2 = x position
3 = y position
<val2>
If <val1> is 0 or 1:
Integer amount to add/subtract from the width/height.
Positive values add to width/height and negative values
subtract from it.
If <val1> is 2 or 3:
Relative integer amount by which to move the upper left
rectangle corner. Positive values move the rectangle
right/down and negative values move the rectangle left/up.
dvb_set_channel <channel_number> <card_number>
Set DVB channel.
dvdnav <button_name>
Press the given dvdnav button.
up
down
left
right
menu
select
prev
mouse
edl_mark
Write the current position into the EDL file.
frame_drop [value]
Toggle/set frame dropping mode.
get_audio_bitrate
Print out the audio bitrate of the current file.
get_audio_codec
Print out the audio codec name of the current file.
get_audio_samples
Print out the audio frequency and number of channels of the current file.
get_file_name
Print out the name of the current file.
get_meta_album
Print out the 'Album' metadata of the current file.
get_meta_artist
Print out the 'Artist' metadata of the current file.
get_meta_comment
Print out the 'Comment' metadata of the current file.
get_meta_genre
Print out the 'Genre' metadata of the current file.
get_meta_title
Print out the 'Title' metadata of the current file.
get_meta_track
Print out the 'Track Number' metadata of the current file.
get_meta_year
Print out the 'Year' metadata of the current file.
get_percent_pos
Print out the current position in the file, as integer percentage [0-100).
get_property <property>
Print out the current value of a property.
get_sub_visibility
Print out subtitle visibility (1 == on, 0 == off).
get_time_length
Print out the length of the current file in seconds.
get_time_pos
Print out the current position in the file in seconds, as float.
get_vo_fullscreen
Print out fullscreen status (1 == fullscreened, 0 == windowed).
get_video_bitrate
Print out the video bitrate of the current file.
get_video_codec
Print out the video codec name of the current file.
get_video_resolution
Print out the video resolution of the current file.
screenshot <each_frame> <full_window>
Take a screenshot. Requires the screenshot filter to be loaded.
each_frame:
0 Take a single screenshot. (Default.)
1 Start/stop taking screenshot of each frame.
full_window:
0 Save the video image, in its original resolution. Typically without
OSD or subtitles. (Default.)
1 Save the contents of the mplayer window. Typically with OSD and
subtitles. If not available (no VO support), this may act as if 0 was
passed.
key_down_event <value>
Inject <value> key code event into MPlayer.
loadfile <file|url> <append>
Load the given file/URL, stopping playback of the current file/URL.
If <append> is nonzero playback continues and the file/URL is
appended to the current playlist instead.
loadlist <file> <append>
Load the given playlist file, stopping playback of the current file.
If <append> is nonzero playback continues and the playlist file is
appended to the current playlist instead.
loop <value> [abs]
Adjust/set how many times the movie should be looped. -1 means no loop,
and 0 forever.
mute [value]
Toggle sound output muting or set it to [value] when [value] >= 0
(1 == on, 0 == off).
osd [level]
Toggle OSD mode or set it to [level] when [level] >= 0.
osd_show_progression
Show the progression bar, the elapsed time and the total duration of the
movie on the OSD.
osd_show_property_text <string> [duration] [level]
Show an expanded property string on the OSD, see -playing-msg for a
description of the available expansions. If [duration] is >= 0 the text
is shown for [duration] ms. [level] sets the minimum OSD level needed
for the message to be visible (default: 0 - always show).
osd_show_text <string> [duration] [level]
Show <string> on the OSD.
panscan <-1.0 - 1.0> | <0.0 - 1.0> <abs>
Increase or decrease the pan-and-scan range by <value>, 1.0 is the maximum.
Negative values decrease the pan-and-scan range.
If <abs> is != 0, then the pan-and scan range is interpreted as an
absolute range.
pause
Pause/unpause the playback (use "set_property pause X" to set a particular
value regardless of whether the player is already paused or not).
frame_step
Play one frame, then pause again.
pt_step <value> [force]
Go to the next/previous entry in the playtree. The sign of <value> tells
the direction. If no entry is available in the given direction it will do
nothing unless [force] is non-zero.
pt_up_step <value> [force]
Similar to pt_step but jumps to the next/previous entry in the parent list.
Useful to break out of the inner loop in the playtree.
quit [value]
Quit MPlayer. The optional integer [value] is used as the return code
for the mplayer process (default: 0).
radio_set_channel <channel>
Switch to <channel>. The 'channels' radio parameter needs to be set.
radio_set_freq <frequency in MHz>
Set the radio tuner frequency.
radio_step_channel <-1|1>
Step forwards (1) or backwards (-1) in channel list. Works only when the
'channels' radio parameter was set.
radio_step_freq <value>
Tune frequency by the <value> (positive - up, negative - down).
run <value>
Run <value> as shell command.
seek <value> [type] [hr-seek]
Seek to some place in the movie.
type = 0 is a relative seek of +/- <value> seconds (default).
type = 1 is a seek to <value> % in the movie.
type = 2 is a seek to an absolute position of <value> seconds.
The hr-seek parameter controls whether to use precise seeks (not limited
to keyframe positions in video).
hr-seek = 0 means use default set with option -hr-seek (default).
hr-seek = 1 means force precise seek if possible.
hr-seek = -1 means force non-precise seek.
seek_chapter <value> [type]
Seek to the start of a chapter.
0 is a relative seek of +/- <value> chapters (default).
1 is a seek to chapter <value>.
switch_angle <value>
Switch to the angle with the ID [value]. Cycle through the
available angles if [value] is omitted or negative.
set_mouse_pos <x> <y>
Tells MPlayer the coordinates of the mouse in the window.
This command doesn't move the mouse!
set_property <property> <value>
Set a property.
set_property_osd <property> <value>
Same as above, but show the new value on the OSD in the standard
manner defined for that property (if any).
speed_incr <value>
Add <value> to the current playback speed.
speed_mult <value>
Multiply the current speed by <value>.
speed_set <value>
Set the speed to <value>.
step_property <property> [value] [direction]
Change a property by value, or increase by a default if value is
not given or zero. The direction is reversed if direction is less
than zero.
step_property_osd <property> [value] [direction]
Same as above, but show the new value on the OSD in the standard
manner defined for that property (if any).
stop
Stop playback.
sub_alignment [value]
Toggle/set subtitle alignment.
0 top alignment
1 center alignment
2 bottom alignment
sub_delay <value> [abs]
Adjust the subtitle delay by +/- <value> seconds or set it to <value>
seconds when [abs] is nonzero.
sub_load <subtitle_file>
Loads subtitles from <subtitle_file>.
sub_log
Logs the current or last displayed subtitle together with filename
and time information to ~/.mplayer/subtitle_log. Intended purpose
is to allow convenient marking of bogus subtitles which need to be
fixed while watching the movie.
sub_pos <value> [abs]
Adjust/set subtitle position.
sub_remove [value]
If the [value] argument is present and non-negative, removes the subtitle
file with index [value]. If the argument is omitted or negative, removes
all subtitle files.
sub_select [value]
Display subtitle with index [value]. Turn subtitle display off if
[value] is -1 or greater than the highest available subtitle index.
Cycle through the available subtitles if [value] is omitted or less
than -1 (forward or backward respectively).
Supported subtitle sources are -sub options on the command
line, VOBsubs, DVD subtitles, and Ogg and Matroska text streams.
This command is mainly for cycling all subtitles, if you want to set
a specific subtitle, use sub_file, sub_vob, or sub_demux.
sub_source [source]
Display first subtitle from [source]. Here [source] is an integer:
SUB_SOURCE_SUBS (0) for file subs
SUB_SOURCE_VOBSUB (1) for VOBsub files
SUB_SOURCE_DEMUX (2) for subtitle embedded in the media file or DVD subs.
If [source] is -1, will turn off subtitle display.
If [value] is omitted or less than -1, will cycle between the first subtitle
of each currently available source (forward or backward respectively).
sub_file [value]
Display subtitle specifid by [value] for file subs. The [value] is
corresponding to ID_FILE_SUB_ID values reported by '-identify'.
If [value] is -1, will turn off subtitle display.
If [value] is omitted or less than -1, will cycle all file subs
(forward or backward respectively).
sub_vob [value]
Display subtitle specifid by [value] for vobsubs. The [value] is
corresponding to ID_VOBSUB_ID values reported by '-identify'.
If [value] is -1, will turn off subtitle display.
If [value] is omitted or less than -1, will cycle all vobsubs
(forward or backward respectively).
sub_demux [value]
Display subtitle specifid by [value] for subtitles from DVD or embedded
in media file. The [value] is corresponding to ID_SUBTITLE_ID values
reported by '-identify'. If [value] is -1, will turn off subtitle display.
If [value] is omitted or less than -1, will cycle all DVD subs or embedded subs
(forward or backward respectively).
sub_scale <value> [abs]
Adjust the subtitle size by +/- <value> or set it to <value> when [abs]
is nonzero.
vobsub_lang
This is a stub linked to sub_select for backwards compatibility.
sub_step <value>
Step forward in the subtitle list by <value> steps or backwards if <value>
is negative.
sub_visibility [value]
Toggle/set subtitle visibility.
forced_subs_only [value]
Toggle/set forced subtitles only.
switch_audio [value] (currently MPEG*, AVI, Matroska and streams handled by libavformat)
Switch to the audio track with the ID [value]. Cycle through the
available tracks if [value] is omitted or negative.
switch_angle [value] (DVDs only)
Switch to the DVD angle with the ID [value]. Cycle through the
available angles if [value] is omitted or negative.
switch_ratio [value]
Change aspect ratio at runtime. [value] is the new aspect ratio expressed
as a float (e.g. 1.77778 for 16/9).
There might be problems with some video filters.
switch_title [value] (DVDNAV only)
Switch to the DVD title with the ID [value]. Cycle through the
available titles if [value] is omitted or negative.
switch_vsync [value]
Toggle vsync (1 == on, 0 == off). If [value] is not provided,
vsync status is inverted.
teletext_add_digit <value>
Enter/leave teletext page number editing mode and append given digit to
previously entered one.
0..9 - Append apropriate digit. (Enables editing mode if called from normal
mode, and switches to normal mode when third digit is entered.)
- - Delete last digit from page number. (Backspace emulation, works only
in page number editing mode.)
teletext_go_link <1-6>
Follow given link on current teletext page.
tv_start_scan
Start automatic TV channel scanning.
tv_step_channel <channel>
Select next/previous TV channel.
tv_step_norm
Change TV norm.
tv_step_chanlist
Change channel list.
tv_set_channel <channel>
Set the current TV channel.
tv_last_channel
Set the current TV channel to the last one.
tv_set_freq <frequency in MHz>
Set the TV tuner frequency.
tv_step_freq <frequency offset in MHz>
Set the TV tuner frequency relative to current value.
tv_set_norm <norm>
Set the TV tuner norm (PAL, SECAM, NTSC, ...).
tv_set_brightness <-100 - 100> [abs]
Set TV tuner brightness or adjust it if [abs] is set to 0.
tv_set_contrast <-100 -100> [abs]
Set TV tuner contrast or adjust it if [abs] is set to 0.
tv_set_hue <-100 - 100> [abs]
Set TV tuner hue or adjust it if [abs] is set to 0.
tv_set_saturation <-100 - 100> [abs]
Set TV tuner saturation or adjust it if [abs] is set to 0.
use_master
Switch volume control between master and PCM.
vo_border [value]
Toggle/set borderless display.
vo_fullscreen [value]
Toggle/set fullscreen mode.
vo_ontop [value]
Toggle/set stay-on-top.
vo_rootwin [value]
Toggle/set playback on the root window.
volume <value> [abs]
Increase/decrease volume or set it to <value> if [abs] is nonzero.
show_chapters_osd
Show the list of chapters in the currently played file on the OSD.
show_tracks_osd
Show the list audio and subtitle tracks in the currently played file on the OSD.
Available properties:
name type min max get set step comment
=================================================================
osdlevel int 0 3 X X X as -osdlevel
speed float 0.01 100 X X X as -speed
loop int -1 X X X as -loop
hr_seek string X X X as -hr-seek
pts_association_mode string X X X as -pts-association-mode
pause flag 0 1 X 1 if paused
filename string X file playing wo path
path string X file playing
demuxer string X demuxer used
stream_pos pos 0 X X position in stream
stream_start pos 0 X start pos in stream
stream_end pos 0 X end pos in stream
stream_length pos 0 X (end - start)
stream_time_pos time 0 X present position in stream (in seconds)
titles int X number of titles
chapter int 0 X X X select chapter
chapters int X number of chapters
angle int 0 X X X select angle
length time X length of file in seconds
percent_pos int 0 100 X X X position in percent
time_pos time 0 X X X position in seconds
metadata str list X list of metadata key/value
metadata/* string X metadata values
volume float 0 100 X X X change volume
balance float -1 1 X X X change audio balance
mute flag 0 1 X X X
audio_delay float -100 100 X X X
audio_format int X
audio_codec string X
audio_bitrate int X
samplerate int X
channels int X
switch_audio int -2 255 X X X select audio stream
switch_angle int -2 255 X X X select DVD angle
switch_title int -2 255 X X X select DVD title
capturing flag 0 1 X X X dump primary stream if enabled
fullscreen flag 0 1 X X X
deinterlace flag 0 1 X X X
ontop flag 0 1 X X X
rootwin flag 0 1 X X X
border flag 0 1 X X X
framedropping int 0 2 X X X 1 = soft, 2 = hard
gamma int -100 100 X X X
brightness int -100 100 X X X
contrast int -100 100 X X X
saturation int -100 100 X X X
hue int -100 100 X X X
panscan float 0 1 X X X
vsync flag 0 1 X X X
colormatrix choice X X X as --colormatrix
colormatrix_input_range choice X X X as --colormatrix-input-range
colormatrix_output_range choice X X X as --colormatrix-output-range
video_format int X
video_codec string X
video_bitrate int X
width int X "display" width
height int X "display" height
fps float X
aspect float X
switch_video int -2 255 X X X select video stream
switch_program int -1 65535 X X X (see TAB default keybind)
sub int -1 X X X select subtitle stream
sub_source int -1 2 X X X select subtitle source
sub_file int -1 X X X select file subtitles
sub_vob int -1 X X X select vobsubs
sub_demux int -1 X X X select subs from demux
sub_delay float X X X
sub_pos int 0 100 X X X subtitle position
sub_alignment int 0 2 X X X subtitle alignment
sub_visibility flag 0 1 X X X show/hide subtitles
sub_forced_only flag 0 1 X X X
sub_scale float 0 100 X X X subtitles font size
ass_vsfilter_aspect_compat flag 0 1 X X X SSA/ASS aspect ratio correction
tv_brightness int -100 100 X X X
tv_contrast int -100 100 X X X
tv_saturation int -100 100 X X X
tv_hue int -100 100 X X X
teletext_page int 0 799 X X X
teletext_subpage int 0 64 X X X
teletext_mode flag 0 1 X X X 0 - off, 1 - on
teletext_format int 0 3 X X X 0 - opaque,
1 - transparent,
2 - opaque inverted,
3 - transp. inv.
teletext_half_page int 0 2 X X X 0 - off, 1 - top half,
2- bottom half

42
DOCS/OUTDATED-tech/subcp.txt
View File

@ -1,42 +0,0 @@
Ascii Subtitle / Font CODEPAGEs
===============================
The subtitle encoding issue seems a bit confusing, so I'll try to
summarize it here.
There are 2 approaches:
1. (preferred) You can generate Unicode subtitles with:
subfont --unicode <signle-byte encoding known by iconv> ...
or
subfont --unicode <path to custom encoding file> ...
(this custom encoding file could list all iso-8859-* characters to create
single font file for common encodings)
and then run mplayer this way (-subcp and -utf8 expect Unicode font!):
mplayer -subcp <any encoding known by iconv> ...
or
mplayer -utf8 ...
2. (current) Generate subtitles for some specific encoding with:
subfont <signle-byte encoding known by iconv> ...
or
subfont <path to custom signle-byte or EUC encoding file> ...
and then run mplayer without any encoding options for signle-byte
encodings, or with -unicode option for EUC (and the like) encodings
(which is only partially implemented in mplayer).
AFAIK, CJK encodings: EUC-*, BIG5 and GB2312 work more or less this way:
- 0x8e (SINGLE-SHIFT TWO, SS2) begins a 2-byte character,
- 0x8f (SINGLE-SHIFT THREE, SS3) begins a 3-byte character,
- 0xa0-0xff begin 2-byte characters,
- other characters are single-byte.
I tested charmap2enc script only with /usr/share/i18n/charmaps/EUC-KR.gz
(on RedHat). It wasn't intended to be perfect.
--
Artur Zaprzala

118
DOCS/OUTDATED-tech/win32-codec-howto.txt
View File

@ -1,118 +0,0 @@
============================
Win32 codecs importing HOWTO
============================
This document describes how to extract the information necessary to hook
up Win32 binary codecs in MPlayer from a Windows system. Different methods
exist depending on which video API your codec uses and which Windows
version you have.
If you have gathered all the necessary information (fourcc, GUID, codec file,
sample file) as described below, notify the mplayer-dev-eng mailing list.
If you want to add a codec yourself, read DOCS/tech/codecs.conf.txt.
VfW codecs
~~~~~~~~~~
VfW (Video for Windows) is the old video API for Windows. Its codecs have
the '.dll' or (rarely) '.drv' extension. If MPlayer fails at playing your
AVI with this kind of message:
VIDEO: [HFYU] 352x288 24bpp 25.000 fps 4321.0 kbps (527.5 kbyte/s)
Cannot find codec matching selected -vo and video format 0x55594648.
It means your AVI is encoded with a codec which has the HFYU fourcc (HFYU =
HuffYUV codec, DIV3 = DivX Low Motion, etc.). Now that you know this, you
have to find out which DLL Windows loads in order to play this file.
You can find the VfW codec by searching the internet for e.g. VIDC.HFYU.
In our case, the 'system.ini' also contains this information in a line that reads:
VIDC.HFYU=huffyuv.dll
So you need the 'huffyuv.dll' file.
ACM Codecs:
~~~~~~~~~~~~
MPlayer may fail at playing the audio in your file with this message:
Cannot find codec for audio format 0x55.
Audio: no sound
MPlayer calls this the TwoCC format identifier. From the TwoCC list we find:
0x0055 MPEG-1 Layer 3 (MP3)
If you are lucky, you can then just search the internet for "codec acm"
e.g. "mp3 acm". Or if the codec is already installed on Windows,
it will show up in the system.ini as:
msacm.l3acm=L3codeca.acm
Note that the audio codecs are specified by the MSACM prefix:
DirectShow codecs:
~~~~~~~~~~~~~~~~~~
DirectShow is the newer video API, which is even worse than its predecessor.
Things are harder with DirectShow, since 'system.ini' does not contain the
needed information, instead it is stored in the registry and we need the
GUID of the codec.
New Method:
-----------
Using Microsoft GraphEdit (fast)
- Get GraphEdit from the Microsoft SDK, DirectX SDK or doom9.
- Start 'graphedit.exe'.
- From the menu select "Graph -> Insert Filters".
- Expand item "DirectShow Filters".
- Select the right codec name and expand item.
- In the entry "DisplayName" look at the text in winged brackets after the
backslash and write it down (five dash-delimited blocks, the GUID).
- The codec binary is the file specified in the "Filename" entry.
If there is no "Filename" and "DisplayName" contains something like
'device:dmo', then it is a DMO-Codec.
Old Method:
-----------
Take a deep breath and start searching the registry...
- Start 'regedit'.
- Press "Ctrl-F", disable the first two checkboxes, and enable the third.
Type in the fourcc of the codec (e.g. "TM20").
- You should see a field which contains the path and the filename (e.g.
"C:\WINDOWS\SYSTEM\TM20DEC.AX").
- Now that you have the file, we need the GUID. Try searching again, but
now search for the codec's name, not the fourcc. Its name can be acquired
when Media Player is playing the file, by checking
"File -> Properties -> Advanced".
If not, you are out of luck. Try guessing (e.g. search for TrueMotion).
- If the GUID is found you should see a "FriendlyName" and a "CLSID" field.
Write down the 16 byte CLSID, this is the GUID we need.
If searching fails, try enabling all the checkboxes. You may have
false hits, but you may get lucky...
Tips:
~~~~~~~
If you get an error loading a new codec, it may need some more files to work.
Start the filemon utility before loading MPlayer to find out which DLLs are
trying to be loaded.
Your codec may load some external DLL libraries. If the codec is already
installed in Windows, run listdlls wmplayer.exe while Windows Media
Player is playing your file to find out which.