1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Understanding MPlayer's etc/codecs.conf File
Introduction
------------
MPlayer features a very flexible codec architecture which allows it to
use its own open source codecs, as well as open source libraries, Win32
codec DLLs, and XAnim binary codec modules. To the MPlayer user, the
most visible piece of this architecture is the etc/codecs.conf file. This
is a text-based configuration file that controls which MPlayer components
are in charge of handling particular compressed data formats.
The codecs.conf file is stored either in a shared directory for all system
users to access, or in the .mplayer directory in a user's home
directory. When MPlayer starts, it first looks for a codecs.conf file in a
user's home directory. Failing that, it searches for the shared file. If
it can't find a codecs.conf file, MPlayer will refuse to run.
The codecs.conf file is really quite simple. It is simply a collection of
codec definition blocks that define how different media types should be
handled. There are a number of keywords that can occur in a block. Not all
of them are required and there is no particular order enforced.
Editing codecs.conf
-------------------
You can edit codecs.conf using your favorite text editor. Anything that
comes after a semicolon (;) on a line is regarded as a comment. For
example:
; this is a comment
format 0x34616d69 ; "ima4" (MOV files)
The codec blocks can be in any order; the file parser doesn't
care. However, they are organized in a particular order for the benefit of
human readers. For example, all of the open source decoders that MPlayer
implements natively are grouped in one section.
Release Number
--------------
Your codecs.conf now requires a release number to avoid codec release
incompatibilities. The format is simple: (YYYYMMDD)
release 20020520
Whenever changes are made to the codecs that *require* an updated
codecs.conf, then MPlayer will no longer accept outdated versions.
It is not recommended to change this line unless you know exactly
what you are doing.
Video Codecs
------------
Let's jump right in with an example. Here is an example video codec block:
videocodec indeo5ds
info "Intel Indeo 5"
status working
fourcc IV50,iv50
driver dshow
dll "ir50_32.dll"
guid 0x30355649, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71
out YV12
out YUY2
out BGR32,BGR24,BGR16,BGR15
This is a particularly full-featured video codec. The "videocodec" keyword
identifies the fact that this is the start of a new video
codec. "indeo5ds" is MPlayer's unique name for the codec. You have to use
this name with the -vd/-ad option.
The next line has the keyword "info" which specifies a human-readable
comment accompanies this codec. This is printed by -vd help / -ad help.
The "status" keyword carries information about the codec's functional
status. MPlayer currently recognizes 4 status levels: working, buggy,
crashing, and untested. When it gets to codec auto-selection, it tries
untested first (to force the users to test it for us and report result :)),
then working and finally buggy ones. Codecs marked crashing won't be tried,
unless explicitly (-vd/-ad) selected.
The next line lists 4-character codes (FOURCCs) that are associated with
this codec. There can be more than one FOURCC specified on a fourcc line
as long as they're separated with a comma. There can also be multiple
fourcc lines in the codec. There also can be a second fourcc given, separated
with a space. MPlayer will replace the original fourcc in the headers with
this one before opening the codec. It's useful for win32 codecs checking for
the fourccs.
The "driver" keyword associates this codec with an internal MPlayer
decoder module. MPlayer has a module named "dshow" that handles data
encoded by the codec. See -vfm help / -afm help for the available module list.
The "dll" keyword specifies which Win32/XAnim/Real binary module needs to be
loaded in order to handle the specific media type. This keyword is usually
only used in conjunction with the dshow, vfw, acm, xanim and real drivers since
they all manage communication with binary-only modules.
The "guid" keyword identifies a 16-byte Microsoft GUID that some media
files use to identify codecs. Used only for win32 dshow codecs.
The "out" keyword identifies which output format that the decoder is known
to output. Just like the fourcc line, there can be multiple out lines or
multiple comma-separated output formats on the same line. The output
formats should be listed in order of preference.
The outfmt values can be followed by one or more flags, like flip, noflip,
static, querty. TODO: describe tehse in detail.
Audio Codecs
------------
Here is an example a rather full-featured audio codec block:
audiocodec mp3
info "MPEG layer-2, layer-3"
status working
comment "Optimized to MMX/SSE/3Dnow!"
format 0x50
format 0x55
format 0x33706d2e ; ".mp3" CBR/VBR MP3 (MOV files)
format 0x5500736d ; "ms\0\x55" older mp3 fcc (MOV files)
driver mp3lib
dll "mp3lib (mpglib)"
flags seekable
Many of the keywords are the same as a video codec block. However, we see
a few that we haven't seen before. The "comment" keyword identifies
another human-readable note for this codec.
The "format" keyword performs a similar job as the fourcc line. However,
since certain media file formats (notably AVI) identify audio formats with
16-bit numbers rather than 32-bit FOURCCs, it's necessary to use this
convention to accomodate them. However, as shown in this example, FOURCCs
can also be specified with the format keyword as long as they're converted
to their hex representation. It's important to note that this can be
useful for video codecs as well if a FOURCC contains a space (such as
Apple's "rle " codec).
The "flags" keywords identifies any additional abilities of this
codec. Currently, seekable is the only flag supported.
EOF
|
