132
|
1 So, I'll describe how this stuff works.
|
|
2
|
|
3 The main modules:
|
|
4
|
876
|
5 1. streamer.c: this is the input layer, this reads the file or the VCD or
|
|
6 stdin. what it has to know: appropriate buffering by sector, seek, skip
|
|
7 functions, reading by bytes, or blocks with any size. The stream_t
|
|
8 structure describes the input stream, file/device.
|
132
|
9
|
136
|
10 2. demuxer.c: this does the demultiplexing of the input to audio and video
|
132
|
11 channels, and their reading by buffered packages.
|
|
12 The demuxer.c is basically a framework, which is the same for all the
|
|
13 input formats, and there are parsers for each of them (mpeg-es,
|
|
14 mpeg-ps, avi, avi-ni, asf), these are in the demux_*.c files.
|
|
15 The structure is the demuxer_t. There is only one demuxer.
|
|
16
|
551
|
17 2.a. demux_packet_t, that is DP.
|
|
18 Contains one chunk (avi) or packet (asf,mpg). They are stored in memory as
|
|
19 in chained list, cause of their different size.
|
|
20
|
876
|
21 2.b. demuxer stream, that is DS.
|
|
22 Struct: demux_stream_t
|
|
23 Every channel (a/v) has one. This contains the packets for the stream
|
|
24 (see 2.a). For now, there can be 3 for each demuxer :
|
|
25 - audio (d_audio)
|
|
26 - video (d_video)
|
|
27 - DVD subtitle (d_dvdsub)
|
132
|
28
|
551
|
29 2.c. stream header. There are 2 types (for now): sh_audio_t and sh_video_t
|
|
30 This contains every parameter essential for decoding, such as input/output
|
|
31 buffers, chosen codec, fps, etc. There are each for every stream in
|
|
32 the file. At least one for video, if sound is present then another,
|
|
33 but if there are more, then there'll be one structure for each.
|
|
34 These are filled according to the header (avi/asf), or demux_mpg.c
|
|
35 does it (mpg) if it founds a new stream. If a new stream is found,
|
|
36 the ====> Found audio/video stream: <id> messages is displayed.
|
|
37
|
|
38 The chosen stream header and its demuxer are connected together
|
|
39 (ds->sh and sh->ds) to simplify the usage. So it's enough to pass the
|
|
40 ds or the sh, depending on the function.
|
|
41
|
|
42 For example: we have an asf file, 6 streams inside it, 1 audio, 5
|
876
|
43 video. During the reading of the header, 6 sh structs are created, 1
|
|
44 audio and 5 video. When it starts reading the packet, it chooses the
|
|
45 stream for the first found audio & video packet, and sets the sh
|
|
46 pointers of d_audio and d_video according to them. So later it reads
|
|
47 only these streams. Of course the user can force choosing a specific
|
|
48 stream with
|
551
|
49 -vid and -aid switches.
|
|
50 A good example for this is the DVD, where the english stream is not
|
|
51 always the first, so every VOB has different language :)
|
|
52 That's when we have to use for example the -aid 128 switch.
|
|
53
|
132
|
54 Now, how this reading works?
|
|
55 - demuxer.c/demux_read_data() is called, it gets how many bytes,
|
|
56 and where (memory address), would we like to read, and from which
|
|
57 DS. The codecs call this.
|
|
58 - this checks if the given DS's buffer contains something, if so, it
|
|
59 reads from there as much as needed. If there isn't enough, it calls
|
|
60 ds_fill_buffer(), which:
|
|
61 - checks if the given DS has buffered packages (DP's), if so, it moves
|
|
62 the oldest to the buffer, and reads on. If the list is empty, it
|
|
63 calls demux_fill_buffer() :
|
|
64 - this calls the parser for the input format, which reads the file
|
|
65 onward, and moves the found packages to their buffers.
|
|
66 Well it we'd like an audio package, but only a bunch of video
|
|
67 packages are available, then sooner or later the:
|
|
68 DEMUXER: Too many (%d in %d bytes) audio packets in the buffer
|
|
69 error shows up.
|
|
70
|
|
71 So everything is ok 'till now, I want to move them to a separate lib.
|
|
72
|
|
73 Now, go on:
|
|
74
|
|
75 3. mplayer.c - ooh, he's the boss :)
|
|
76 The timing is solved odd, since it has/recommended to be done differently
|
138
|
77 for each of the formats, and sometimes can be done in many ways.
|
132
|
78 A new frame is displayed if v_frame<a_frame, and sound is decoded if
|
|
79 a_frame<v_frame.
|
876
|
80
|
|
81 The structure of the playing loop :
|
|
82 while(not EOF) {
|
|
83 fill audio buffer (read & decode audio) + increase a_frame
|
|
84 read & decode a single video frame + increase v_frame
|
|
85 sleep (wait until a_frame>=v_frame)
|
|
86 display the frame
|
|
87 apply A-V PTS correction to a_frame
|
|
88 check for keys -> pause,seek,...
|
|
89 }
|
|
90
|
132
|
91 When playing (a/v), it increases the variables by the duration of the
|
876
|
92 played a/v.
|
|
93 - with audio this is played bytes / sh_audio->o_bps
|
|
94 Note: i_bps = number of compressed bytes for one second of audio
|
|
95 o_bps = number of uncompressed bytes for one second of audio
|
|
96 (this is = bps*samplerate*channels)
|
|
97 - with video this is usually == 1.0/fps, but I have to note that
|
138
|
98 fps doesn't really matters at video, for example asf doesn't have that,
|
|
99 instead there is "duration" and it can change per frame.
|
132
|
100 MPEG2 has "repeat_count" which delays the frame by 1-2.5 ...
|
|
101 Maybe only AVI and MPEG1 has fixed fps.
|
|
102
|
138
|
103 So everything works right until the audio and video are in perfect
|
132
|
104 synchronity, since the audio goes, it gives the timing, and if the
|
|
105 time of a frame passed, the next frame is displayed.
|
|
106 But what if these two aren't synchronized in the input file?
|
|
107 PTS correction kicks in. The input demuxers read the PTS (presentation
|
|
108 timestamp) of the packages, and with it we can see if the streams
|
|
109 are synchronized. Then MPlayer can correct the a_frame, within
|
|
110 a given maximal bounder (see -mc option). The summary of the
|
|
111 corrections can be found in c_total .
|
|
112
|
|
113 Of course this is not everything, several things suck.
|
|
114 For example the soundcards delay, which has to be corrected by
|
876
|
115 MPlayer! The audio delay is the sum of all these:
|
|
116 - bytes read since the last timestamp:
|
|
117 t1 = d_audio->pts_bytes/sh_audio->i_bps
|
|
118 - if Win32/ACM then the bytes stored in audio input buffer
|
|
119 t2 = a_in_buffer_len/sh_audio->i_bps
|
|
120 - uncompressed bytes in audio out buffer
|
|
121 t3 = a_buffer_len/sh_audio->o_bps
|
|
122 - not yet played bytes stored in the soundcard's (or DMA's) buffer
|
|
123 t4 = get_audio_delay()/sh_audio->o_bps
|
|
124
|
|
125 From this we can calculate what PTS we need for the just played
|
|
126 audio, then after we compare this with the video's PTS, we have
|
|
127 the difference!
|
132
|
128
|
|
129 Life didn't get simpler with AVI. There's the "official" timing
|
|
130 method, the BPS-based, so the header contains how many compressed
|
|
131 audio bytes belong to one second of frames.
|
|
132 Of course this doesn't always work... why it should :)
|
|
133 So I emulate the MPEG's PTS/sector method on AVI, that is the
|
|
134 AVI parser calculates a fake PTS for every read chunk, decided by
|
|
135 the type of the frames. This is how my timing is done. And sometimes
|
|
136 this works better.
|
|
137
|
|
138 In AVI, usually there is a bigger piece of audio stored first, then
|
|
139 comes the video. This needs to be calculated into the delay, this is
|
|
140 called "Initial PTS delay".
|
|
141 Of course there are 2 of them, one is stored in the header and not
|
|
142 really used :) the other isn't stored anywhere, this can only be
|
|
143 measured...
|
876
|
144
|
|
145 3.a. audio playback:
|
|
146 Some words on audio playback:
|
|
147 Not the playing is hard, but:
|
|
148 1. knowing when to write into the buffer, without blocking
|
|
149 2. knowing how much was played of what we wrote into
|
|
150 The first is needed for audio decoding, and to keep the buffer
|
|
151 full (so the audio will never skip). And the second is needed for
|
|
152 correct timing, because some soundcards delay even 3-7 seconds,
|
|
153 which can't be forgotten about.
|
|
154 To solve this, the OSS gives several possibilities:
|
|
155 - ioctl(SNDCTL_DSP_GETODELAY): tells how many unplayed bytes are in
|
|
156 the soundcard's buffer -> perfect for timing, but not all drivers
|
|
157 support it :(
|
|
158 - ioctl(SNDCTL_DSP_GETOSPACE): tells how much can we write into the
|
|
159 soundcard's buffer, without blocking. If the driver doesn't
|
|
160 support GETODELAY, we can use this to know how much the delay is.
|
|
161 - select(): should tell if we can write into the buffer without
|
|
162 blocking. Unfortunately it doesn't say how much we could :((
|
|
163 Also, doesn't/badly works with some drivers.
|
|
164 Only used if none of the above works.
|
132
|
165
|
|
166 4. Codecs. They are separate libs.
|
|
167 For example libac3, libmpeg2, xa/*, alaw.c, opendivx/*, loader, mp3lib.
|
|
168 mplayer.c calls them if a piece of audio or video needs to be played.
|
|
169 (see the beginning of 3.)
|
|
170 And they call the appropriate demuxer, to get the compressed data.
|
|
171 (see 2.)
|
551
|
172 We have to pass the appropriate stream header as parameter (sh_audio/
|
|
173 sh_video), this should contain all the needed info for decoding
|
|
174 (the demuxer too: sh->ds).
|
|
175 The codecs' seprating is underway, the audio is already done, the video is
|
|
176 work-in-progress. The aim is that mplayer.c won't have to know
|
|
177 which are the codecs and how to use 'em, instead it should call
|
|
178 an init/decode audio/video function.
|
132
|
179
|
551
|
180 5. libvo: this displays the frame.
|
|
181 The constants for different pixelformats are defined in img_format.h,
|
|
182 their usage is mandatory.
|
|
183
|
|
184 Each vo driver _has_ to implement these:
|
132
|
185
|
551
|
186 query_format() - queries if a given pixelformat is supported.
|
|
187 return value: flags:
|
|
188 0x1 - supported (by hardware or conversion)
|
|
189 0x2 - supported (by hardware, without conversion)
|
|
190 0x4 - sub/osd supported (has draw_alpha)
|
|
191 IMPORTANT: it's mandatorial that every vo driver support the YV12 format,
|
|
192 and one (or both) of BGR15 and BGR24, with conversion, if needed.
|
|
193 If these aren't supported, not every codec will work! The mpeg codecs
|
|
194 can output only YV12, and the older win32 DLLs only 15 and 24bpp.
|
|
195 There is a fast MMX-using 15->16bpp converter, so it's not a
|
|
196 significant speed-decrease!
|
|
197
|
|
198 The BPP table, if the driver can't change bpp:
|
|
199 current bpp has to accept these
|
|
200 15 15
|
|
201 16 15,16
|
|
202 24 24
|
|
203 24,32 24,32
|
|
204
|
|
205 If it can change bpp (for example DGA 2, fbdev, svgalib), then if possible
|
|
206 we have to change to the desired bpp. If the hardware doesn't support,
|
|
207 we have to change to the one closest to it, and do conversion!
|
|
208
|
|
209 init() - this is called before displaying of the first frame -
|
|
210 initializing buffers, etc.
|
|
211
|
|
212 draw_slice(): this displays YV12 pictures (3 planes, one full sized that
|
|
213 contains brightness (Y), and 2 quarter-sized which the colour-info
|
|
214 (U,V). MPEG codecs (libmpeg2, opendivx) use this. This doesn't have
|
132
|
215 to display the whole frame, only update small parts of it.
|
551
|
216
|
|
217 draw_frame(): this is the older interface, this displays only complete
|
133
|
218 frames, and can do only packed format (YUY2, RGB/BGR).
|
132
|
219 Win32 codecs use this (DivX, Indeo, etc).
|
551
|
220
|
|
221 draw_alpha(): this displays subtitles and OSD.
|
|
222 It's a bit tricky to use it, since it's not a part of libvo API,
|
|
223 but a callback-style stuff. The flip_page() has to call
|
|
224 vo_draw_text(), so that it passes the size of the screen and the
|
|
225 corresponding draw_alpha() implementation for the pixelformat
|
|
226 (function pointer). The vo_draw_text() checks the characters to draw,
|
|
227 and calls draw_alpha() for each.
|
|
228 As a help, osd.c contains draw_alpha for each pixelformats, use this
|
|
229 if possible!
|
|
230
|
|
231 flip_page(): this is called after each frame, this diplays the buffer for
|
|
232 real. This is 'swapbuffers' when double-buffering.
|
|
233
|
|
234
|