source: DOV/ch04.xml@ 54

Last change on this file since 54 was 54, checked in by ktk, 19 years ago

Plenty of changes, mostly done in Glengarriff, Ireland. This is quite close to the 0.1 version.
File size: 12.6 KB
Line 
1<?xml version='1.0'?>
2<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3b2/docbookx.dtd">
3<chapter id="dov.triton">
4
5 <title>Triton</title>
6
7 <section id="dov.triton.i">
8
9 <title>Introducton</title>
10
11 <para>The multimedia subsystem of Voyager (called Triton) is a plugin-based,
12 extendable, flexible architecture, originally designed for stable playback
13 of any kind of multimedia streams from any kind of source. The system is not yet
14 capable of recording, it&apos;s planned for later versions.</para>
15
16 <para>The MMIO subsystem has a layered architecture. It means that in order to play
17 back a given multimedia content, the subsystem builds a logical structure of at
18 least five levels. This structure describes the inner structure of the given
19 multimedia content, and makes it possible to divide the processing and playback
20 of multimedia contents into different modular parts, making it easier to find
21 and fix the bugs in plugins. The modular structure also helps so that once support
22 for a new format is added, it will probably work from all the supported sources
23 (like from local file or from an Internet stream), and vice versa, a new plugin for
24 a new source will make it possible to play back all the supported formats without
25 any additional code.</para>
26
27 <para>The current version of MMIO has the following layers defined:</para>
28
29 <itemizedlist>
30
31 <listitem>
32
33 <para>Medium</para>
34
35 </listitem>
36
37 <listitem>
38
39 <para>Channel</para>
40
41 </listitem>
42
43 <listitem>
44
45 <para>Elementary Stream</para>
46
47 </listitem>
48
49 <listitem>
50
51 <para>Raw Stream</para>
52
53 </listitem>
54
55 <listitem>
56
57 <para>Terminator Nodes (Visualization)</para>
58
59 </listitem>
60
61 </itemizedlist>
62
63 <para>These layers and the layered structure are handled internally by the system,
64 and all these are built up from a URL. This effectively means that playing back a
65 given file (or any kind of multimedia content) is as simple as opening a URL with
66 one MMIO API call, and sending it a Play command.</para>
67
68 <para>These URLs look this simple:</para>
69
70 <itemizedlist>
71
72 <listitem>
73
74 <para>file://c:/Musics/My_Favourite.mp3</para>
75
76 </listitem>
77
78 <listitem>
79
80 <para>
81 http://local.video.store.com:8080/Horror/Killing_The_Killer.avi</para>
82
83 </listitem>
84
85 <listitem>
86
87 <para>rtsp://radio.com/live.ra</para>
88
89 </listitem>
90
91 </itemizedlist>
92
93 </section>
94
95 <section id="dov.triton.bo">
96
97 <title>Basic Overview</title>
98
99 <section id="dov.triton.bo.plptsg">
100
101 <title>Plugin List, Process Tree, Stream Groups</title>
102
103 <para>There are three main expressions of MMIO with which one has to be familiar
104 with.</para>
105
106 <para>The Plugin List means the list of available MMIO Plugins from where the
107 MMIO subsystem can select plugins to be used for the playback of a given URL.
108 This list can be queried and examined, so the application will get an idea
109 about the capabilities of the system it runs on. Alternatively, it can
110 decide to de-register old plugins and register new ones.</para>
111
112 <para>The Process Tree is probably the most important thing of the MMIO
113 subsystem. It is a tree structure, having different kind of nodes connected
114 together, describing the layered architecture of the multimedia content
115 to be played back. This tree is built somewhat automatically by the MMIO
116 subsystem, using the registered plugins of the Plugin List. The top of the
117 tree has a URL node, containing only the URL string itself, while the bottom
118 of the tree will have Terminator nodes, the <quote>Visualization</quote>
119 nodes for every supported stream of the URL. Here is an example of an
120 imaginary URL and the Process Tree created from it by the MMIO
121 subsystem:</para>
122
123 <para>URL: http://www.server.com/Films/LOTR_Trailer.avi</para>
124
125 <para>As you can see, this example has an AVI file containing one video stream in
126 DIVX format, one audio stream for the video in MPEG Audio format, and one
127 Subtitle stream for all these, in DVD Subtitle format. All these elementary
128 streams (ES) have a raw stream (RS) descendant, meaning that a decoder has
129 been found for all of them, and all of them has a Terminator (Term) node,
130 meaning that all the decoder outputs can be sent to the screen or speaker, so
131 all of them can be played back. More about node types and their purpose
132 later.</para>
133
134 <para>Having three Terminator nodes means that we have three independent
135 streams we can play back. We could send a <command>Start
136 Playback</command> command to all the three of these Terminator nodes,
137 which would mean that the playback of all these streams would be started, and
138 we would be able to watch and listen to the movie.</para>
139
140 <para>However, usually it&apos;s not this simple. Nothing guarantees that
141 starting the playback this way, independently, stream-by-stream, will
142 result in an experience where the video and the audio goes together. There
143 must be <quote>lipsync</quote> as it&apos;s usually called, meaning that
144 the audio and the video has to go together in order to have an enjoyable
145 experience.</para>
146
147 <para>That&apos;s the reason why there is a third expression in the MMIO
148 subsystem to get familiar with: the Stream Groups.</para>
149
150 <para>Stream Groups are logical entities, grouping Terminator nodes
151 together. One can create a Stream Group from the three Terminator nodes of
152 the example above, and send the <command>Start Playback</command>
153 command to the Stream Group. The Stream Group itself will take care of the
154 lipsync, and will make sure that all the streams grouped together in it will
155 move and act together.</para>
156
157 </section>
158
159 <section id="dov.triton.bo.nntpt">
160
161 <title>Nodes and Node Types in the Process Tree</title>
162
163 <para>The Process Tree is built from nodes. Every node in the tree has a type, and
164 has a string describing the format which that node can provide. Using the
165 Process Tree example we had before, there is a node which is a URL node (its
166 type is URL), and can provide <quote>urls</quote> to any other nodes that
167 are connecting to it.</para>
168
169 <para>The MMIO subsystem looked through its list of available plugins, and
170 found a media handler plugin that can handle that URL node. Using that
171 plugin, a new node was created, which is a Media node, describing the media
172 contained in the URL. This new Media node was created by the media handler
173 plugin (http handler plugin, in our example), and that plugin also checked
174 what kind of stuff it can provide. It saw that the URL contains a file, which
175 has the extension of <computeroutput>.avi</computeroutput>, so it
176 reports that this node can provide an AVI container format to everyone who
177 connects to it. As it&apos;s a Media node, everybody will be able to use the
178 node&apos;s type-specific functions, like seeking, reading and other
179 Media-specific functions.</para>
180
181 <para>The MMIO subsystem tried to <quote>grow</quote> this process tree, so
182 again looked into its plugin list, and found a plugin which can handle AVI
183 container formats (cont_AVI format strings). This is the AVI demuxer
184 plugin. Using that plugin, new nodes of the Process Tree could be built. The
185 first one is a Channel node, which describes logical channels in a given
186 container. There is only one channel in an AVI file, but for example the MPEG
187 Transport Stream containers, used by the digital television broadcasting
188 systems have a lot of channels in one container, namely a lot of TV channels,
189 and each of the channels have at least one Video elementary stream and one or
190 more Audio elementary streams. So, the Channel node is to be able to group the
191 available Elementary Stream Nodes of a given container.</para>
192
193 <para>It&apos;s still the AVI demuxer plugin which examined the AVI file format
194 (using the Media node to read and seek in the file) and found out that there are
195 three Elementary Streams (ES) in this AVI file, namely one video stream in
196 DIVX format, one audio stream in MPEG Audio format, and a subtitle stream
197 with DVD-format subtitles. So, the AVI demuxer plugin has created four new
198 nodes into the Process Tree.</para>
199
200 <para>The ball is at the side of the MMIO subsystem again. It&apos;s still trying
201 to grow the process tree, so it&apos;s looking for plugins to handle the
202 three new Nodes of the tree. It&apos;s lucky again, and based on the plugin
203 list, it finds decoder plugins for all the three formats, namely a DIVX
204 decoder plugin for the es_v_DIVX format, an MPEG Audio decoder plugin for
205 the es_a_MPA format, and a DVD Subtitle decoder/renderer plugin for the
206 es_s_DVD format.</para>
207
208 <para>Using these decoder plugins for the corresponding nodes, each of the
209 decoder plugins create one new Node into the tree, a Raw Stream Node. The Raw
210 Stream (RS) terminology means decoded elementary streams, so while
211 reading data from Elementary Streams would give encoded/compressed data,
212 reading from Raw Streams gives decoded/uncompressed data, which can be
213 directly shown on the screen, or sent to the audio card.</para>
214
215 <para>The MMIO subsystem does not give up, and still checks if it has plugins to
216 handle the new nodes. It finds a video output plugin, which is capable of
217 displaying YUV422 formatted images on the screen, and connects it to the
218 video RS node. Also finds an audio output plugin which can handle the PCM
219 audio format, and connects it to the audio RS node. The subtitle RS node will
220 be handled by a subtitle visualizer plugin. All these plugins have one thing
221 in common: they <quote>eat</quote> data from the upper layers, but do not
222 provide any data, as they consume them by showing it. That&apos;s why they
223 are called Terminator Nodes, because they terminate a given branch of the
224 Process Tree.</para>
225
226 <para>Now the MMIO subsystem can see that all the leafs of the Process Tree are
227 either Terminator nodes (so there is no task to do with them), or there was no
228 plugin to handle them (none of the nodes are such in our example). So, it gives
229 up growing the tree, the Process Tree has been built successfully.</para>
230
231 </section>
232
233 </section>
234
235 <section id="dov.triton.ums">
236
237 <title>Using the MMIO Subsystem</title>
238
239 <section id="dov.triton.ums.f">
240
241 <title>Foreword</title>
242
243 <para>Now that you&apos;ve reached this chapter, you&apos;ve either read
244 through the hard part, or you&apos;ve simply skipped the previous parts. If
245 you&apos;ve read through the previous parts, you know the basic idea behind
246 the MMIO subsystem, and you&apos;ll be able to use it in a more advanced way,
247 customize it for your needs. However, if you haven&apos;t read through the
248 previous parts, it&apos;s not a problem, the MMIO subsystem can be used very
249 easily without that knowledge too, <xref
250 linkend="dov.triton.ums.qu"/> is for you then.</para>
251
252 </section>
253
254 <section id="dov.triton.ums.qu">
255
256 <title>Quick Usage</title>
257
258 <para>This chapter is to be done.</para>
259
260 </section>
261
262 <section id="dov.triton.ums.au">
263
264 <title>Advanced Usage</title>
265
266 <para>This chapter is to be done.</para>
267
268 <para>Using the MMIO subsystem:</para>
269
270 <itemizedlist>
271
272 <listitem>
273
274 <para>Init MMIO</para>
275
276 </listitem>
277
278 <listitem>
279
280 <para>Query/Manage plugin list</para>
281
282 </listitem>
283
284 <listitem>
285
286 <para>Open URL</para>
287
288 </listitem>
289
290 <listitem>
291
292 <para>Create stream group</para>
293
294 </listitem>
295
296 <listitem>
297
298 <para>Start playback</para>
299
300 </listitem>
301
302 <listitem>
303
304 <para>Clean up</para>
305
306 </listitem>
307
308 </itemizedlist>
309
310 </section>
311
312 </section>
313
314 <section id="dov.triton.maap">
315
316 <title>The MMIO API for Application Programmers</title>
317
318 <para>This chapter is to be done.</para>
319
320 </section>
321
322 <section id="dov.triton.cpms">
323
324 <title>Creating Plugins for the MMIO Subsystem</title>
325
326 <para>This chapter is to be done.</para>
327
328 </section>
329
330 <section id="dov.triton.pg">
331
332 <title>Programming Guidelines</title>
333
334 <para>This chapter is to be done.</para>
335
336 <para>Use MMIOmem.h and the Triton Porting Layer, where possible, so the plugins
337 will be portable, memory leaks will be detectable and trackable.</para>
338
339 </section>
340
341</chapter>
Note: See TracBrowser for help on using the repository browser.