summaryrefslogtreecommitdiffstats
path: root/tde-i18n-pt_BR/docs/tdemultimedia/artsbuilder/future.docbook
blob: f821174c20684e9b1a71778542f2bcd129f06114 (plain)
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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
<!-- <?xml version="1.0" ?>
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant
V1.1//EN" "dtd/kdex.dtd">
To validate or process this file as a standalone document, uncomment
this prolog. Be sure to comment it out again when you are done -->

<chapter id="future-work">
<title
>Trabalho Futuro</title>

<para
>Esta seção descreve parte do trabalho no &arts; que está em progresso. O desenvolvimento evolui rapidamente, assim estas informações já devem estar desatualizadas. Você deve verificar o arquivo de lista TODO e os arquivos da <link linkend="mailing-lists"
>lista de discussão</link
> para ver quais novas funcionalidades estão sendo planejadas. Sinta-se à vontade para envolver-se em novos projetos e implementações. </para>

<para
>Este é um rascunho que tenta fornecer-lhe uma visão geral de como novas tecnologias serão integradas ao &arts;. Específicamente, isto cobre o seguinte: </para>

<itemizedlist>
<listitem
><para
>Como a interface funciona.</para
></listitem>
<listitem
><para
>Codecs - decodificação de fluxos mp3 ou wav em uma forma que eles possam ser usados como dados.</para
></listitem>
<listitem
><para
>Vídeo.</para
></listitem>
<listitem
><para
>Linhas de execução.</para
></listitem>
<listitem
><para
>Sincronização.</para
></listitem>
<listitem
><para
>Expansão/mascaramento dinâmico.</para
></listitem>
<listitem
><para
>Composição dinâmica.</para
></listitem>
<listitem
><para
>&GUI;</para
></listitem>
<listitem
><para
>&MIDI;</para
></listitem>
</itemizedlist>

<para
>Estes são os trabalhos em progresso. No entanto, isto deve ser a base se você deseja ver novas tecnologias no &arts;. Isto deve fornecer uma idéia geral de como estes problemas serão abordados. No entanto, sinta-se à vontade para corrigir qualquer coisa que veja aqui. </para>

<para
>Coisas que usarão a tecnologia do &arts; (logo por favor, coordene seus esforços): </para>

<itemizedlist>
<listitem>
<para
><application
>KPhone</application
> (voz sobre <acronym
>IP</acronym
>) </para>
</listitem>

<listitem>
<para
>&noatun; (reprodutor de vídeo / áudio) </para>
</listitem>

<listitem>
<para
>&artscontrol; (programa de controle do servidor de som, para escopos) </para>
</listitem>

<listitem>
<para
><application
>Brahms</application
> (sequenciador de música) </para>
</listitem>

<listitem>
<para
><application
>Kaiman</application
> (tocador de mídia do &kde;2 - compatível com o kmedia2) </para>
</listitem>

<listitem>
<para
><application
>mpglib</application
>/<application
>kmpg</application
> (tecnologia para reprodução de áudio e vídeo <acronym
>mpg</acronym
>) </para>
</listitem>

<listitem>
<para
><application
>SDL</application
> (camada de mídia direta para jogos ainda não iniciada mas talvez bem legal) </para>
</listitem>

<listitem>
<para
><application
>electric ears</application
> (o autor contactou-me - estado desconhecido) </para>
</listitem>
</itemizedlist>

<sect1 id="interfaces-how">
<title
>Como a Interface Funciona</title>

<!-- I think this is now obsolete and documented elsewhere ? -->

<para
>As interfaces &MCOP; são a base do conceito do &arts;. Elas são a transparência de rede equivalente para classes C++. Sempre que possível você deve orientar seu desenho em função destas interfaces. As interfaces consistem de quatro partes: </para>

<itemizedlist>
<listitem
><para
>Fluxos síncronos</para
></listitem>
<listitem
><para
>Fluxos assíncronos</para
></listitem>
<listitem
><para
>Métodos</para
></listitem>
<listitem
><para
>Atributos</para
></listitem>
</itemizedlist>

<para
>Eles podem ser misturados de qualquer jeito que desejar. As novas tecnologias devem ser definidas em termos de interfaces. Leia as seções sobre fluxos assíncronos e síncronos, bem como as sobre interfaces KMedia2, que são bons exemplos de como as coisas funcionam. </para>

<para
>Interfaces são especificadas em código <literal role="extension"
>.idl</literal
> e rodam através do compilador <command
>mcopidl</command
>. Você deriva a classe <classname
><replaceable
>Nomeinterface</replaceable
>_impl</classname
> para implementá-las, e usa <function
>REGISTER_IMPLEMENTATION(NomeInterface_impl)</function
> para inserir sua implementação de objeto no sistema de objetos &MCOP;. </para>

</sect1>

<sect1 id="codecs">
<title
>Codecs - Decodificando Dados</title>

<para
>As interfaces kmedia2 permitem que você ignore que arquivos wav, mp3s e seja o que for consistem de fluxos de dados. Ao invés disso, você somente implementas métodos para reproduzí-los. </para>

<para
>Assim, você pode escrever uma rotina de carregamento wave da mesma maneira que você pode reproduzir arquivos wave (com PlayObject), mas ninguém mais usa seu código. </para>

<para
>Fluxos assíncronos devem ser a alternativa. Você define uma interface que permite passar blocos de dados para ela, e obter blocos de dados dela. Isto se parece assim no &MCOP;: </para>

<programlisting
>interface Codec {
  in async byte stream indata;
  out async byte stream outdata;
};
</programlisting>


<para
>É claro que codecs também podem fornecer atributos para emitir dados adicionais, como informações do formato. </para>

<programlisting
>interface ByteAudioCodec {
  in async byte stream indata;
  out async byte stream outdata;
  readonly attribute samplingRate, bits, channels;
};
</programlisting>

<para
>Este <interfacename
>ByteAudioCodec</interfacename
> por exemplo pode ser conectado a um objeto <interfacename
>ByteStreamToAudio</interfacename
> para criar áudio flutuante real. </para>

<para
>É claro, outros tipos de Codec podem envolver diretamente emitir dados de vídeo, como </para>

<programlisting
>interface VideoCodec {
  in async byte stream indata;
  out video stream outdata;      /* note: video streams do not exist yet */
};
</programlisting>

<para
>Provavelmente, um conceito de codec deve ser empregado ao invés do modo <quote
>você sabe como reproduzir e eu não</quote
> por exemplo o uso atual do <interfacename
>WavPlayObject</interfacename
>. No entanto, alguém precisa sentar e realizar alguns testes antes de uma <acronym
>API</acronym
> poder ser finalizada. </para>

</sect1>

<sect1 id="video">
<title
>Vídeo</title>

<para
>Minha idéia é fornecer vídeo como fluxos assíncronos de algum tipo de dado nativo do &MCOP; que contenha imagens. Este tipo de dado ainda será criado. Fazendo isso, plugins que lidam com imagens de vídeo podem ser conectados da mesma maneira que plugins de áudio podem ser conectados. </para>

<para
>Existem algumas coisas que são importantes que não sejam deixadas de fora, especificamente: </para>

<itemizedlist>
<listitem>
<para
>Existem espaços de cores <acronym
>RGB</acronym
> e <acronym
>YUV</acronym
>. </para>
</listitem>
<listitem>
<para
>O formato deve ser algo vocacionado para fluxo. </para>
</listitem>
<listitem>
<para
>Sincronização é importante. </para>
</listitem>
</itemizedlist>

<para
>Minha idéia é deixar possível reimplementar a classe <classname
>VideoFrame</classname
> de modo que eu possa armazenar material no segmento de memória compártilhada. Fazendo isso, cada fluxo de vídeo entre processos diferentes serão possíveis sem muito sacrifício. </para>

<para
>No entanto, a situação padrão para vídeo é que as coisas estão no mesmo processo, da decodificação à renderização. </para>

<para
>Eu fiz uma implementação de fluxo de vídeo experimental, que você pode baixar <ulink url="http://space.twc.de/~stefan/kde/download/video-quickdraw.tar.gz"
>aqui</ulink
>. Isto precisará ser integrado ao &MCOP; após alguns testes. </para>

<para
>Um componente de renderização deve ser fornecido que suporte XMITSHM (com <acronym
>RGB</acronym
> e <acronym
>YUV</acronym
>). Martin Vogt me disse que ele está trabalhado em algo deste tipo. </para>

</sect1>

<sect1 id="threading">
<title
>Linhas de execução</title>

<para
>Atualmente, o &MCOP; é todo em linha simples de execução. Talvez para vídeo nós não sejamos capazes de manternos em uma linha simples. Ok. Existem algumas coisas que devem ser tratadas com cuidado: </para>


<itemizedlist>
<listitem
><para
>SmartWrappers - eles não são seguros para linhas de execução devido a contagem de referência não segura e coisas semelhantes. </para>
</listitem>
<listitem>
<para
>Dispatcher / I/O - também não é seguro para linhas de execução. </para>
</listitem>
</itemizedlist>

<para
>No entanto, o que eu posso imaginar é tornar os módulos selecionados seguros para linhas de execução, tanto para fluxo síncrono como assíncrono. De que modo - com um sistema de fluxo ciente da linha de execução, você pode agendar o fluxo do sinal sobre dois ou mais processadores. Isto também auxiliaria o áudio principalmente em situações de multiprocessamento. </para>

<para
>Como isto funcionaria: </para>


<itemizedlist>
<listitem>
<para
>O Sistema de Fluxo decide quais módulos devem calcular o que - o que é: </para>
    <itemizedlist>
	<listitem
><para
>quadros de vídeo (com método process_indata)</para
></listitem>
	<listitem
><para
>fluxos de áudio síncrono (calculateBlock)</para
></listitem>
	<listitem
><para
>outros fluxos assíncronos, principalmente fluxos de byte</para
></listitem>
	</itemizedlist>
</listitem>
<listitem>
<para
>Os módulos podem calcular estas coisas em suas próprias linhas de execução. Para áudio, faz sentido reusar linhas (&eg; renderizar em quatro linha de execução para quatro processadores, não importa se 100 módulos estiverem rodando). Para vídeo e descompressão de bytes, seria mais confortável ter uma implementação em blocos em sua própria linha, que é sincronizada com o resto do &MCOP; pelo sistema de fluxo. </para>
</listitem>

<listitem>
<para
>Módulos não devem usar funcionalidades do &MCOP; (como invocações remotas) durante a operação em linha de execução. </para>
</listitem>
</itemizedlist>

</sect1>

<sect1 id="synchronization">
<title
>Sincronização</title>

<para
>Vídeo e &MIDI; (e áudio) devem requerer sincronização. Basicamente, isto é estampa de tempo. A idéia que eu tenho é anexar estampa de tempo aos fluxos assíncronos, adicionando uma estampa de tempo para cada pacote. Se você enviar dois quadros de vídeo, simplesmente crie dois pacotes (eles serão grandes de qualquer jeito), assim você pode ter duas estampas de tempo diferentes. </para>

<para
>Áudio deve implicitamente ter estampas de tempo, uma vez que ele é síncrono. </para>

</sect1>

<sect1 id="dynamic-composition">
<title
>Composição Dinâmica</title>

<para
>Deve ser possível dizer: Um efeito FX é composto de seus módulos simples. O FX deve parecer um módulo &MCOP; normal (veja mascaramento), mas de fato consiste de outros módulos. </para>

<para
>Isto é necessário para o &arts-builder;. </para>

</sect1>

<sect1 id="gui">
<title
>&GUI;</title>

<para
>Todos os componentes de &GUI; serão módulos &MCOP;. Eles devem ter atributos como tamanho, rótulo, cor, ... . Um construtor <acronym
>RAD</acronym
> (&arts-builder;) deve ser capaz de compô-los visualmente. </para>

<para
>A &GUI; deve ser salvável salvando os atributos. </para>

</sect1>

<sect1 id="midi-stuff">
<title
>&MIDI;</title>

<para
>O material de &MIDI; será implementado como fluxos assíncronos. Existem duas opções, uma é usar estruturas normais do &MCOP; para definir os tipos e outra é introduzir outros tipos customizados. </para>

<para
>Eu acho que estruturas normais deve ser o bastante, que é algo como: </para>

<programlisting
>struct MidiEvent {
  byte b1,b2,b3;
  sequence&lt;byte&gt; sysex;
}
</programlisting>

<para
>Fluxos assíncronos devem suportar tipos de fluxo customizados. </para>

</sect1>

</chapter>