-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathevaluation.tex
executable file
·333 lines (248 loc) · 39.2 KB
/
evaluation.tex
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
\ifx\all\undefined
\include{base}
\begin{document}
\fi
\chapter{Evaluación}
Este capítulo expone las pruebas realizadas sobre el sistema desarrollado y evalúa su comportamiento frente a los casos de uso planteados. El objetivo es estudiar cómo mejora el formato extendido sobre el estándar ISDB-Tb tradicional. Asimismo, se exponen las limitaciones del nuevo diseño.
\section{Infraestructura}
La \cref{fig:infra_extended} representa la infraestructura involucrada en la emisión de servicios a través de radiofrecuencia y una red IP.
\begin{figure}[h]
\begin{center}
\includegraphics[width=15cm]{imgs/infraestructura_extendida.png}
\caption{Infraestructura utilizada en la emisión de servicios con el esquema extendido.\label{fig:infra_extended}}
\end{center}
\end{figure}
En adición a los elementos comunes de televisión digital en la norma ISDB-Tb tradicional, el nuevo esquema necesita de dos entidades al final del \emph{pipeline} de producción de contenidos para soportar el \emph{streaming} a través de una red IP: el \textbf{servidor de streaming} y un \textbf{coordinador}.
\subsubsection{Servidor de streaming}
El servidor de \emph{streaming} consiste en un \emph{host} con conexión a la red IP. Su responsabilidad es emitir el contenido audiovisual del servicio reubicado que le corresponde. Los paquetes deben ser dirigidos al grupo y puerto multicast indicados en la información provista a través del \emph{elementary streams relocation descriptor} de la norma ISDB-Tb extendida.
\subsubsection{Coordinador}
Para garantizar que la información provista por el nuevo descriptor y la información de \emph{multicasting} sean congruentes, se requiere esta nueva entidad. El \emph{coordinador} decide qué servicios se emiten en la señal ISDB-Tb de forma tradicional y cuáles por la red IP. Luego, define qué grupo multicast y puerto se usan para la emisión. Con esta información se completa el \emph{elementary streams relocation descriptor} y se configura el servidor de \emph{streaming} multicast.
\subsection{Infraestructura de prueba}
\begin{figure}[h]
\begin{center}
\includegraphics[width=14cm]{imgs/infraestructura_prueba.png}
\caption{Esquema de las pruebas\label{fig:test_scheme}}
\end{center}
\end{figure}
Para las pruebas realizadas cuyos resultados se exponen en este capítulo se utilizó un banco de trabajo representado en la \cref{fig:test_scheme}. Las entidades que pueden observarse son:
\begin{itemize}
\item \textbf{Host Multiplexador:} Controla la moduladora y provee el \emph{transport stream} extendido que se emite a través de la señal modulada. En este punto se introducen los elementos necesarios para señalizar los servicios que se obtienen a través de la red IP, identificada por la dirección IP asignada por el coordinador. Por supuesto, en un escenario ficticio como este, la coordinación se trata de configurar correctamente descriptores y \emph{streaming} únicamente.
\item \textbf{Moduladora}: Convierte el \emph{transport stream} en una señal radioeléctrica modulada.
\item \textbf{Combinador de señales:} Es un dispositivo simple que mezcla la señal modulada que transporta el \emph{transport stream} generado y una señal regular de Televisión Digital Abierta. El objetivo de esta combinación es estudiar la convivencia del flujo de tranporte generado con otros tradicionales.
\item \textbf{Sintonizador:} El sintonizador es la contrapartida de la moduladora, convierte una señal modulada en un \emph{bitstream} intepretable por \emph{Mara}.
\item \textbf{Mara:} Computadora que corre el reproductor de televisión y entrega los servicios al usuario, consumiendo de una u otra fuente de manera transparente.
\item \textbf{Red IP:} Red con soporte de la \emph{suite} de protocolos IP, incluyendo emisión multicast.
\item \textbf{Host de \emph{streaming}:} Emite el flujo de transporte que incluye el servicio reubicado a través del grupo indicado por el coordinador.
\end{itemize}
\subsection{Análisis del flujo de transporte como formato contenedor en redes IP}
Una emisora ISDB-Tb modula una señal que puede ser directamente intepretada por un decodificador. Desde el punto de vista del reproductor de TV, la información que arriba por el dispositivo de sintonización es una secuencia de bytes, no existen para él los aspectos específicos de modulación involucrados. Esta secuencia de bytes recibida se interpreta directamente como un flujo de transporte. Notablemente, este formato provee todas las capas de abstracción necesarias para la comunicación, solucionando problemas como sincronización, multiplexación y corrección de errores.
El caso de las redes IP es radicalmente distinto. Las mismas se basan en el intercambio de paquetes a través de medios indeterminados. Para abstraer los detalles propios de implementación de la comunicación, las redes IP respetan un modelo de capas. El término IP refiere solo a una de estas capas. Pero la información útil que arriba a un \emph{host} no abarca el total recibido, sino que se obtiene luego de un desempaquetamiento que elimina las cabeceras necesarias por las capas inferiores. Entonces, si se asume al flujo de transporte como el punto de vista de carga útil, ISDB-Tb no sufre \emph{overhead}. Las redes IP, en cambio, sí lo hacen. El objetivo de esta sección es analizar cómo influye el \emph{overhead} de los servicios reubicados.
Existe un aspecto negativo de utilizar el flujo de transporte a través de una red IP, como ocurre en los servicios reubicados. Por la duplicidad de capas de abstracción de comunicación mencionada, el \emph{overhead} es en algunos casos redundante. Por ejemplo, los mecanismos de sincronización que provee el flujo de transporte no son necesarios en las redes IP si se alinean los paquetes. También, tanto el \emph{transport stream} MPEG como el protocolo UDP proveen \emph{checksum}\footnote{Si bien podría argumentarse que esto mejora la calidad de control de errores, la realidad es que viola la razón fundamental detrás del modelo de capas.}.
En términos de la \cref{fig:infra_extended}, el enlace entre el servidor de \emph{streaming} y la red IP resulta un eslabón clave en el esquema. Especialmente si se trata de un servidor que debe transmitir varios servicios por la red. La sobrecarga de esta vía implicaría que se vean afectados todos los servicios que emite en caso de alcanzar su límite de acho de banda. Por el contrario, es más extraño encontrar sobrecargas sobre los enlaces de \emph{última milla}\footnote{Término utilizado en telecomunicaciones para referir al último extremo de la red que entrega conexión a los clientes.}. Se puede asumir que estos enlaces van a transportar un pequeño número de servicios simultáneamente, probablemente uno.
\begin{figure}[h]
\begin{center}
\includegraphics[width=14cm]{imgs/infra_multiple_streamers.png}
\caption{Infraestructura con múltiples servidores de \emph{streaming}\label{fig:infra_multiple_streamers}}
\end{center}
\end{figure}
La \cref{fig:infra_multiple_streamers} ilustra el caso en que los servicios se distribuyen a través de múltiples servidores de \emph{streaming}. En este caso, el cuello de botella podría hallarse en alguno de los enlaces \emph{backbone}\footnote{Principales enlaces de datos en una red. En este caso, en particular, refiere a una red IP.} si se tratara de una arista de corte\footnote{En teoría de grafos, refiere a una arista que, si se elimina, aumenta el número de componentes conexas de la topología.}. Sin embargo, este tipo de enlaces dispone del mayor ancho de banda en toda la red.
Encontrar un cuello de botella en la red requiere de una topología, pero es común que los \emph{hosts} posean un único \emph{access point} (y, por ende, un único enlace) a la red. El ancho de banda del mismo limita el número y la calidad de los servicios que puede emitir un único servidor de \emph{streaming}. Para ejemplificar, se presenta la \cref{tab:bandwidth_limits}.
\begin{table}[H]
\begin{center}
\begin{tabular}{ | l | c | c | }
\hline
Ancho de banda disponible & Número de servicios SD & Número de servicios HD \\
\hline
\hline
30 Mbps & 14 & 2 \\
100 Mbps & 47 & 8 \\
1 Gbps & 476 & 82 \\
\hline
\end{tabular}
\caption{Cantidad de servicios que pueden ser emitidos por un enlace, considerando ancho de banda requerido.\label{tab:bandwidth_limits}}
\end{center}
\end{table}
Los valores presentados se basan en mediciones realizadas sobre conexiones ethernet sobre par trenzado, donde el \emph{overhead} de comunicación es de un $4.1\%$, en promedio. Este valor proviene del envío de 7 paquetes\footnote{Es imposible enviar un número mayor de paquetes, dado que es ideal respetar el tamaño de ventana más común para redes IP de 1500 bytes.} de flujo de transporte (1316 bytes) sobre la cabecera del paquete UDP(8 bytes), la cabecera del paquete IP(20 bytes) y la cabecera de la trama \emph{ethernet}(26 bytes).
%El ancho de banda de un enlace de fibra óptica oscila entre valores [podemos medir qué ancho de banda ocupa un servicio hd en una red común y de acuerdo a eso ver qué onda, asumiendo el overhead de los encabezados ip y eso...] (Eth/IP/UDP agrega un 5.5\% de overhead!, cuando en emisión ISDB-Tb es 0. Es decir, las mediciones toman el formato contenedor.)
\section{Análisis del trabajo}
A fin de evaluar la extensión de la norma y el reproductor Mara en un marco práctico, se analizan diversos aspectos relevantes utilizando la infraestructura presentada en \cref{fig:infra_extended} para las ejecución de pruebas. La \cref{tab:evalcomparison} presenta y clasifica los resultados de las evaluaciones. A su vez, incluye referencias a las secciones posteriores, que desarrollan más detalladamente cada prueba o aspecto del análisis. Es importante remarcar que la columna titulada \textbf{ISDB-Tb + IP} analiza los aspectos inherentes a los servicios enviados por IP. Es decir, el diagrama no establece que es imposible enviar \emph{Closed Caption} con la extensión de la norma. Sí afirma que es imposible enviarlo para aquellos servicios que se transmiten por IP.
% \begin{table}[H]
% \begin{tabular}{|r|c|c|c|}
% \hline
% \rowcolor[HTML]{656565}
% \multicolumn{1}{|l}{\cellcolor[HTML]{656565}{\color[HTML]{EFEFEF} Aspecto}} & \multicolumn{1}{c}{\cellcolor[HTML]{656565}{\color[HTML]{EFEFEF} \begin{tabular}[c]{@{}c@{}}ISDB-Tb\\ Tradicional\end{tabular}}} & {\color[HTML]{EFEFEF}ISDB-Tb+IP} & {\color[HTML]{EFEFEF} Ver} \\ \hline
% Número de servicios & Hasta 5 SD y 1 LD & Hasta 50 HD & \cref{sec:maxservicenumber} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0}Con el uso del nuevo descriptor, el máximo número de servicios asciende a 50. La cota es consecuencia del tamaño máximo de la sección de la SDT.} \\ \hline
% \begin{tabular}[c]{@{}r@{}}Múltiples flujos\\ elementales\end{tabular} & \cmark & \xmark & \cref{sec:multipleelementarystreams} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0} Mara no posee la funcionalidad necesaria para entregar múltiples flujos elementales intercambiables. Por otro lado, su inclusión incurriría en un desperdicio innecesario de ancho de banda.} \\ \hline
% \begin{tabular}[c]{@{}r@{}}Guía electrónica de\\ programación\end{tabular} & \cmark & \xmark & \cref{sec:epg} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0}El soporte que ofrece MPEG para la descripción de guía electrónica de programación no basta para el número de servicios que permite la extensión.} \\ \hline
% \textit{Closed Caption} & \cmark & \xmark & \cref{sec:closedcaptioning} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0}Mara actualmente no soporta \emph{closed captioning} para los servicios que se envían por IP. Dependiendo del tipo de los mismos, sería fácil adaptar el reproductor para soportarlo. } \\ \hline
% \begin{tabular}[c]{@{}r@{}}Gestión de audiencias\end{tabular} & \xmark & \cmark & \cref{sec:traceability} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0}En el caso de ISDB-Tb convencional, es imposible determinar qué servicio consume cada usuario. Por el contrario, esto es posible con los servicios enviados por IP.} \\ \hline
% \begin{tabular}[c]{@{}r@{}}Aplicaciones\\ interactivas\end{tabular} & \cmark & \xmark & \cref{sec:interactiveapps} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0} Mara no provee soporte para esta funcionalidad. Si se deseara posibilitar esto, sería necesario un uso diferente de este mecanismo respecto al que utiliza ISDB-Tb.} \\ \hline
% \begin{tabular}[c]{@{}r@{}}Velocidad de\\ sintonización\end{tabular} & 1,8 seg & \begin{tabular}[c]{@{}l@{}}Sintonización + \\ \emph{buffering} (1,7 seg)\end{tabular} & \cref{sec:tunespeed} \\
% \rowcolor[HTML]{C0C0C0}
% \textit{Resumen} & \multicolumn{3}{p{11cm}|}{\cellcolor[HTML]{C0C0C0}Aún para los servicios que se transmiten por IP, es necesario sintonizar la banda de radiofrecuencia que transporta el flujo que señaliza al servicio.} \\ \hline
% \end{tabular}
% \caption{Resumen de características de la solución elaborada.\label{tab:evalcomparison}}
% \end{table}
% \newpage
\begin{sidewaystable}[ph!]
\centering
\caption{Resumen de características de la solución elaborada\label{tab:evalcomparison}}
\begin{tabular}{|r|c|c|m{2cm}|m{8cm}|}
\hline
\rowcolor[HTML]{656565}
{\color[HTML]{EFEFEF}Aspecto} & {\color[HTML]{EFEFEF}\begin{tabular}[c]{@{}l@{}}ISDB-Tb\\ Tradicional\end{tabular}} & {\color[HTML]{EFEFEF}ISDB-Tb + IP} & {\color[HTML]{EFEFEF}Ver} & {\color[HTML]{EFEFEF}Resumen} \\
\hline \hline
\specialcell{Número de\\servicios} & \begin{tabular}[c]{@{}l@{}}Hasta 5 SD y\\ 1 LD\end{tabular} & Hasta 50 HD & \cref{sec:maxservicenumber} & Con el uso del nuevo descriptor, el máximo número de servicios asciende a 50. La cota es consecuencia del tamaño máximo de la sección de la SDT. \\
\hline
\rowcolor{gray}\specialcell{Múltiples Flujos\\ elementales} & \cmark & \xmark & \cref{sec:multipleelementarystreams} & Mara no posee la funcionalidad necesaria para entregar múltiples flujos elementales intercambiables. Por otro lado, su inclusión incurriría en un desperdicio innecesario de ancho de banda. \\
\hline
\specialcell{Guía electrónica \\de programación} & \cmark & \xmark & \cref{sec:epg} & El soporte que ofrece MPEG para la descripción de guía electrónica de programación no basta para el número de servicios que permite la extensión. \\
\hline
\rowcolor{gray}
Closed Caption & \cmark & \xmark & \cref{sec:closedcaptioning} & Mara actualmente no soporta closed captioning para los servicios que se envían por IP. Dependiendo del tipo de los mismos, sería fácil adaptar el reproductor para soportarlo. \\
\hline
\specialcell{Gestión de\\audiencias} & \xmark & \cmark & \cref{sec:traceability} & En el caso de ISDB-Tb convencional, es imposible determinar qué servicio consume cada usuario. Por el contrario, esto es posible con los servicios enviados por IP.\\
\hline
\rowcolor{gray}
\specialcell{Aplicaciones\\interactivas} & \cmark & \xmark & \cref{sec:interactiveapps} & Mara no provee soporte para esta funcionalidad. Si se deseara posibilitar esto, sería necesario un uso diferente de este mecanismo respecto al que utiliza ISDB-Tb. \\
\hline
\specialcell{Velocidad de\\ sintonización} & 1,8s & \begin{tabular}[c]{@{}l@{}}Sintonización\\ + buffering (1,7s)\end{tabular} & \cref{sec:tunespeed} & Aún para los servicios que se transmiten por IP, es necesario sintonizar la banda de radiofrecuencia que transporta el flujo que señaliza al servicio.\\
\hline
\end{tabular}
\end{sidewaystable}
% \renewcommand{\thefootnote}{\fnsymbol{footnote}}
% \taburowcolors[2]{white .. black!20}
% \begin{figure}[h]
% \begin{center}
% \footnotesize
% \tabulinesep=6pt
% \begin{tabu} to 17cm {|>{\cellcolor{black!60}\color{white}}r|X[cm]|X[cm]|X[cm]|X[0.5cm]|}
% \hline
% \rowcolor{black!80}\strut \emph{Aspecto de comparación} & \color{white}ISDB-Tb\newline tradicional & \color{white}ISDB-Tb + IP & \color{white} Resumen & \color{white} Ver \\
% Número de servicios & Hasta 6 SD & Hasta 50 & La calidad de los servicios es indistinta para determinar el máximo número de servicios de la norma extendida & \cref{sec:TODO} \\
% Múltiples flujos elementales & \cmark & \xmark* & Resumen & \cref{sec:TODO} \\
% Guía electrónica de programación & \cmark & \cmark & Resumen & \cref{sec:TODO} \\
% \emph{Closed Caption} & \cmark & \xmark* & Resumen & \cref{sec:TODO} \\
% Gestión de audiencias & \xmark & \cmark & Resumen & \cref{sec:TODO} \\
% Aplicaciones Interactivas & \cmark & \xmark& Resumen & \cref{sec:TODO} \\
% % Independencia de calidad de servicio & \xmark & \cmark \\
% % Sintonización múltiple simultánea & \xmark & \cmark \\
% Velocidad de sintonización & ~$1.8$ seg & Dependiente de la red & Resumen & \cref{sec:TODO} \\
% \hline
% \end{tabu}
% \caption{Comparación entre los servicios de una señal ISDB-Tb y los servicios reubicados. \textbf{(*)} Limitación impuesta por el cliente, Mara. Implementaciones más sofisticadas podrían dar soporte.\label{tab:evalcomparison}}
% % Reemplazar esto por un footnote que explique que esos dos (... como puede verse en la subsección tal ...) son limitaciones de implementacion del cliente, no del estándar. Así no hay que usar el plusmark del orto, que de otra manera, habría uqe explicar.
% \end{center}
% \end{figure}
% \renewcommand{\thefootnote}{\arabic{footnote}}
\section{Número de servicios}\label{sec:maxservicenumber}
El objetivo final del nuevo diseño es extender la lista de servicios provistos por una señal ISDB-Tb convencional, a través del aprovechamiento de redes IP disponibles para el decodificador. En consecuencia se debe analizar la limitación del tamaño de la lista de servicios, considerando la nueva posibilidad de usar el \emph{Elementary Streams Relocation Descriptor}.
Son varios los aspectos que se deben considerar para determinar la verdadera limitación del número de servicios en un flujo de transporte, de acuerdo al formato MPEG. En esta sección se mencionan estos aspectos y se incluye el resultado del análisis, pero para una discusión completa de este punto, ver el \cref{app:appendix_service_number}.
\begin{itemize}
\item \textbf{Tamaño de sección:} El tamaño de sección para la mayoría de las tablas de ISDB-Tb es de 1024 \emph{Kilobytes}. Esto limita el número de entradas y descriptores que pueden incluirse en ellas. Las tablas afectadas son la PAT y la SDT.
\begin{itemize}
\item\textbf{PAT:} Transporta contenidos binarios, por lo que la señalización no ocupa demasiado espacio. En la absoluta mayoría de los casos, toda la información necesaria cabe en un único paquete TS. En una sección de PAT pueden señalizarse hasta 252 servicios.
\item\textbf{SDT:} Transporta información textual sobre el flujo de transporte. En primer lugar esto significa que los contenidos son los más pesados de todas las tablas obligatorias. En segundo lugar, la cantidad de bytes utilizados para la misma depende de los servicios que describe. Para un análisis que supone nombres de servicios de 9 caracteres en promedio, la SDT ubica la cota superior en el número de servicos en 50.
\end{itemize}
\item \textbf{Disponibilidad de paquetes nulos:} La inclusión de servicios no implica que las PMT crezcan, en su lugar aparecen nuevas instancias de la tabla. Es la única tabla con estas características.
\begin{itemize}
\item \textbf{PMT:} La adición de un servicio, de acuerdo al capítulo anterior, requiere del reemplazo de un paquete nulo por uno que contenga una instancia de esta tabla. El formato MPEG establece que debe haber una separación temporal máxima de 200 milisegundos entre instancias de la PMT para un mismo servicio. Con esta restricción, es necesario considerar el \emph{bitrate} del flujo de transporte en el análisis. Para un flujo de transporte similar al de Canal 23 estudiado previamente, la limitación de este aspecto del formato fija el número máximo de servicios en 200.
\end{itemize}
\end{itemize}
En conclusión, el número máximo de servicios, si bien depende de los contenidos del flujo de transporte, responde directamente al formato de específico de la SDT. Y para el caso promedio de 9 caracteres por nombre de servicio, este número es de 50 servicios por flujo de transporte.
\section{Flujos elementales múltiples}\label{sec:multipleelementarystreams}
Es normal que en los servicios de televisión digital se incluyan varios flujos elementales de un mismo tipo para un mismo servicio. Por ejemplo, la emisión de un partido de fútbol podría incluir múltiples audios para permitir la elección del relato a reproducir, posiblemente en distintos idiomas. Esto no suele ocurrir para el video.
En el caso de ISDB-Tb extendido, la red IP emite un flujo de transporte simple. En otras palabras, envía un flujo de transporte que contiene una única señal de video y de audio. Esto puede considerarse una limitación del diseño pero resulta importante, para los servicios que viajan por IP, la eliminación de toda información redundante. Si se emitieran múltiples flujos de audio a través del mismo grupo, entonces algunos de ellos serían ignorados, incurriendo en un desperdicio innecesario de ancho de banda. En otras palabras, todos los audios, salvando aquel que se está reproduciendo, serían inútiles.
Para evitar tal desperdicio, sería posible enviar cada flujo por un grupo multicast distinto. Existen técnicas de transmsión de contenidos donde el ensamble del servicio final percibido se realiza en el cliente de reproducción. Este aspecto de la solución se visita en el capítulo final de Conclusión, en la \cref{sec:futureobjectbased}, como parte de las propuestas de trabajo futuro.
\section{Guía electrónica de programación}\label{sec:epg}
La guía electrónica de programación (o EPG por sus siglas en inglés) contiene información acerca de los eventos en los servicios del flujo de transporte. La información que compone la guía de programación se construye por las emisoras de contenido y se envía a los decodificadores a través de la EIT(\emph{Event Information Table}). Las secciones que componen una EIT pueden alcanzar los 4096 bytes. Cabe remarcar que cada sección guarda un bloque de tres horas de eventos.
Se suele denotar EIT-k a cada sección, donde un k mayor denota un bloque más lejano en el tiempo. Así, EIT-0 describe los eventos de las próximas tres horas y EIT-1 los eventos de las tres horas siguientes. En consecuencia hay 4096 bytes para describir los eventos que ocurren en todos los servicios en el intervalo de tiempo que le corresponde a la sección.
El tamaño de cada descripción de evento depende del título del mismo y del texto asociado. Por esto, es imposible determinar cuántos servicios se pueden describir, pero se puede realizar una estimación sobre el espacio disponible para cada evento, dada una lista de servicios.
Asumiendo que la lista de servicios del flujo de transporte posee 50 entradas (limitación impuesta por la sección de la SDT, ver \cref{sec:maxservicenumber}), y que en tres horas cada servicio auspicia dos eventos, se deben describir 100 eventos.
\begin{figure}[h]
\begin{center}
\includegraphics[width=12cm]{imgs/eit_section_syntax.png}
\caption{Representación ilustrativa de la sintaxis de una sección de EIT\label{fig:eit_section_syntax}}
\end{center}
\end{figure}
La \cref{fig:eit_section_syntax} ilustra el formato de una sección de la EIT. El encabezado de la EIT ocupa los primeros 14 bytes, y cada evento, a su vez, tiene un tamaño base de 12 bytes. Esto significa que de los 4096 bytes disponibles de la sección, 2882 pueden utilizarse para títulos y descripción de eventos. Lo cual da un promedio de $29$ bytes por evento para título y descripción.
\begin{figure}[h]
\begin{center}
\includegraphics[width=14cm]{imgs/eit_size.png}
\caption{Gráfico de puntos que describe la disponibilidad de caracteres para la descripción de eventos en la EIT\label{fig:eit_size}}
\end{center}
\end{figure}
La \cref{fig:eit_size} establece una relación entre el número de eventos a describir y la cantidad de caracteres disponibles. A partir de los 20 eventos, la disponibilidad cae debajo de los 200. En resumen, no es posible describir acordemente todos los servicios incluidos en el flujo de transporte extendido a través de la EIT, salvando la inclusión del nombre del evento y la información textual asociada a alguno de ellos.
\section{\emph{Closed Captioning}}\label{sec:closedcaptioning}
Existen varios estándares ampliamente difundidos para la transmisión de \emph{Closed Caption}. El formato estándar para ISDB-Tb se define en ARIB-B37. Otro tipo también muy difundido, pero más popular en otras normas como ATSC, es CEA 608 y su sucesor CEA 708\cite{ceaclosedcaption}, denominados comúnmente simplemente por el número. Existe una diferencia principal entre ambos formatos que propone una clasificación de los estándares de subtitulado.
\begin{itemize}
\item \textbf{Embebidos}: En esta categoría se encuentran los formatos 608 y 708. Los subtítulos de esta categoría se incluyen en un espacio preasignado de un flujo externo. Por ejemplo, el formato de video H.264 provee un espacio de usuario para incluir, entre otras cosas, subtítulos. La característica que define a esta categoría es que no necesitan señalización en la PMT, dado que los \emph{Closed Caption} forman parte del flujo elemental de video.
\item \textbf{Señalizados}: Categorizamos en este grupo a los canales de \emph{Closed Caption} que deben ser referidos por la \pmt\ y que viajan en un flujo elemental con su propio PID. En esta categoría entra el formato ARIB-37.
\end{itemize}
% Sin embargo, cambios en el cliente son suficientes para proveerlos, dado que no son limitaciones del formato MPEG sino la incapacidad del reproductor de entregarlos al cliente.
Mara no posee la funcionalidad de reproducir ninguno de los dos tipos. La imposibilidad de reproducir subtítulos señalizados viene dada por el diseño de la señalización. La imposibilidad de reproducir los subtítulos embebidos se debe a la forma que Wari reproduce los flujos elementales. La entrega de \emph{Closed Caption} de la primer categoría requeriría de Mara leer la PMT del servicio reubicado para demultiplexar los paquetes que transportan los datos de subtitulado. Para esto, \emph{mpegparser} debería filtrar los paquetes involucrados y realizar el \emph{parsing}.
De forma mucho más simple, los subtítulos de la segunda categoría pueden ser manejados directamente por el reproductor, dado que forman parte del video. El cambio necesario implica enviar un mensaje al reproductor para active la pista de subtítulos correspondiente. La complejidad de la modificación depende el estándar de \emph{Closed Caption}, pero no implica la lectura del flujo de transporte en \emph{mpegparser}, facilitando drásticamente la implementación.
\section{Gestión de audiencias}\label{sec:traceability}
La emisión en las señales ISDB-Tb es \emph{broadcast}. En este esquema los consumidores son anónimos, lo cual implica que es imposible determinar si un receptor está consumiendo un servicio dado. En el caso de los servicios reubicados, las redes IP identifican a los \emph{hosts} unívocamente a través de una dirección IP. Para saber si un receptor consume un servicio tranportado por IP, éste puede ser asociado a una dirección y determinar a qué grupo multicast se ha unido.
Utilizando este tipo de técnicas, sería posible para una entidad con autoridad sobre la red IP que emite los servicios determinar el número de usuarios que consumen determinado servicios, así como ubicación geográfica y otros datos más específicos. Este tipo de mediciones no se puede realizar sobre ISDB-Tb tradicional y, en general, tampoco sobre cualquier esquema \emph{broadcast}.
\section{Aplicaciones Interactivas}\label{sec:interactiveapps}
\textbf{\emph{Digital storage media command and control}}(DSM-CC) es el mecanismo que utiliza la televisión digital para la distribución de aplicaciones interactivas, definido en MPEG-2, parte 6. DSM-CC provee un conjunto de herramientas para el desarrollo de canales de control en un modelo cliente/servidor. Empero, es imposible implementar directamente este modelo en la norma ISDB-Tb por la naturaleza subyacente, donde no existe un canal de retorno para el cliente.
Las emisiones \emph{broadcast} de televisión digital, entonces, hacen uso de un carrusel de datos para solucionar este problema. El mismo consiste en la emisión periódica de los datos disponibles. Para que el cliente pueda acceder al cuerpo de datos que intenta obtener, simplemente debe esperar su emisión. Existen dos motivos por los que el nuevo diseño no puede reubicar contenido DSM-CC a una red IP.
\begin{itemize}
\item \textbf{Implementación}: Actualmente, los contenidos recibidos a través de la red IP son alimentados directamente al reproductor audiovisual. Esto elimina la posibilidad de proveer el \emph{middleware} necesario para la ejecución de las aplicaciones. \emph{Mara} no posee la funcionalidad necesaria para redireccionar el contenido DSM-CC fuera del reproductor de video y audio hacia el intérprete de comandos.
\item \textbf{Diseño}: En una red IP existe un canal de retorno y el modelo cliente/servidor se aplica de manera natural. Además, el ancho de banda no es un flujo constante que debe ser aprovechado, sino que su mala utilización incurre en una sobrecarga innecesaria. Por estos motivos, la adición de soporte DSM-CC sugiere una implementación del protocolo diferente de la utilizada por receptores ISDB-Tb.
\end{itemize}
Si se solucionara la ausencia de implementación de \emph{Mara}, la utilización de contenido DSM-CC en el formato establecido en la norma ISDB-Tb incurriría en un desaprovechamiento considerable del ancho de banda. Especialmente si se tiene en cuenta que la versión original del conjunto de herramientas DSM-CC se adecúa perfectamente al modelo de comunicación unicast con retorno que ofrecen las redes IP.
En conclusión, mientras los servicios audiovisuales de una señal ISDB-Tb se reubican de forma natural como flujos a las redes IP, las aplicaciones interactivas deben ser tratadas de forma diferente. Preferiblemente utilizando el soporte completo que ofrece DSM-CC, para eliminar la necesidad del uso de un carrusel de datos.
% Explicar qué onda con el DSM-CC. Decir cómo funciona, y por qué no tiene sentido que se utilice a través de IP. Lo que sí es interesante, es pensar en una extensión de DSM-CC para referir recursos de internet, si es que no existe aún, porque esto facilita rotundamente el problema del carrusel de datos, etc. Puede estar buena esta sección. Lo importante es decir que el enfoque que la da la tvd a DSM-CC con carrusel de datos no tiene sentido.
% \subsection{Independencia de calidad del servicio}
% En la norma ISDB-Tb tradicional, un flujo de transporte ve limitado el tamaño de su lista de servicios por el ancho de banda constante que ofrece. En el caso de la reubicación de servicios a través del \emph{elementary streams relocation descriptor}, el \emph{bitrate} de los flujos elementales no
%\subsection{Averiguar qué onda con el scrambling y el acceso condicional}
% Se podría stremear el certificado PKI por ISDB-Tb, por ejemplo.
% Un transport stream que refiere a dos servicios diferidos.
% Dos transport streams que refieren a dos servicios diferentes. Uno cada uno.
% Un transport stream que refiere a muchos servicios. Digamos 10.
% Un transport stream que refiere a 2 servicios. Uno de los cuales no tiene emisión.
% Closed caption
% Cómo se comportaría el acceso condicional con el esquema extendido
% Problemas de seguridad? Si alguien se pone a emitir algo en algún momento
% Todo el resto de las cosas deberían funcionar. Ver el tema del bitrate puede ser más complicado.
% Con este esquema es imposible usar varios audios.
% También es imposible mandar video por multicast y audio por ts.
% Todos los flujos elementales se deben enviar por el mismo medio.
% Está bueno que no le interesa al ts si el servicio es HD o SD. Inclusive podría cambiar, supongo yo.
\section{Tiempo de sintonización}\label{sec:tunespeed}
\begin{figure}[h]
\begin{center}
\includegraphics[width=10cm]{imgs/tune_time.png}
\caption{Tiempos de sintonización\label{fig:tune_time}}
\end{center}
\end{figure}
Utilizando la infraestructura de prueba presentada en la \cref{fig:test_scheme} se realizaron mediciones sobre el tiempo de selección de un servicio. La \cref{fig:tune_time} presenta los resultados obtenidos clasificándolos por el servicio \emph{destino}, dado que este valor es independiente del servicio \emph{origen}. Hay cuatro escenarios posibles:
\begin{itemize}
\item El servicio destino se transmite por el mismo canal de radiofrecuencia, de forma tradicional. En la \cref{fig:tune_time} corresponde al destino \emph{regulares}, misma frecuencia.
\item El servicio destino se transmite de forma tradicional, pero por una frecuencia distinta a la sintonizada actualmente. En el gráfico corresponde a los servicios regulares, distinta frecuencia.
\item El servicio destino se transmite por una red IP, y es señalizado por el flujo de transporte sintonizado actualmente. En el gráfico, servicios reubicados, misma frecuencia.
\item El servicio destino se transmite por la red IP, y es señalizado por un flujo de transporte ajeno al actual. En el gráfico, servicios reubicados, distinta frecuencia.
\end{itemize}
La medición de mayor magnitud corresponde a la selección de un servicio tradicional que se transmite por un flujo de transporte distinto al actual, obligando al reproductor a realizar una sintonización de banda. La demora para tal selección es de $1.8$ segundos. Por el contrario, si el servicio sí se encuentra en el mismo flujo de transporte, el tiempo de selección no supera las tres décimas de segundo.
Por las mediciones, es claro que el cuello de botella en el procedimiento radica en la sintonización de banda de frecuencia. Para los servicios cuyos flujos elementales vienen por una red IP, este proceso es innecesario, de modo que es esperable que este tiempo se reduzca drásticamente. Sin embargo, la \cref{fig:tune_time} muestra lo contrario. Para explicar esto, es necesario retomar el proceso de sintonización.
El diagrama de secuencia de la \cref{fig:seqplaymara}, incluida en el capítulo Diseño y Desarrollo, expone el proceso normal de selección de un servicio reubicado para su reproducción, incluyendo la construcción de la URL de reproducción. Un bloque de condición del diagrama encapsula la verificación de correspondencia de flujo de transporte sintonizado y flujo de transporte que contiene al servicio seleccionado. Este bloque comprende la mayoría del tiempo de demora del procedimiento completo. A simple vista, la sintonización física es innecesaria, dado que inmediatamente después, el reproductor pasa a consumir los contenidos desde la interfaz de red, en lugar del dispositivo sintonizador. En realidad, la omisión de este bloque incurriría en la imposibilidad de cambio de información de origen.
Por ejemplo, en el caso de los servicios reubicados, sería imposible cambiar el grupo multicast por el que el servidor que realiza el \emph{streaming}. De lo contrario, los usuarios que encendieran el reproductor antes del cambio, seguirían intentando unirse al grupo multicast antiguo. El único lugar donde se reflejaría el cambio sería en la PAT que viaja en el flujo de transporte correspondiente a la señalización de servicio. Esto sería análogo a memorizar los PID de los flujos elementales provistos por una PMT y usarlos posteriormente. Un eventual cambio de PID para el flujo imposibiliaría la sintonización del servicio.
En resumen, si bien para obtener los flujos elementales de un servicio reubicado no es necesario un cambio de sintonía, el proceso es necesario para garantizar la consistencia del proceso de sintonización. De esta manera, se evita la referencia de grupos multicast obsoletos y se permite la ubicación de nuevos servicios en la red IP.
Con esta sección finaliza el detalle de las evaluaciones realizadas sobre el sistema híbrido. El capítulo final de Conclusión, a continuación, recorre las características desde el punto de vista de los objetivos planteados inicialmente. Además, incluye posibles elementos de trabajo futuro, que complementa los estudios del capítulo de Evaluación.
\ifx\all\undefined
\end{document}
\fi