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