mirror of https://github.com/mpv-player/mpv
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:
parent
df0312b694
commit
19ed132c8a
File diff suppressed because it is too large
Load Diff
|
@ -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.
|
|
|
@ -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.
|
|
|
@ -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!!!
|
|
|
@ -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
|
|
||||||
.
|
|
||||||
[...]
|
|
|
@ -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)
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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
|
|
|
@ -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.
|
|
Loading…
Reference in New Issue