Estudio de viabilidad técnica e implementación de un...

PROYECTO FINAL DE CARRERA

Estudio de viabilidad técnica e

implementación de un sistema de

transmisión de video adaptativo

H264/SVC sobre TCP

Estudios: INGENIERIA SUPERIOR DE TELECOMUNICACIONES

Autor: MANEL GRAU GRACIA

Tutor: DR. JORGE MATA DÍAZ

JUNIO 2014

Sistema de video adaptativo H264/SVC sobre TCP 2

3 Sistema de video adaptativo H264/SVC sobre TCP

Índice general

Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.1. JSVM y OpenSVCDecoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.2. Proyectos similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.3. Medidas objetivas de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.4. Introducción a H264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.4.1. Predicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4.2. Transformación y cuantificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.3. Codificación entrópica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2. H264/SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1. Conceptos de escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.1. Escalabilidad temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.2. Escalabilidad espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1.3. Escalabilidad de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.1.4. Escalabilidad híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2. Cabecera de las unidades NAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3. Sintaxis de las unidades NAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1. Unidades NAL non-VCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.1.1. Supplemental Enhancement Information . . . . . . . . . . . . . . . . . 34

2.3.1.2. Sequence Parameter Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.1.3. Picture Parameter Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.2. Unidades NAL VCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.2.1. Coded Slice of non-IDR Picture . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.2.2. Coded Slice of an IDR Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.2.3. Coded Slice Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3. Filtrado adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1. Filtrado de unidades NAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.1. Reglas de dependencia en el filtrado de unidades NAL . . . . . . . . . . . . . 38

3.1.1.1. Reglas con escalabilidad espacial y temporal . . . . . . . . . . . . . . 39 3.1.1.2. Reglas con escalabilidad de SNR y uso de MGS . . . . . . . . . . . . . 39

3.1.2. Algoritmo de filtrado de unidades NAL . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.2.1. Algoritmo de extracción sin usar MGS . . . . . . . . . . . . . . . . . . . . 40


3.1.2.2. Algoritmo de extracción usando MGS . . . . . . . . . . . . . . . . . . . . 42 3.2. Filtrado adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1. Orden de transmisión de flujo de datos H264/AVC . . . . . . . . . . . . . . . . 46 3.2.2. Orden de transmisión de flujo de datos H264/SVC . . . . . . . . . . . . . . . . 50 3.2.3. Parámetros de diseño del filtrado adaptativo . . . . . . . . . . . . . . . . . . . . 52

4. Estimación del ancho de banda de transmisión . . . . . . . . . . . . . . . . . . 55

4.1. Protocolo de control de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.1. Cabecera TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1.2. Control de congestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2. Estimación del ancho de banda de transmisión . . . . . . . . . . . . . . . . . . . . . . 61 4.2.1. Tamaño de las capas de extracción en tiempo real . . . . . . . . . . . . . . . . 61 4.2.2. Velocidad de reproducción del video . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.3. Implementación de la estimación en tiempo real del ancho de banda de

transmisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.3.1. Detalles de la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.3.2. Función estimación ancho de banda . . . . . . . . . . . . . . . . . . . . . 68

4.2.4. Estrategias temporales en la estimación del ancho de banda . . . . . . . 69 4.2.4.1. Implementación del uso de iteraciones . . . . . . . . . . . . . . . . . . . 70

5. Transmisor y receptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.1. Implementación del transmisor adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.1.1. Justificación uso de dos hilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.1.2. Clase H264BitStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.1.3. Justificación de semáforos en la cola circular . . . . . . . . . . . . . . . . . . . . 79 5.1.4. Solución de semáforos en la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 81 5.1.5. Solución de ancho de banda adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1.6. Medidas para reducir el alto número de intercambios entre capas . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2. Criterios de diseño del receptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.1. Relación entre tiempo de reproducción y tiempo de transmisión . . . . 88 5.2.2. Estrategia de filtrado en recepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.3. Solución de semáforos de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 95

6. Evaluación del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.1 Características de codificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.1.1 Elección de los parámetros de cuantificación . . . . . . . . . . . . . . . . . . . . 99

6.2 Resultados al aplicar el algoritmo de filtrado . . . . . . . . . . . . . . . . . . . . . . . . 99 6.3 Perfiles de ancho de banda de transmisión . . . . . . . . . . . . . . . . . . . . . . . . 101 6.4 Puesta en escena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.4.1 Prueba 1 - Ancho de banda límite de 300 Kbit/s . . . . . . . . . . . . . . . . . 107 6.4.2 Prueba 2 - Ancho de banda límite de 600 Kbit/s . . . . . . . . . . . . . . . . . 111

6.4.3 Prueba 3 - Ancho de banda límite de 1,3 Mbit/s . . . . . . . . . . . . . . . . . 115


6.4.4 Prueba 4 - Ancho de banda variable de 1,3 Mbit/s y 600 Kbit/s . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.4.5 Prueba 5 - Ancho de banda de 1,3 Mbit/s compartido . . . . . . . . . . . . 120

7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.1 Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

APÉNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

A. Ficheros de configuración del codificador de JSVM utilizados en las

simulaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

B. Sintaxis H264/SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

C. Manual de utilidades del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

C.1. Utilidades de vídeo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 C.2. Utilidades de compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 C.3. Utilidades desarrolladas en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156


Lista de Figuras

1.1. Esquema de codificación H264/AVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2. Esquema intra-predicción de bloques 4x4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.3. Esquema intra-predicción de bloques 16x16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.4. Esquema inter-predicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1. Esquema de codificación H264/SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2. Estructura de bipredicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3. Estructura diádica y no diádica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4. Escalabilidad espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5. Estructuras de dependencia de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6. Estructura del primer byte de la cabecera de las unidades NAL . . . . . . . . . . . . 30

2.7. Tipos de unidad NAL H264/AVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.8. Tipos de unidad NAL H264/SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.9. Estructura de los tres últimos bytes de la cabecera de las unidades NAL en

H264/SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1. Estructura de la codificación, con capa base, capa de calidad mejorada y capa

de resolución superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2. Estructura de la codificación, con capa base, capa de calidad mejorada con uso

de MGS y capa de resolución superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3. Flujo de inicio con tamaño de GOP igual a 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46



3.6. Flujo normal con tamaño de GOP igual a 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47



3.9. Flujo en IDR múltiple periodo intra-predicción con tamaño de GOP igual a 2 . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.12. Flujo en IDR no múltiple periodo intra-predicción con tamaño de GOP igual a 2 .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.15. Flujo inicio codificación con tres capas, capa base, capa calidad mejorada y capa

de resolución superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


3.16. Flujo normal codificación con tres capas, capa base, capa calidad mejorada y

capa de resolución superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.17. Flujo en IDR múltiple periodo intra-predicción codificación con tres capas, capa

base, capa calidad mejorada y capa de resolución superior . . . . . . . . . . . . . . . . . . 51

3.18. Flujo en IDR no múltiple periodo intra-predicción codificación con tres capas,

capa base, capa calidad mejorada y capa de resolución superior . . . . . . . . . . . . . . 52

3.19. Intercambio entre capas 110 y 011 en flujo normal. Caso 1 . . . . . . . . . . . . . . . 53

3.20. Intercambio entre capas 110 y 011 en flujo normal. Caso 2 . . . . . . . . . . . . . . . 53

3.21. Intercambio entre capas 110 y 011 en flujo IDR múltiple periodo intra-

predicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.22. Intercambio entre capas 110 y 011 en flujo IDR no múltiple periodo intra-

predicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1. Fases de establecimiento y finalización de conexión . . . . . . . . . . . . . . . . . . . . . 56

4.2. Casos de transmisión: Paquete enviado y reconocido, retransmisión y paquete

duplicado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.3. Ejemplo de control de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.4. Cabecera TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5. Fase “slow start” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.6. Ejemplo control de congestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1. Ciclo de histéresis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1. Algoritmo extracción hasta la capa 000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100






6.7. Perfil de ancho de banda: Capa 000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102






6.13. Escenario de red para las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.14. Flujo transmitido: Prueba 300 Kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.15. Perfil de transmisión según opciones del socket: Prueba 300 Kbit/s . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.16. Intercambio entre capas: Prueba 300 Kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . 108



. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111





. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114


6.23. Flujo transmitido: Prueba 1,3 Mbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.24. Perfil de transmisión según opciones del socket: Prueba 1,3 Mbit/s . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.25. Intercambio entre capas: Prueba 1300 Kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.26. Flujo transmitido: Prueba 1300-600-1300 Kbit/s . . . . . . . . . . . . . . . . . . . . . . . 118

6.27. Perfil de transmisión según opciones del socket: Prueba 1300-600-1300 Kbit/s .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.28. Intercambio entre capas: Prueba 1300-600-1300 Kbit/s . . . . . . . . . . . . . . . . . 120

6.29. Perfil de transmisión según opciones del socket: Prueba 1,3 Mbit/s compartido .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.30. Intercambio entre capas: 1,3 Mbit/s compartido . . . . . . . . . . . . . . . . . . . . . . . 121


Lista de Tablas

2.1. Lista de ejemplos de codificación Exp-Golomb . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1. Resultados algoritmo de extracción para el ejemplo 1 . . . . . . . . . . . . . . . . . . . . 41

3.2. Resultados algoritmo de extracción para el ejemplo 2 . . . . . . . . . . . . . . . . . . . . 44

6.1. Parámetros de cuantificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.2. PSNR obtenidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.3. Medias y desviaciones típicas del ancho de banda de transmisión . . . . . . . . . 105


Agradecimientos

Les doy las gracias y le dedico este proyecto a mi familia por su apoyo y comprensión

durante el largo trayecto universitario así, como el de realización del PFC.

También, le doy las gracias al director de mi proyecto, Jorge Mata Díaz por su ayuda y

tutelaje en el desarrollo del PFC, en el que gran parte de haberlo llevado a buen puerto

es gracias a él.


Resum

Durant els últims 20 anys, la comunitat científica ha estat estudiant la possibilitat de

desenvolupar un sistema de video escalable. Es va intentar desenvolupar als anys 90 a

l’estàndard MPEG2, però no va arribar a desenvolupar-se lo suficientment per a poder

convertir-lo en un projecte comercial.

L’any 2003, va aparèixer l’estàndard H264, amb el que es va aconseguir una millora important

en la taxa de compressió de video respecte al seu antecessor MPEG2. Es va aconseguir

mantenir la qualitat de la seqüencia de video amb taxes de compressió fins a un 50% més

grans que a l’estàndard anterior.

Amb el pas dels anys, s’han anat afegint annexos a l’estàndard H264, essent el més important

l’annex G, “Scalable Video Coding”, corresponent a l’ús de video escalable. Un flux escalable,

es defineix com aquell flux de dades, que pot ser descodificat i conformant amb l’estàndard al

filtrar fins a uns determinats atributs, eliminant part del flux de dades.

H264/SVC consta de tres atributs de dependència, els identificadors temporals, se resolució i

de qualitat. D’aquesta manera, SVC permet codificar una mateixa seqüencia de video amb

capes de millora de PSNR objectiva, i de millora de resolució. Per exemple, una seqüencia de

video codificada amb tres capes, capa base, capa de millora de qualitat i capa amb més

resolució, donarà lloc a diferents possibilitats de filtratge. És a dir, serà possible la extracció de

fluxos conformants amb resolució més alta i més baixa, diferents velocitats de reproducció, y

diferents PSNR.

L’objectiu d’aquest projecte, és el desenvolupament d’una aplicació de video escalable sota

demanda funcionant sobre el protocol de transport TCP. L’adequació al tipus de video i a les

condicions de xarxa són els paràmetres de disseny principals de l’aplicació. Concretament, el

principal objectiu ha obtenir, és que les transmissions de video siguin adaptatives a la connexió

de xarxa.

Actualment, existeixen molts sistemes de video sota demanda que utilitzen solucions

propietàries, com en el cas de “Flash Media Server”, i unes altres que utilitzen H264/SVC

(“Advanced Video Coding”), l’annex A de l’estàndard. Les dues més importants són sistemes de

video sota demanda i punt a punt a Internet, com per exemple, Youtube; i la Televisió Digital

Terrestre (TDT). Ambdós sistemes son susceptibles a l’aparició d’errors, i cadacún els combat

de forma diferent. Als sistemes de video per Internet, quan es perd un paquet utilitzant TCP, es

reenvia, en canvi, a la TDT s’utilitza OFDM per minimitzar els errors.

Els paràmetres principals de la connexió de xarxa que s’utilitzaran per a fer el sistema

adaptatiu, són l’ample de banda disponible, i el temps d’anada i tornada del paquets. El

paràmetre d’ample de banda disponible serà estimat pels “sockets” a partir de la grandària de

la finestra de congestió i el RTT de la connexió. D’aquesta manera, l’estratègia a seguir, serà

l’estimació a temps real dels amples de banda necessaris per transmetre fins una determinada

capa, i transmissions amb l’ample de banda més gran que sigui menor al disponible. Per

aconseguir-ho, es fa l’estimació de les longituds incloses a cada extracció (per a capes


superiors a la capa base, s’inclouran unitats NAL amb diferents atributs), i es rectifica l’ample

de banda amb la velocitat de reproducció, per a obtenir les estimacions en temps real.

Els instants d’estimació, vindran limitats per l’algoritme de filtrat adaptatiu. No serà possible

fer estimacions després de cada unitat NAL, perquè els fluxos amb canvis temporals de nivells

d’extracció, estaran limitats pel fet que cada tira B depèn de les dos tires I, P o B anteriors.

Això, fa que només es puguin elegir com a punts de tall les tires I amb DTQ igual a 000. A més,

les extraccions adaptatives seran d’alguna de les dues formes següents:

1. Canviar d’identificadors al punt de tall i filtrar les tires B següents.

2. Filtrar les tires I del canvi amb els identificadors anteriors i posteriors, incloent totes

les tires I que compleixin algun del dos requisits, i filtrar les tires B posteriors amb els

identificadors anteriors en temps, ja que depenen de les dos tires I, P o B anteriors.

L’altre paràmetre de la connexió de xarxa, és el temps de recepció. Per al cas d’un receptor en

temps real, es defineixen les següents estratègies de filtratge. Quan una unitat NAL es rebuda

més tard que l’instant de reproducció, es filtra automàticament. A més, s’ha de tornar a filtrar

al final de cadascuna de les iteracions (entre tira I amb DTQ igual a 000 i la següent amb els

mateixos atributs) amb els nous atributs límit obtinguts després de filtrar les tires que no han

arribat a temps, per a que el flux segueixi sent conformant.

En aquest projecte, s’han realitzat probes de xarxa en un entorn real, per a provar la utilitat del

sistema desenvolupat. Concretament, s’ha codificar el video BigBuckBunny amb tres capes,

capa base, capa de millora de qualitat i capa amb més resolució; i s’ha provat el sistema amb

dos routers entremitjos. Els resultat indiquen que realment es tracta d’un sistema que pot ser

l’alternativa als sistemes actual, sempre que es disposi d’una connexió de banda ampla.


Resumen

Durante los últimos 20 años, la comunidad científica ha estado estudiando la posibilidad de

desarrollar un sistema de video escalable. Se intentó desarrollar en los años 90 en el estándar

MPEG2, pero no llego a desarrollarse lo suficientemente para poder convertirlo en un proyecto

comercial.

En el año 2003, apareció el estándar H264, que conseguía una mejora importante en tasa de

compresión de video respecto a su antecesor MPEG2. Se consiguió mantener la calidad de la

secuencia de video con tasas de comprensión un 50% mayores al anterior estándar.

Con el paso de los años, se han ido añadiendo anexos al estándar H264, siendo el más

importante el anexo G, “Scalable Video Coding”, correspondiente al uso de video escalable. Se

define un flujo escalable, como aquel flujo de datos, que puede ser decodificable y

conformante con el estándar al filtrar hasta unos determinados atributos, eliminando parte del

flujo de datos.

H264/SVC consta de tres atributos de dependencia, los identificadores temporales, de

resolución y de calidad. De esta forma, SVC permite codificar una misma secuencia de video

con capas de mejora de PSNR objetiva, y de mejora de resolución. Por ejemplo, una secuencia

de video codificada con tres capas, capa base, capa de mejora de calidad y capa con más

resolución, dará lugar a varias posibilidades de filtrado. Es decir, será posible la extracción de

flujos conformantes con mayor y menor resolución, distintas velocidades de reproducción, y

PSNR diferentes.

El objetivo del presente proyecto, es el desarrollo de una aplicación de video escalable bajo

demanda sobre el protocolo de transporte TCP. La adecuación al tipo de video y a las

condiciones de red son los parámetros de diseño principales de la aplicación. En concreto, el

principal objetivo a alcanzar es que las transmisiones de video sean adaptativas a la conexión

de red.

Actualmente, existen muchos sistemas de video bajo demanda que utilizan soluciones

propietarias como es el caso de “Flash Media Server” de Adobe, y otras que utilizan H264/AVC

(“Advanced Video Coding”), el anexo A del estándar. Las dos más importantes son sistemas de

video bajo demanda punto a punto en Internet como Youtube; y la Televisión Digital Terrestre

(TDT). Ambos sistemas son susceptibles de la aparición de errores, y cada uno de ellos lo

combate de forma distinta. En los sistemas de video por Internet, cuando se pierde un paquete

utilizando TCP, se reenvía, mientras que en la TDT se utiliza OFDM para minimizar los errores.

Los parámetros principales de la conexión de red que se van a utilizar para hacer el sistema

adaptativo son el ancho de banda disponible, y el tiempo de ida y vuelta de los paquetes. El

parámetro de ancho de banda disponible va a ser estimado por los “sockets” a partir del

tamaño de la ventana de congestión y el RTT de la conexión. De esta forma, la estrategia a

seguir será la estimación en tiempo real de los anchos de banda necesarios para transmitir

hasta una determinada capa y transmisiones con el ancho de banda mayor que sea menor al

disponible. Para lograrlo, se hace la estimación de los tamaños incluidos en cada extracción


(para capas superiores a la base, se incluirán unidades NAL con diferentes atributos), y se

rectifica el ancho de banda con la velocidad de reproducción, para obtener las estimaciones en

tiempo real.

Los instantes de estimación vendrán limitados por el algoritmo de filtrado adaptativo. No será

posible hacer estimaciones detrás de cada unidad NAL, porque los flujos con cambios

temporales de niveles de extracción, vendrán limitados por el hecho de que cada tira B

depende de las dos tiras I, P o B anteriores. Esto hace que solo pueda cogerse como punto de

corte las tiras I con DTQ igual a 000. Además, las extracciones adaptativas van a ser de una de

las dos formas siguientes:

1. Cambiar de identificadores en el punto de corte y filtrar las tiras B siguientes

2. Filtrar las tiras I del cambio con los identificadores anteriores y posteriores, incluyendo

todas las tiras que cumplan uno de los dos requisitos, y filtrar las tiras B posteriores

según los identificadores anteriores en tiempo, debido a que dependen de las dos tiras

I, P o B anteriores.

El otro parámetro de la conexión de red, es el tiempo de recepción. En el caso de un receptor

para trabajar a tiempo real, se definen las siguientes estrategias de filtrado. Cuando una

unidad NAL es recibida en un instante temporal mayor al instante de reproducción, se desecha

automáticamente. Además, se debe volver a filtrar al final de cada iteración entre I con DTQ

igual a 000 y la siguiente, con los nuevos atributos limite obtenidos después de filtrar las tiras

que no han llegado a tiempo, para que el flujo resultante siga siendo conformante.

En el presente proyecto, se han realizado pruebas de red en un entorno real, para probar la

utilidad real del sistema desarrollado. En concreto, se ha codificado el video BigBuckBunny con

tres capas, capa base, capa de mejora de calidad y capa con más resolución; y se ha probado el

sistema con el uso de dos routers intermedios. Los resultados indican que realmente se trata

de una alternativa válida a los sistemas actuales, siempre que se disponga de una conexión de

ancha banda.


Abstract

During last 20 years, scientific community has been studying scalable video coding developing

possibility. In nineties, they try to develop it in MPEG2 standard, but it was not enough

developed in order to become a commercial project.

In year 2003, it appears H264 standard, getting a significant improvement of video

compression tax against his predecessor MPEG2. They got maintain quality video sequence

achieving 50% major video compression taxes.

During years, H264 annex has been appeared. The most important annex is G annex, “Scalable

Video Coding”, which corresponds to scalable video use. An scalable bit stream is defined as

that bit stream which could be decoded and standard confortable when it is filtered with

specific attributes, deleting part of bit stream.

H264/SVC standard has three dependency attributes, temporal, resolution and quality

identifiers. Thus, SVC allows to code the same video sequence with PSNR and resolution

improvement layers. For example, a coded video sequence of three layers, base layer,

improvement quality layer and improvement resolution layer, become in different filtering

possibilities. Therefore, it could be possible conformant extractions with different PSNR,

resolution and playing velocity.

The project objective is develop an scalable video on demand application over TCP protocol.

Principal application parameters are video type and net conditions adequacy. Specifically,

achieved principal objective is that video transmissions become network connection adaptive.

Actually, it exists a lot of video on demand systems, which use proprietary solutions such as

“Flash Media Server”, or they use H264/AVC (“Advanced Video Coding”), A annex of H264

standard. Two most important applications are point to point Internet video on demand

systems and Digital Television (TDT). Both systems are susceptible of error appearance but

each one fight differently errors. In Internet video systems, when a packet is lost using TCP, it

is forwarded, while in TDT it is used OFDM in order to minimize transmission errors.

Principal network connection parameters, which will be used in order to become and adaptive

system, are available network bandwidth and packet round trip time. Available bandwidth

parameter will be estimated by sockets from congestion window size and connection RTT.

Thus, the strategy will be real time estimation of necessary bandwidth in order to transmit up

to a certain layer, and transmit with maximum bandwidth less than available bandwidth. In

order to achieve this, extraction included sizes are estimated (for superior layers than base

layer, it will be included NAL units with different attributes), and it is rectified bandwidth with

playing velocity, in order to obtain real time estimations.

Estimation moments are limited by adaptive filter algorithm. It could not be possible to

estimate after every NAL unit, because bit streams with temporal changes, will be limited by

the fact that every B slice depends on last two I, P or B slices. Therefore, it could only catch

cutoff point in I slices with DTQ equal to 000. Furthermore, adaptive extractions will be of one

of the two following:


1. Change identifiers in cutoff point and filter following B slices.

2. Filter change I slices with both identifiers, previous and posterior, including all slices

which comply one of both requisites, and filter posterior B slices by previous time

identifiers, due to, they depend on last two I, P or B slices.

The other network connection parameter is receiver time. In real time applications, there are

defined the following filtering strategies. When a NAL unit is received after its playing moment,

it is filtered. Furthermore, it has to be filtered another time after every iteration between I

slice with DTQ equal 000 and following next I slice with DTQ equal 000, with new limit

attributes obtained after filtering slices which had not arrived at time, in order to obtain a

H264 conformant resultant bit stream.

In this project, there have been made network test in a real environment, in order to check

developed system real utility. Specifically, it has been coded BigBuckBunny video sequence

with three layers, base layer, PSNR quality improvement layer, and resolution improvement

layer; and it has been checked the system by the use of a network environment which contain

two intermediate routers. Obtained results indicate that it is really a valid alternative to actual

systems, if we have a broadband connection.


Capítulo 1:

Introducción:

En los últimos años se han desarrollado un gran conjunto de sistemas de video bajo

demanda en diferentes entornos, desde sistemas de televisión por pago, hasta

sistemas de videos bajo demanda en Internet, como por ejemplo “Youtube” o

“Vimeo”.

El objetivo del presente proyecto, es el desarrollo de otro sistema de video bajo

demanda, que sea adaptativo a las condiciones de red, y que tome provecho de las

diferentes características del video transmitido. Así, la principal innovación del

presente proyecto es el hecho de trabajar con H264/SVC, la extensión del estándar

H264 en su anexo G. El estándar es el documento “ITU-T H.264 Advanced video coding

for generic audiovisual services (2012).

Hasta ahora, la mayoría de sistemas bajo demanda habían sido implementados con los

protocolos RTP (“Real Time Transport Protocol”), o sus versiones con mejoras de

seguridad RTSP (“Real Time Streaming Protocol”) y RTCP. También en versiones

comerciales como el caso de Adobe con “Flash Media Server” junto con toda la

tecnología “Flash”, “ActionScript” y “Flex”, que mediante el uso de códec propietarios

(“VP6 Sorenson” en el video) permitía el desarrollo de sistemas de video bajo demanda

sobre HTTP y TCP.

El principal reto que se nos plantea en el presente proyecto, es el del desarrollo de un

sistema que sea fiable extremo a extremo independientemente de cual sea su sistema

de acceso (“Wifi”, “ADSL”, “WiMAX”, “FTTH”, …), razón por la cual se va a trabajar

sobre TCP, protocolo orientado a conexión, fiable y con control de errores extremo a

extremo. Se tendrá que tratar con todos los problemas asociados a su uso, como es el

caso que al inicio de la conexión, en la etapa de “slow start” las transmisiones no van a

ser lo suficientemente rápidas como para que se pueda recibir el contenido en tiempo

de reproducción, razón por la que se van a utilizar búferes en recepción para controlar

el flujo transmitido.

En concreto, con el uso de H264/SVC, que define los flujos de datos con diferentes

atributos de escalabilidad nos permitirá transmitir hasta una determinada capa

durante un cierto tiempo, y hasta otra determinada capa durante otro cierto tiempo.

La idea principal es la de codificar con diferentes capas con atributos de velocidad de

reproducción, resolución y PSNR diferentes, combinándolos todos en un flujo de datos

único. De esta manera será posible filtrar con unos determinados atributos de los

comentados anteriormente, para transmitir con condiciones del video cambiantes, que

se adapten a las condiciones de red existentes.


Así, la conexión de red vendrá principalmente caracterizada por el ancho de banda

disponible para transmisión y el tiempo de transmisión extremo a extremo,

parámetros de los que se va a sacar provecho en la búsqueda de un algoritmo de

transmisión que sea adaptativo a estas condiciones de red. En concreto, se van a

controlar los tamaños de transmisión de las diferentes capas en busca de la capa con

mayor calidad posible para ser transmitida, que cumpla la restricción que el tamaño

transmitido se pueda recibir y decodificar en tiempo real.

El proyecto constara de los capítulos siguientes:

1. Presentación de H264 y del software disponible para H264/SVC.

2. Descripción detallada de H264/SVC.

3. Descripción detallada de los algoritmos de filtrado y de filtrado adaptativo de

flujos de datos H264/SVC.

4. Descripción detallada de TCP y de la estimación del ancho de banda de

transmisión.

5. Descripción detallada de la implementación del sistema transmisor y de los

criterios de diseño del receptor en caso de buscar un sistema en tiempo real.

6. Resultados obtenidos y líneas futuras.

1.1. JSVM y OpenSVCDecoder:

Actualmente, existen un codificador y dos decodificadores de H264/SVC. El software

correspondiente es “Join Scalable Video Model” (JSVM) y “OpenSVCDecoder”.

JSVM, es un software desarrollado por el “Joint Video Team” del ISO/IEC “Moving

Pictures Experts Group” (MPEG) y el ITU-T “Video Coding Experts Group” (VCEG), capaz

de codificar y decodificar flujos de video en el estándar H264/SVC.

“OpenSVCDecoder” es una librería desarrollada por el IETR/INSA de la ciudad de

Rennes, que implementa un decodificador de flujos H264/SVC en tiempo real.

“OpenSVCDecoder” se usa conjuntamente con el reproductor “Mplayer” y permite

visualizar flujos de datos codificados en SVC.

1.2. Proyectos similares:

El proyecto más similar al que se presenta en este documento, es el “MPEG DASH

(Dynamic Adaptive Streaming over HTTP)”, el cual a diferencia del actual que trabaja

con SVC, trabaja con la transmisión de flujos H264/AVC.

El parámetro de diseño principal de “MPEG Dash” es que concentra flujos de

diferentes calidades (parámetro de cuantificación diferente), y los transmite


adaptativamente a las condiciones de red, seleccionando las unidades NAL de un flujo

o de otro en función de las condiciones de red.

El funcionamiento es inverso al proyecto actual, en este caso la estimación se hace en

recepción, donde a partir del tamaño de ocupación del buffer se hace una estimación

del ancho de banda al que se va a solicitar la recepción. Se entiende que cuando se

llena se puede pedir más velocidad de transmisión porque la velocidad de red es

mayor a la de reproducción, y que cuando se vacía se debe reducir la velocidad de

transmisión.

Los perfiles de los proyectos son muy similares, pero la diferencia principal es que en

“MPEG Dash” se transmite flujo AVC, y en el presente proyecto se transmiten flujos

SVC, con las ventajas asociadas a este estándar.

1.3. Medidas objetivas de calidad:

Para medir objetivamente una secuencia de video utilizamos el PSNR (“Peak Signal to

Noise Ratio”) en dB. Se define como el coeficiente entre el valor máximo que puede

tener una secuencia al cuadrado y el error cuadrático medio de la secuencia.

Se considera como una medida de calidad objetiva, ya que cuantifica el error

producido en el tratamiento de la secuencia de video. En general, cuanto mayor sea la

PSNR en dB mayor será la calidad de la secuencia de video reconstruida.

1.4. Introducción a H264:

H264 es un estándar de codificación digital de video que introduce muchas mejoras de

compresión respecto a sus predecesores MPEG2 y MPEG4 Visual, de los que hereda

muchas de sus características de codificación.

H264 está desarrollado por “Joint Video Team”, formado a su vez por los equipos del

ITU-T VCEG y el ISO/IEC MPEG. El documento estándar publicado en 2003, no define

como codificar el video, pero sí define toda la implementación del decodificador, con

lo que para codificar se puede llevar a cabo el procedimiento inverso.


A continuación se van a ver las principales características del proceso de codificación y

decodificación.

El proceso de codificación consta de tres etapas principales:

1. Predicción: Ya sea intra-predicción o inter-predicción, en función de si se

predice desde el propio a anteriores fotogramas.

2. Transformación y cuantificación: Se pasa la información al dominio

transformado y se cuantifica.

3. Codificación entrópica: Codificación en palabras de longitud variable del

resultado.

Figura 1.1: Esquema de codificación H264/AVC

1.4.1. Predicción:

El codificador procesa todo el contenido del fotograma en macro-bloques que van de

16x16 a 4x4 en muestras de luminancia y de 8x8 a 2x2 en muestras de crominancia,

debido al submuetreo 4:2:0 del video. Durante este proceso se realizan predicciones a

partir de los bloques ya codificados. Se conoce como Intra-predicción cuando los

macro-bloques proviene del mismo fotograma, y como Inter-predicción cuando los

macro-bloques proviene de otro fotograma previamente codificado.

La predicción será necesaria en función del error cuadrático medio, en los Intra-

predecidos habrá casos en que será más eficiente enviar su información directamente.

En los casos en que sí sea necesario realizar la predicción, se obtiene el residual entre

la predicción hecha y los valores del macro-bloque actual.

La inter-predicción se conoce como estimación de los vectores de movimiento,

mientras que la compensación de movimiento es el proceso de la obtención de los

residuales a partir de la Inter-predicción.


La Intra-predicción utiliza bloques de 16x16 hasta 4x4 píxeles para realizar la

predicción a partir de los macro-bloques contiguos. Las formas de extrapolar para los

casos de 4x4 muestras son las siguientes:

Figura 1.2: Esquema intra-predicción de bloques 4x4

Como se puede ver en la figura 1.2, las formas de extrapolar en el caso de 4x4 muestras son de

arriba abajo, prediciendo las muestras inferiores a partir de las superiores; de izquierda a

derecha, promediando las muestras de arriba y de la izquierda; y varias combinaciones en

diagonal dando más peso a muestras de dos de los lados del macro-bloque.

Y en el caso de 16x16 muestras:

Figura 1.3: Esquema intra-predicción de bloques 16x16

Como se puede ver en la figura 1.3, las formas de extrapolar en el caso de 16x16

muestras son de arriba abajo, de izquierda a derecha, promediando las muestras de

arriba y de la izquierda y en combinaciones diagonales de las muestras de abajo a la

izquierda y arriba a la derecha.

La inter-predicción se hace con bloques de 16x16 píxeles a 4x4 píxeles, y se utiliza para

sacar provecho de las regiones similares entre diferentes fotogramas. Tal como se

puede ver en la figura 1.4 se predicen regiones del fotograma predicho a partir de

macro-bloques de los fotogramas de referencia, cogiendo tamaños variables con

bloques de 16x16 a 4x4 muestras, en función del error cuadrático medio de la

predicción.


Figura 1.4: Esquema inter-predicción

1.4.2. Transformación y cuantificación:

En H264, se transforma a partir de la “Transformada Discreta del Coseno” (DCT), para

obtener un conjunto de coeficientes prácticamente incorrelados y en los que la energía

se concentra en un poco número de ellos.

La DCT se basa en multiplicar por delante y por detrás por una matriz A y A transpuesta

respectivamente, a la matriz que contiene los coeficientes. Los coeficientes de la

matriz son:

Para el caso de 4x4 muestras, la matriz A es la siguiente:

A la salida de la transformación, tendremos un bloque de coeficientes transformados,

en los que la energía se va a concentrar en pocos de ellos. Una vez se ha transformado

se pasa al proceso de cuantificación, en el que a partir de un parámetro de

cuantificación (QP) se van dividiendo por el parámetro de cuantificación los

coeficientes resultantes, dando lugar a muchos ceros. De esta forma, cuando mayor

sea el parámetro de cuantificación, mayor será el número de ceros y más información

se perderá, y cuanto menor sea más información se conservará y, por lo tanto, mejor

calidad tendrá el video reconstruido.

1.4.3. Codificación entrópica:


El resultado de la transformación y cuantificación en forma de coeficientes

transformados o de residuales de la predicción deben ser estructurados de alguna

forma para la posterior transmisión en forma de flujo.

En H264 se utilizan dos codificaciones entrópicas con palabras de longitud variable.

Estas codificaciones son “Context Adaptive Variable Length Coding” (CAVLC) y “Context

Adaptive Binary Arithmetic Coding” (CABAC).

La diferencia principal entre las dos codificaciones es que con CABAC se consiguen

compresiones mayores aunque su complejidad algorítmica es mucho mayor que en

CAVLC, lo que se traduce en la necesidad de más recursos computacionales para poder

llevar a cabo las codificaciones.

En este proyecto, se ha elegido el uso de CAVLC, y se va a ver como realmente se

consiguen altas tasas de compresión, a pesar de ser el algoritmo con tasas de

compresión menores entre los dos a elegir.


Capítulo 2:

H264/SVC:

En este capítulo vamos a ver todos los conceptos necesarios sobre el anexo G del

estándar H264, para facilitar la correcta comprensión del proyecto en desarrollo.

Partiendo de la definición de flujo decodificable en H264/AVC, se generaliza en

H264/SVC el concepto de flujo de datos escalable, como el flujo tal que se pueden

extraer sub-flujos decodificables, dividiendo el flujo de datos en distintas capas.

Se muestra a continuación el esquema general de codificación del H264/SVC.

Figura 2.1: Esquema de codificación H264/SVC

2.1. Conceptos de escalabilidad:

En H264/SVC se definen tres tipos de escalabilidad, escalabilidad temporal, ya propia

de H264/AVC, escalabilidad espacial, que consiste en diferentes capas con resolución

espacial diferente, y escalabilidad de calidad, que consiste en diferentes pasos de

cuantificación (QP), dando lugar a capas de mayor o menor PSNR.

2.1.1. Escalabilidad temporal:


Se define la escalabilidad temporal como la capacidad de partir en tiempo una capa en

diferentes casos de identificador de dependencia temporal (T0, …, Ti). La escalabilidad

temporal, ya es propia del estándar H264/AVC, de forma que funciona igual en AVC

que en SVC.

Se entiende por escalabilidad temporal los niveles de dependencia entre tiras B, de

forma que cada nueva capa que se añade se traduce en doblar el número de tiras B de

la estructura del orden de reproducción. Las tiras B se forman de la forma siguiente.

Figura 2.2: Estructura de bipredicción

En las tiras B se realiza un proceso de bipredicción, a partir de las listas cero y uno de

tiras I, P o B anteriores y posteriores al orden de reproducción. En el uso de

escalabilidad temporal se utilizan estructuras de predicción jerárquicas y diádicas. En

general en el caso de estructuras diádicas se obtiene un número de capas

correspondiente al logaritmo en base dos del tamaño de GOP más uno.

número de capas = log(GOP_size) + 1

Existen tres casos a contemplar, como se verá en la figura siguiente, estructura diádica,

no diádica y el caso de solo usar tiras P inter-predichas.

La estructura diádica es cuando se multiplica por dos el número de tiras B al

incrementar el número de identificadores de escalabilidad temporal. En concreto,

cuando se pone la primera B se añade una entre tiras I y P, y a partir de la primera B

con cada identificador temporal que se añade se añaden el doble de tiras I de las que

había. De esta forma se genera una estructura en la que las tiras B que se añaden se

van intercalando a derecha e izquierda de las otras tiras I, P o B anteriores en tiempo

de transmisión formando la estructura que se muestra en el caso a) de la figura 2.3.

Este caso se corresponde con una estructura diádica con un tamaño de GOP igual a

ocho, dando lugar a la capa base más tres capas de mejora.


El caso b) muestra la estructura de GOP no diádica para un tamaño de GOP igual a

nueve. Como se puede ver en la figura a partir de las tiras I se predicen las dos tiras P

siguientes, y a partir de las tiras I y P se hace la bi-predicción de dos tiras B

intermedias. La estructura es no diádica porque no respeta que se vayan añadiendo

tiras B multiplicando por dos e intercalándolas secuencialmente, tal como sucede en la

figura del caso a).

El caso c) muestra una estructura diádica para el caso de solo usar tiras P. En este caso,

a partir de la tira I inicial se predicen tres tiras P intermedias, y a partir de las tiras P

intermedias se predicen más tiras P posteriores en tiempo de reproducción.

Normalmente, cuando nos encontremos con una estructura de este tipo se va a tratar

de un tamaño de GOP igual a uno en el que cada tira P posterior en tiempo va a

depender de la tira I o P anterior en tiempo.

Figura 2.3: Estructura diádica y no diádica

2.1.2. Escalabilidad espacial:

La escalabilidad espacial, está basada en la capacidad de escalar en tamaño la

resolución del video de menor a mayor tamaño. Así, las capas superiores dependen de

las inferiores. En este caso aparte de las predicciones inter e intra, se añade el caso de

la predicción entre capas.

Se muestra a continuación un ejemplo con dos capas de escalabilidad espacial.


Figura 2.4: Escalabilidad espacial

La predicción entre capas se realiza de tal forma que se utiliza información propia de la

capa y de las capas inferiores. En concreto hay tres tipos de predicción entre capas:

1. Predicción de los vectores de movimiento (Inter-Layer Motion Prediction, M):

Consiste en sacar versiones interpoladas de los vectores de movimiento de la

capa inferior.

2. Predicción a partir del residual (Inter-Layer Residual Prediction, R): Se interpola

el residual de la capa inferior.

3. Predicción de macro-bloques intra-predecidos (Inter-Layer Intra Prediction): Se

interpola la intra-predicción realizada en la capa inferior.

La diferencia principal entre usar M y R, es que cuando se trabaja con la interpolación

de los vectores de movimiento, en la siguiente tira se sigue prediciendo desde la capa

base, mientras que cuando se trabaja con R, en las tiras siguientes se sigue trabajando

con inter-predicción en la capa superior.

2.1.3. Escalabilidad de calidad:

La escalabilidad de calidad se basa en el uso de dos o más capas con la misma

resolución pero con diferente parámetro de cuantificación a la hora de obtener el valor

de los coeficientes transformados.

En H264/SVC se utiliza “Medium-Grain Scalability Coding” (MGS), que permite predecir

desde la propia capa y desde las capas inferiores los valores de los residuales en cada

caso. Se caracteriza por el hecho de permitir partir los coeficientes transformados en

diferentes capas de mejora, asegurándose que se va a poder reconstruir usando los

coeficientes de las capas inferiores en caso de que no se disponga de todos los

coeficientes transformados en la capa superior.

La ventaja principal de usar MGS respecto a sus antecesores, es que nos permite el

intercambio entre capas en cualquier momento. En MPEG4 se utilizaba “Fine-Grain

Scalability Coding”, que a diferencia de la escalabilidad de SNR, predecía todas las


capas de mejora a partir de la capa base. En el otro extremo esta lo que se planteo en

MPEG2, que consistía en predecir todas las capas a partir de la de mejora. El problema

principal que apareció es que no se obtenía unas buenas tasas de codificación

comparado con el caso de transmitir varios flujos codificados con AVC, a diferencia del

caso de MGS que si se consiguió.

En MGS se utilizan fotogramas clave, que sirven para re-sincronizar la capa base con

las capas de mejora. De esta forma, se almacenan los fotogramas clave para no tener

que recodificar los fotogramas clave en las capas de mejora.

En la figura siguiente se muestran las diferentes estrategias de codificación en

escalabilidad de SNR.

Figura 2.5: Estructuras de dependencia de calidad

El caso a) es el correspondiente a FGS, b) es el extremo opuesto propuesto en MPEG2,

c) es un caso intermedio y d) es el caso de MGS.

2.1.4. Escalabilidad híbrida:

El concepto general de escalabilidad en el estándar H264/SVC, se basa en las posibles

combinaciones de los tres tipos de escalabilidad, dando lugar a flujos de datos

conformantes con diferentes combinaciones de los tres tipos de escalabilidad. Así se

podría generar secuencias de video codificadas con varias capas de escalabilidad

temporal y de SNR dentro de cada capa con una resolución diferente.

2.2. Cabecera de las unidades NAL:

En H264 hay tres tipos de unidades NAL:

1. VCL NALU: son propiamente las unidades NAL que contienen la información

codificada de la secuencia de video.

2. Non-VCL NALU: Contienen conjuntos de parámetros de codificación,…


3. Cabeceras NALU del flujo de datos.

En este apartado vamos a analizar las cabeceras de las VCL NALU en H264/SVC.

En H264/AVC las cabeceras de la unidad NAL son de un byte de longitud, en cambio las

SVC contienen cuatro bytes de longitud, teniendo el primer byte el mismo contenido

que en AVC. En SVC se utilizan las unidades NAL de tipo 20, que son las unidades NAL

de tiras codificadas de extensión escalable.

Figura 2.6: Estructura del primer byte de la cabecera de las unidades NAL

F: 1 bit

forbidden_zero_bit: Se define que cuando valga uno indica un error en la

sintaxis.

NRI: 2 bits

nal_ref_idc: Un valor de 00 indica que la unidad NAL no será necesaria para

reconstruir fotogramas de referencia en predicciones futuras. Se puede descartar la

unidad NAL siempre que su valor sea de 00 pudiendo seguir decodificando sin su

existencia. Las tiras B de las que dependen otras tiras B según la estructura diádica

nunca tendrán un valor de 00, mientras que serán las tiras B de las que no depende

ninguna unidad NAL las que tendrán un valor de 00.

TYPE: 5 bits

nal_unit_type: Indica el tipo de unidad NAL en cuestión.

Los valores posibles en H264/AVC son los siguientes:

Figura 2.7: Tipos de unidad NAL H264/AVC

En SVC los valores posibles son los siguientes:


Figura 2.8: Tipos de unidad NAL H264/SVC

Los principales tipos de unidad NAL son las unidades NAL VCL (tipos 1, 2, 3, 4 y 5),

correspondientes en H264/AVC a la codificación parcial o total de una tira en instante

de refresco instantáneo, o sin instante de refresco instantáneo, y las non-VCL (tipos 6,

7 y 8) correspondientes al envió de información sobre la secuencia (SPS), sobre los

fotogramas (PPS), o de información suplementaria para la decodificación (SEI).

En H264/SVC, se añaden las unidades NAL correspondientes a la información

codificada para las capas superiores, llamadas de extensión de tira escalable (tipo 20),

las de información de capa a nivel de secuencia (SSPS, tipo 15) y las Prefix NAL Unit

(tipo 14), para contener información de compatibilidad con H264/AVC.

En H264/SVC además se añaden otros tres bytes que contienen la información de capa

superior para las unidades NAL de tipo 14 y 20.

Figura 2.9: Estructura de los tres últimos bytes de la cabecera de las unidades NAL en

H264/SVC

R: 1 bit

reserved_one_bit: Bit reservado para extensiones futuras.

I: 1 bit

idr_flag: Indica si se trata de una unidad NAL de IDR (vale 1), o no. Las tiras IDR,

tienen la peculiaridad que permiten resetear los errores propagados, ya que se

decodifican por si solas.

PRID: 6 bits

priority_id: Indica la prioridad de la unidad NAL. Cuanto menor es su valor, más

prioridad tiene la unidad NAL. Básicamente, los valores introducidos se ciñen a los

niveles de dependencia, de forma que una unidad NAL de una tira I en la primera capa


de mejora será la más prioritaria de todas y a medida que se suben capas hasta llegar a

la capa superior en las tiras B sin que otras tiras B dependan de la bi-predicción se

asignara los valores más altos.

N: 1 bit

no_inter_layer_pred_flag: Indica que se debe usar predicción entre capas para

decodificar la tira (vale 1) o no.

DID: 3 bits

dependency_id: Identifica el nivel de dependencia espacial de la unidad NAL.

Un valor de cero indica capa base, y a medida que aumenta se va pasando a las capas

superiores. Existen ocho resoluciones posibles.

QID: 4 bits

quality_id: Identifica el nivel de dependencia de calidad de las capas MGS. Para

una capa (Di, Ti, Qi) existe una capa (Di, Ti, (Qi – 1)) a partir de la que se hace

predicción entre capas. Existen diez y seis niveles de escalabilidad de calidad por nivel

de resolución.

TID: 3 bits

temporal_id: Identifica el nivel de dependencia temporal de la capa. Una capa

con un determinado identificador temporal depende siempre de los identificadores

temporales inferiores pero nunca superiores. Existen ocho niveles de dependencia

temporal por cada capa de calidad y/o resolución.

U: 1 bit

use_ref_base_pic_flag: Indica que se utilizan fotogramas base de referencia

para la inter-predicción (vale 1) o no (vale 0).

D: 1 bit

discartable_flag: Cuando vale uno indica que la unidad NAL actual no se utiliza

para decodificar otras unidades NAL con valores superiores de dependency_id, ni en

esta unidad de acceso ni en ninguna otra AU. Estas unidades NAL pueden ser

descartadas sin comprometer la integridad de las capas con identificador de

dependencia superior.

O: 1 bit

output_flag: Cuando vale uno indica que esta unidad NAL se utilizará para el

proceso de decodificación de otras tiras posteriores en tiempo de transmisión.


RR: 2 bits

reserved_three_2_bits: Bits reservados para extensiones futuras. Debe valer

“11”.

2.3. Sintaxis de las unidades NAL:

En el estándar H264 se proponen varios tipos de lectura, en función de cómo están

estructurados los datos de las unidades NAL. En concreto se propone:

u(n): Leer n bits y devolver su valor como natural (unsigned).

u(v): Leer v bits que son función de otros parámetros y devolver su valor como

natural (unsigned).

ue(v): Leer un código Exp-Golomb y devolver su valor como natural (unsigned).

se(v): Leer un código Exp-Golomb y devolver su valor como entero (signed). El

signo positivo va con los números pares.

Los códigos Exp-Golomb son una codificación entrópica caracterizada por palabras de

longitud variable. Estos códigos se generan de la forma siguiente:

[sucesión de zeros][1][información]

número_ceros_sucesión = floor(log2(número_codigo + 1);

información = número_codigo + 1 – exp(2, número_ceros_sucesión);

Tabla 2.1: Lista de ejemplos de codificación Exp-Golomb

Y se decodifican de la forma siguiente:

número_ceros_sucesión = read(ceros);

información = read(número_ceros_sucesión después de uno);


número_codigo = información + exp(2, número_ceros_sucesión) – 1;

En H264 hay tres tipos de unidades NAL tal y como se ha comentado antes, las

unidades NAL VCL, las non-VCL y las cabeceras. Vamos a ver a continuación los

parámetros más importantes de los distintos tipos de unidad NAL.

2.3.1. Unidades NAL non-VCL:

Son las unidades NAL, que nos aportan información a nivel de secuencia o de

fotograma, para la posterior correcta decodificación. Las comunes en AVC y SVC son:

Supplemental Enhancement Information (SEI).

Sequence Parameter Set (SPS).

Picture Parameter Set (PPS).

Además en H264/SVC se añaden las siguientes:

Prefix NAL Unit.

Subset Sequence Parameter Set (SSPS).

2.3.1.1. Supplemental Enhancement Information:

Los SEI aportan información acerca de la secuencia de video y su organización. Hay

alrededor de 40 tipos de mensaje SEI pero nos vamos a centrar en el

“Scalability_Information_SEI”, que solo se utiliza en SVC, y proporciona toda la

información de cómo está estructurada la secuencia de video.

Los elementos sintácticos más importantes que forman parte de este tipo de mensaje

SEI son:

num_layers_minus1: Indica el número de combinaciones diferentes de los

parámetros DTQ que forman la secuencia de video, es decir indica el número de capas

de la codificación.

layer_id: Asigna un identificador a cada capa. El identificador de capa es único,

y es un parámetro intercambiable por los tres siguientes.

dependency_id: Identificador de dependencia espacial de cada capa.

quality_id: Identificador de dependencia de calidad de cada capa.

temporal_id: Identificador de dependencia temporal de cada capa.

frame_height_in_mbs_minus1: Indica la altura en macro-bloques de los

fotogramas.


2.3.1.2. Sequence Parameter Set:

El “Sequence Parameter Set” contiene información acerca de los parámetros de

codificación usados en origen, y se debe transmitir para que el decodificador pueda

realizar la función inversa en recepción. Solo puede haber uno en todo el flujo de datos

y se corresponde con la capa base. Para las demás capas están los “Subset Sequence

Parameter Set” que contiene el SPS.

Los elementos sintácticos más importantes en el SPS son:

seq_parameter_set_id: Un identificador para que los PPS puedan referenciar de

que SPS dependen.

pic_order_cnt_type: Un valor de cero indica que en la cabecera de la tira

tendremos su orden dentro del GOP. Los demás valores están sin definir. Siempre a

cero.

pic_width_in_mbs_minus1: Indica la anchura en macro-bloques del fotograma.

2.3.1.3. Picture Parameter Set:

Los PPS contiene información para decodificar, principalmente sobre la capa de

cuantificación. Puede haber uno para cada capa de las que forman el flujo de datos, y

llevan asociado un SPS para la capa 000, y un SSPS para las demás.

Los elementos sintácticos más importantes en el PPS son:

pic_parameter_set_id: Un identificador del conjunto de parámetros a nivel de

fotograma para poder referenciarlo desde la cabecera de la tira.

seq_parameter_set_id: Identificador del SPS o SSPS del cual depende.

entropy_coding_mode_flag: Nos indica si la codificación de datos de la

secuencia de video se ha realizado con CAVLC (0) o CABAC (1). Ambos tipos de

codificación son codificadores entrópicos con longitud de las palabras variables, y se

aplican a los coeficientes transformados en forma de codificación.

2.3.2. Unidades NAL VCL:

Las unidades NAL VCL son las que contienen la información útil del video. En función

del tipo de unidad NAL se pueden clasificar en “Coded Slice of a non-IDR Picture”,

“Coded Slice of an IDR Picture” y las “Coded Slice Extension” propias de SVC. Por tipo

de tira se pueden clasificar en tiras I (Intra-predecidas), tiras P (inter-Predecidas) y tiras

B (Bipredecidas).

Todas las unidades NAL VCL, constan de la cabecera de la unidad NAL ya analizada en

apartados anteriores y de la cabecera de la tira, que nos dará toda la información para


decodificar, ya que referencia al “Picture Parameter Set” que a su vez referencia al

“Sequence Parameter Set” o “Subset Sequence Parameter Set” correspondiente.

2.3.2.1. Coded Slice of non-IDR Picture:

Las tiras codificadas de una imagen que no son de instante de refresco instantáneo,

son aquellas que forman parte de la capa base, y que además de poder ser tiras I,

como en el caso IDR, pueden ser tiras P o B. Se caracterizan por ser iguales en

H264/AVC que en H264/SVC.

Los elementos sintácticos más importantes de la cabecera de las tiras no IDR son:

first_mb_in_slice: Indica la posición del primer macro-bloque en la tira. En

principio vale cero, pero si la tira fuera demasiado grande para caber en una unidad

NAL, se utiliza para indicar la posición relativa en número de macro-bloques.

slice_type: Indica el tipo de tira. Las tiras I son el número 2, las P el número 0 y

las B el número 1.

pic_parameter_set_id: Indica de que “Picture Parameter Set” depende.

pic_order_cnt_lsb: Nos indica cual sera el orden de decodificación, el cual va a

seguir la estructura del GOP.

direct_spatial_mv_pred_flag: Indica si esta activa (1) o desactiva (0) la

predicción directa entre capas. Un valor de cero indica que se pueden coger las tiras

anterior y posterior para la decodificación temporal.

Los elementos sintácticos más importantes de la parte de datos de las tiras son:

mb_skip_run: Se utiliza en CAVLC, e indica el número de macro-bloques no

codificados o perdidos.

mb_skip_flag: Se utiliza en CABAC, e indica si el macro-bloque presente se

reconstruye con datos de la propia tira o de otras.

2.3.2.2. Coded Slice of an IDR Picture:

Las tiras codificadas de una imagen de refresco instantáneo de decodificación, solo

pueden ser tiras I, y nunca tendrán ningún mb_skip_flag igual a uno, ni ningún

mb_skip_run diferente de cero. Se utilizan como punto de recuperación de errores, ya

que dichas unidades NAL no dependen de ninguna otra.

Los elementos sintácticos de estas unidades NAL son los mismos de las no IDR, con lo

que la cabecera de la tira contiene los mismos campos.

2.3.2.3. Coded Slice Extension:


Son las tiras propias de las capas superiores según H264/SVC. Mantienen mucha

similitud con la sintaxis de H264/AVC (la parte de datos es igual). Sin embargo, se

añaden algunos campos importantes para la caracterización de la escalabilidad.

Los elementos sintácticos más importantes que se añaden respecto a las de AVC son:

store_ref_base_pic_flag: Indica si se debe tener en cuenta la tira

inmediatamente inferior, según niveles de dependencia, en el proceso de predicción

de los vectores de movimiento de los macro-bloques de los datos de tira.

ref_layer_dq_id: Indica el valor de los parámetros DQ de la capa que se utiliza

como referencia. El parámetro DQ se establece según la expresión:

DQ_id = (dependency_id << 4) + quality_id

slice_skip_flag: Un valor de uno indica que no hay datos de tira.

num_mbs_in_slice_minus1: Indica el número de macro-bloques que se van a

predecir directamente.


Capítulo 3:

Filtrado adaptativo:

3.1. Filtrado de unidades NAL:

Hasta este capítulo, se ha introducido la teoría necesaria para la correcta comprensión

de los puntos que se introducirán a continuación. En concreto, se puede considerar

como el capítulo central del proyecto, ya que es aquí donde se introducirá, la forma de

filtrar las unidades NAL, de tal forma que con el resultado obtenido pasado el filtrado

sea posible obtener una secuencia de video decodificable con los paquetes de

software JSVM y OpenSVCDecoder.

En primer lugar, vamos a definir como se entiende la palabra filtrar en este contexto.

Entendemos como filtro de unidades NAL, el filtro que es capaz de extraer sub-flujos

decodificables a partir del flujo general con distintos parámetros máximos de

“dependency_id”, “quality_id” y “temporal_id”. De esta forma se extraerán capas con

atributos menores a los máximos que serán a su vez conformantes con el estándar, y

por lo tanto decodificables y reproducibles.

En segundo lugar, cabe destacar que en el algoritmo desarrollado se ha buscado, la

máxima adaptación a todas las codificaciones posibles, pero en el transcurso del

desarrollo, he decidido acotar algunas limitaciones, contemplando aspectos como el

de implementabilidad de la lógica interna en tiempo real equiparablemente inferior al

tiempo de reproducción.

Razón, por la que se han impuesto las siguientes restricciones en el proceso de

codificación:

El nivel de dependencia entre capas siempre respecto a la inferior.

Máximo 2 capas de escalabilidad de SNR por cada capa.

Para tratar el tema con detalle, se van a tomar en consideración las distintas

implicaciones en el proceso de filtrado, teniendo en cuenta que las reglas expuestas a

continuación, van acotadas a las restricciones anteriores.

De esta forma, el planteamiento elegido es empezar de abajo a arriba añadiendo

nuevas reglas impuestas según el nivel de opciones utilizado.

3.1.1. Reglas de dependencia en el filtrado de unidades NAL:

Se empezará desde una primera versión en la que se verán las reglas impuestas por el

uso de diferentes capas con escalabilidad espacial, conjuntamente con el uso de

escalabilidad temporal. Una vez vistas las reglas de dependencia en el filtrado de


unidades NAL para la reproducción en este caso, se pasara a evaluar las reglas

introducidas por el uso de escalabilidad de SNR, y la introducción de “Medium Grain

Scalability”.

SINTAXIS: Si se desea extraer (Di, Ti, Qi) se debe extraer (Dj, Tj, Qj)

Equivalente a:

(Di, Ti, Qi) (Dj, Tj, Qj)

Si se desea extraer (Di , Ti, Qi) no se debe extraer (Dj, Tj, Qj)

Equivalente a:

(Di, Ti, Qi) -/-> (Dj, Tj, Qj)

3.1.1.1. Reglas con escalabilidad espacial y temporal:

En general, las reglas de dependencia cumplen:

Escalabilidad temporal:

(D, T + 1, 0) (D, T, 0)

Escalabilidad espacial:

(D + 1, T, 0) (D, T, 0)

En particular, se deben añadir las siguientes reglas:

Reglas combinadas:

Si existe (Di, TMAX + 1, 0):

(DMAX, TMAX, QMAX) -/-> (Di, TMAX + 1, 0)

Esta regla básicamente indica que cuando existan más tiras B en alguna capa inferior

que en la capa que se va a extraer (es decir, que se utilice una velocidad de

reproducción mayor en capas inferiores), al extraer la capa superior a velocidad de

reproducción menor que la capa inferior, esas tiras B de las capas inferiores van a ser

filtradas en la extracción de la capa superior porque no habrán sido utilizadas para las

predicciones entre capas, y consecuentemente no serán necesarias para la

decodificación.

3.1.1.2. Reglas con escalabilidad de SNR y uso de MGS:


En general las reglas de dependencia cumplen:

Escalabilidad de SNR y uso de MGS:

(D, T, Q + 1) (D, T, Q)

Con el uso de MGS se añade una nueva regla general, que implica que cuando se

utilizan niveles temporales con escalabilidad de SNR que en la capa superior no

incluyen todos los coeficientes DCT de la codificación, en caso de existir alguna capa

con la misma resolución y nivel temporal inferior, se deben incluir todas las capas MGS

de esos niveles que contengan coeficientes DCT.

Si existe (DMAX , Ti, QMAX + 1) Ti < TMAX

(DMAX, TMAX, QMAX) (DMAX, Ti, QMAX + 1)

Reglas combinadas con escalabilidad espacial y temporal:

Para el correcto funcionamiento del algoritmo que se expondrá en el siguiente

apartado, es importante remarcar que en un video codificado con H.264 SVC, se deben

aplicar todas las reglas que se han ido desglosando en varios apartados, para obtener

un archivo SVC filtrado que sea conformante con el estándar.

3.1.2. Algoritmo de filtrado de unidades NAL:

A través de las reglas expuestas anteriormente, se ha procedido a la obtención del

algoritmo en lenguaje de programación que llevara a cabo el acometido de extraer

según los límites impuestos por dichas reglas.

Se distinguen los dos casos según se trate de un video codificado que utilice MGS, o en

ausencia de su uso.

3.1.2.1. Algoritmo de extracción sin usar MGS:

Para una mejor comprensión del código que se muestra a continuación, vamos a ver

un ejemplo del funcionamiento del algoritmo de filtrado explicado detalladamente.

En este caso, no se contempla el uso de MGS, por lo que el ejemplo elegido, ha sido

pensado para contener los tres tipos de escalabilidad, es decir una codificación con

tres capas, la capa base, una capa de mejora de calidad, y otra con más resolución. Así,

se estaría utilizando escalabilidad de resolución y de SNR. Por esto, se elige un tamaño

de GOP igual a 2 generando así dos capas temporales por capa de resolución y calidad.

En este caso particular, dispondremos de seis capas, que según el valor de sus

identificadores DTQ, serán las capas 000, 001, 100, 010, 011 y 110. La generación del

flujo se hace según la imagen de la figura 3.1.


Figura 3.1: Estructura de la codificación, con capa base, capa de calidad mejorada y

capa de resolución superior

Partiendo de la capa base (000) se generan las capas superiores en niveles de

dependencia de resolución (100), de calidad (001) y temporal (010), y a partir de las

capas superiores se generan las capas temporales superiores en resolución (110) y

calidad (011). Estas últimas capas dependen a su vez de la capa base y de las capas de

mejora.

El algoritmo de filtrado, se encarga de obtener la extracción con un DTQ_th máximo,

encargándose de cumplir todos los niveles de dependencia, es decir, hacer que en

cada extracción se cumplan todas las reglas descritas en el apartado anterior.

Por ejemplo, para conseguir la extracción del flujo con máxima resolución a la máxima

velocidad de reproducción se deben incluir las unidades NAL correspondientes a las

capas 000, 010, 100 y 110, porque para cumplir las reglas, la extracción hasta 110 debe

incluir todas sus dependencias, la capa 100 según dependencia temporal y las capas

000 y 010 porque la capa base de la que se predice entre capas es esta.

Es importante darse cuenta que no depende de las capas de calidad mejorada, ya que

se parte de una codificación, en la que se debe haber utilizado como capa base de la

de resolución mayor, la capa base. En este caso también se podría añadir las capas de

mejora de calidad, pero no se obtendría el mínimo flujo de transmisión.

Para completar el ejemplo, se ve en la tabla siguiente para cada DTQ_th de extracción,

las capas que va a incluir una vez analizado según el algoritmo de extracción que se

mostrará más adelante.

DTQ_th Capas incluidas

000 001 100 010 011 110

000 Sí No No No No No

001 Sí Sí No No No No

100 Sí No Sí No No No

010 Sí No No Sí No No

011 Sí Sí No Sí Sí No

110 Si No Sí Sí No Sí

Tabla 3.1: Resultados algoritmo de extracción para el ejemplo 1


A continuación, vemos el código correspondiente al algoritmo de filtrado para el caso

sin uso de MGS, el cual se encarga de realizar el proceso descrito en el ejemplo, y en el

que los atributos “dependency_id”, “quality_id” y “temporal_id” se corresponden con

los atributos de cada unidad NAL analizada.

//PARAMETROS LIMITE EN LA EXTRACCIÓN int dependency_id_th, quality_id_th, temporal_id_th; int extract = 0; //1: NALU se debe extraer //0: No se debe extraer //Parametros auxiliares para manejar los limites en las distintas capas int quality_id_tmp; … extract = 0; quality_id_tmp = quality_id_th; for(int i=dependency_id_th; i>-1; i--){ for(int j=temporal_id_th; j>-1; j--){ for(int k=quality_id_tmp; k>-1; k--){ if(dependency_id == i && temporal_id == j && quality_id == k){ extract = 1; break; } } if(extract == 1) break; } if(extract ==1) break; quality_id_tmp = 0; } if(extract == 1){ //ALMACENAR o TRANSMITIR }

3.1.2.2. Algoritmo de extracción usando MGS:

De la misma forma, que en el caso sin MGS, vamos a ver un ejemplo, que permita la

correcta comprensión del código que se añade al algoritmo de extracción para el caso

en que se va a usar MGS.

La codificación de video elegida es la misma que en el ejemplo anterior, pero usando

MGS en la capa de calidad mejorada. En concreto, se van a generar dos capas de

calidad mejorada, que contendrán cuatro de los ocho coeficientes transformados cada


una. De esta forma, se generan las ocho capas 000, 001, 002, 100, 010, 011, 012 y 110,

tal y como se ve en la figura 3.2.

Figura 3.2: Estructura de la codificación, con capa base, capa de calidad mejorada con

uso de MGS y capa de resolución superior

Aunque, en la imagen se muestra, la capa añadida (Q=2) como si fuera predicha a

partir de la capa de mejora (Q=1), en realidad se trata de una codificación con MGS,

por lo que se trata de la misma capa pero en este caso se parten los coeficientes

transformados en dos capas. En la práctica, se van a dividir las unidades NAL de la

misma forma que si se estuvieran utilizando varias capas de mejora.

La principal diferencia, con el algoritmo de extracción sin el uso de MGS, es que se va a

cumplir la última regla general expuesta, que consiste en incluir las capas con

identificador de calidad mayor, nivel temporal inferior y misma resolución que el de la

extracción, en los casos en que se va extraer con identificador de calidad menor e

identificador temporal más grande.

Este es el caso, que sucede cuando se quiere extraer hasta la capa 011, en que según el

algoritmo de filtrado sin MGS, cumpliendo todas las dependencias se iban a extraer las

capas 000, 001, 010 y 011. Lo que sucede, es que al usar MGS, los coeficientes

transformados quedan divididos en las capas con Q igual a uno y dos, razón por la que

si se quiere extraer hasta 011 se debe incluir la capa 002 para que se incluyan todos los

coeficientes transformados de la capa DT igual a 00.

Es importante tener en cuenta, que en el caso de haber utilizado dos capas de calidad

mejorada el algoritmo de extracción funciona correctamente sin el uso de MGS. Por

esto, ya se ha expuesto al inicio del capítulo que se limita a dos capas con diferentes

calidades por capa de resolución, y posibilidad de usar MGS en la capa de mejora.

Para completar el ejemplo, se ve en la tabla siguiente para cada DTQ_th de extracción,

las capas que va a incluir una vez analizado según el algoritmo de extracción que se

mostrará más adelante.

DTQ_th Capas incluidas

000 001 002 100 010 011 012 110


000 Sí No No No No No No No

001 Sí Sí No No No No No No

002 Sí Sí Sí No No No No No

100 Sí No No Sí No No No No

010 Sí No No No Sí No No No

011 Sí Sí Sí No Sí Sí No No

012 Sí Sí Sí No Sí Sí Sí No

110 Si No No Sí Sí No No Sí

Tabla 3.2: Resultados algoritmo de extracción para el ejemplo 2

A continuación, se muestra el código correspondiente al algoritmo de filtrado para el

caso con uso de MGS. Los atributos “dependency_id”, “quality_id” y “temporal_id” se

corresponden con los atributos de cada unidad NAL analizada.

A continuación, vemos el código correspondiente al algoritmo de filtrado para el caso

sin uso de MGS, el cual se encarga de realizar el proceso descrito en el ejemplo, y en el

que los atributos “dependency_id”, “quality_id” y “temporal_id” se corresponden con

los atributos de cada unidad NAL analizada.

//PARAMETROS LIMITE EN LA EXTRACCIÓN int dependency_id_th, quality_id_th, temporal_id_th; int extract = 0; //1: NALU se debe extraer //0: No se debe extraer //Parametros auxiliares para manejar los limites en las distintas capas int quality_id_tmp; //Parametros que contendran las capas a las que se les da acceso int D_array[NUM_LAYER], T_array[NUM_LAYER], Q_array[NUM_LAYER]; int pos_array = 0; … extract = 0; quality_id_tmp = quality_id_th; for(int i=dependency_id_th; i>-1; i--){ for(int j=temporal_id_th; j>-1; j--){ for(int k=quality_id_tmp; k>-1; k--){ if(dependency_id == i && temporal_id == j && quality_id == k){ extract = 1; break; } } if(extract == 1) break; } if(extract ==1) break;


quality_id_tmp = 0; } //Comprobar que en caso de (D,T,Q) almacenado con ((D < dependency_id_th || T < temporal_id_th)&&Q>=1) // Se incluyan también (D,T,Qi) con Qi>Q int i = 0; if(quality_id > 0 && extract == 0){ while(!(D_array[i] == -1 && T_array[i] == -1 && Q_array[i] == -1) == true){ if((D_array[i] < dependency_id_th || (T_array[i] < temporal_id_th)) && Q_array[i] > 0){ if(dependency_id == D_array[i] && temporal_id == T_array[i] && quality_id > Q_array[i]){ extract = 1; } } i++; } } //Comprobar si existe (D, T, Q) introducido en los arrays i = 0; int DTQ_exists_in_array = 0; while(!(D_array[i] == -1 && T_array[i] == -1 && Q_array[i] == -1)){ if(dependency_id == D_array[i] && quality_id == Q_array[i] && temporal_id == T_array[i]){ DTQ_exists_in_array = 1; break; } i++; } //Almacenar capas a las que se les da acceso y que no han sido introducidas antes (DTQ_exists_in_array == 0) if(extract == 1 && DTQ_exists_in_array == 0){ D_array[pos_array] = dependency_id; Q_array[pos_array] = quality_id; T_array[pos_array] = temporal_id; pos_array++; } if(extract == 1){ //ALMACENAR o TRANSMITIR }

3.2. Filtrado adaptativo:


Se define el filtrado adaptativo, como la capacidad de extracción de distintas capas

máximas a través del tiempo, de forma que durante un intervalo de tiempo se extraerá

a un DTQ_th y durante otro intervalo de tiempo a otro DTQ_th distinto del primero y

así, sucesivamente.

Las reglas del filtrado adaptativo, vendrán limitadas por las líneas de dependencia

entre unidades NAL propias del estándar H264. De esta manera empezaremos por ver

como se conforman los flujos de transmisión en el estándar H264/AVC, para seguir con

la conformación del estándar H264/SVC, para a posteriori poder obtener los posibles

puntos de corte en que se pueda realizar un intercambio de capa.

3.2.1. Orden de transmisión de flujo de datos H264/AVC:

Hay tres casos a contemplar, el flujo inicial en que se transmite una I seguida de una P,

porque I y P, siempre van transmitidas antes que las B que se reproducen antes de la I

o P en cuestión, contemplado como flujo en inicio; flujo normal y flujo cuando se

encuentra una unidad NAL de refresco instantáneo de decodificación (IDR).

Vamos a ver unos cuantos ejemplos con valores variables de tamaño de GOP.

Flujo de inicio:

GOP size = 2:

Figura 3.3: Flujo de inicio con tamaño de GOP igual a 2

GOP_size = 4:


GOP size = 8:



Flujo normal:

GOP size = 2:

Figura 3.6: Flujo normal con tamaño de GOP igual a 2

GOP_size = 4:


GOP size = 8:



Como se puede ver, el orden de dependencia es tal que se van añadiendo tiras B, hasta

llegar al máximo identificador de dependencia, y a partir de ahí se van repartiendo de

dos en dos formando la estructura que se puede ver en las imágenes. La diferencia

entre el flujo de origen y el normal es tal que en el origen se transmiten primero las

tiras I y P para que las B que se transmiten a posteriori sean anteriores en orden de

reproducción.

En el caso de intercambio por tira I de refresco de decodificación se deben contemplar

dos casos. En primer lugar, el caso en que el periodo de IDR es múltiple del periodo de

tiras intra-predecidas, caso en el que cuando se pone la tira IDR le toca a una tira I. Y el

segundo es el caso contrario, caso en el que debido a que el periodo IDR debe ser

múltiple del tamaño de GOP, le corresponderá la posición de una P.

Flujo en IDR:

IDR_period = M * Intra_period (M entero):

GOP size = 2:

Figura 3.9: Flujo en IDR múltiple periodo intra-predicción con

tamaño de GOP igual a 2

GOP size = 4:



GOP size = 8:




IDR_period != M * Intra_period (M entero):

GOP size = 2:

Figura 3.12: Flujo en IDR no múltiple periodo intra-predicción con


GOP size = 4:



GOP size = 8:




El detalle más importante en que hay que fijarse es el hecho que cuando aparece una

tira I de refresco instantáneo de decodificación, las tiras B siguientes no tienen dos

tiras para ser inter-predichas y consecuentemente se transforman en tiras P en las que

el segundo subíndice indica la posición relativa.

Para el filtrado adaptativo en H264/AVC tendremos combinaciones con diferentes

identificadores de dependencia temporal, como por ejemplo 010 y 020. Al tener

siempre dependencia hacía atrás en tiempo de reproducción respecto al tiempo de

transmisión será posible cortar por cualquier sitio obteniendo como resultado flujos

conformantes con el estándar, independientemente de si los intercambios son de

identificador temporal mayor a menor, o menor a mayor.

3.2.2. Orden de transmisión de flujo de datos H264/SVC:

Para el caso del estándar H264/SVC se elige una codificación que contiene los tres

tipos de escalabilidad a modo de ejemplo para detectar las características que deben

cumplir los puntos de corte para obtener flujos de datos conformantes con el

estándar.

En concreto, se elige una codificación de tres capas, capa base, capa de calidad de SNR

mejorada y capa con resolución superior a las dos capas anteriores, con un tamaño de

GOP en cada capa de dos. Se va a ver para esta codificación el orden de transmisión

del flujo de datos para cada uno de los cuatro casos. Los subíndices indican la capa

correspondiente a la que pertenecen las unidades NAL, siendo cero la capa base, 1 la

capa de escalabilidad de SNR y 2 la capa de escalabilidad de resolución.

Se muestra a continuación, los flujos generados.

Flujo de inicio:

Figura 3.15: Flujo inicio codificación con tres capas, capa base,

capa calidad mejorada y capa de resolución superior


Flujo normal:

Figura 3.16: Flujo normal codificación con tres capas, capa base,

capa calidad mejorada y capa de resolución superior

Flujo en IDR:


Figura 3.17: Flujo en IDR múltiple periodo intra-predicción codificación con

tres capas, capa base, capa calidad mejorada y capa de resolución superior



Figura 3.18: Flujo en IDR no múltiple periodo intra-predicción codificación con

tres capas, capa base, capa calidad mejorada y capa de resolución superior

De forma general, igual que en el caso analizado, el orden de transmisión cuando se

transmite más de una capa, sigue el orden temporal de H264/AVC, fijando el orden

entre capas correspondiente a la codificación. En este caso, se transmiten primero las

unidades NAL de la capa base, seguidas por las de escalabilidad de SNR, y finalmente

las de escalabilidad de resolución.

3.2.3. Parámetros de diseño del filtrado adaptativo:

Vamos a analizar a continuación la posibilidad de transmitir flujos filtrados

adaptativamente que puedan contener cualquier combinación entre las seis capas

generadas (000, 001, 100, 010, 011 y 110).

En primer lugar es importante darse cuenta que en los flujos resultantes se deberá

cumplir todas las restricciones de dependencia propias del estándar. Así, si se fuera a

cortar por tiras P o tiras B, ya se ve enseguida que dependerían de las tiras I anteriores,

por lo que podría dar lugar a flujos de datos no conformantes.

De esta forma, se ve la necesidad de que los puntos de corte se localicen en las tiras I

de la capa base. Entonces, teniendo en cuenta que las tiras B que siguen al punto de

corte son dependientes de las dos tiras I y/o P anteriores se llega a dos posibilidades

en el filtrado realizado en el flujo normal:

1. Cambiar de DTQ_th en la tira I con DTQ igual a 000, y filtrar las tiras B

siguientes, de forma que se consigue un flujo de datos decodificable porque las

siguientes tiras B que aparecen ya disponen de dos tiras I y/o P para poder ser

decodificadas correctamente.

2. La segunda opción, es no filtrar las tiras B que se transmiten después del punto

de corte. En este caso, estas tiras B dependerán del DTQ_th inicial porque para


poder ser decodificadas, deberá ser filtrado en el DTQ_th que se dispongan las

dos tiras I y/o P anteriores, y como antes del filtrado la tira I y/o P anterior será

extraída en el primer DTQ, las tiras B que siguen al punto de corte se van a

filtrar con el DTQ_th que había antes del corte. De forma similar las siguientes

tiras B que aparezcan dependerán de las dos tiras I y/o P anteriores, razón por

la cual dependerán de las tiras I siguientes al punto de corte incluidas en la

extracción. Se ve así la necesidad de extraer las tiras I siguientes al corte para

que se incluya las necesarias para decodificar las dos tiras B siguientes. Es decir,

debe incluir las tiras I según los dos DTQ_th, el anterior y el posterior al punto

de corte. Así, el funcionamiento es el siguiente, intercambio a DTQ_th2 cuando

se detecte tira I con DTQ igual a 000, cambio a DTQ_th cuando se detecte

dependencia temporal más grande que uno y intercambio a DTQ_th2 cuando

se vuelva a detectar tira con nivel de dependencia temporal igual a 0.

En el caso de intercambio de capa por un punto de corte IDR, que también cumple que

la tira del intercambio es una I con DTQ igual a 000, al ser las tiras siguientes

dependientes solamente de la unidad NAL IDR, van a poder realizar el intercambio sin

tener que filtrar ni tener en cuenta consideraciones adicionales.

Se muestra el ejemplo de un intercambio entre 110 y 011 para cada uno de los casos.

Flujo normal:

Figura 3.19: Intercambio entre capas 110 y 011 en flujo normal. Caso 1

Figura 3.20: Intercambio entre capas 110 y 011 en flujo normal. Caso 2

Flujo en intercambio IDR:


Figura 3.21: Intercambio entre capas 110 y 011 en flujo IDR múltiple


periodo intra-predicción


Figura 3.22: Intercambio entre capas 110 y 011 en flujo IDR no múltiple

periodo intra-predicción


Capítulo 4:

Estimación del ancho de banda de transmisión:

Una vez visto el algoritmo de filtrado de unidades NAL, el siguiente paso para

desarrollar el sistema de transmisión de video adaptativo sobre TCP, es plantearse cuál

será él, o los parámetros que nos permitirán transmitir adaptativamente a la conexión

un determinado número de capas durante un cierto tiempo y otro determinado

número de capas durante otro cierto tiempo, y así sucesivamente.

De esta forma, es en el protocolo TCP, donde vamos a buscar los parámetros

característicos de la conexión, razón por la cual en primer lugar se verá una breve

descripción de los parámetros de funcionamiento del protocolo de transporte TCP.

4.1. Protocolo de control de Transporte:

TCP es un protocolo de transporte orientado a conexión, fiable y con control de

errores extremo a extremo. Es orientado a conexión porque antes de iniciar la

conexión se pasa por la fase de establecimiento y al finalizar la conexión se pasa por la

fase de cierre de conexión. Es fiable porque se encarga de comprobar y asegurar que

los paquetes se reciban y que sea en orden correcto, mediante el uso de control de

errores, basados en el uso de paquetes de reconocimiento de recepción por parte del

extremo receptor.

En primer lugar, cuando aparece una conexión usando TCP, se pasa por la fase de

establecimiento, que es un proceso de tres pasos, el extremo que inicia la apertura

activa envía un paquete SYN, al extremo que debe estar escuchando en un puerto de

recepción, para que cuando reciba un paquete SYN, responda con un SYN-ACK, que le

indica al extremo inicial que se va a establecer conexión, y este finalmente envía un

paquete de reconocimiento de recepción del paquete de establecimiento de conexión,

momento en que la conexión queda establecida, y ya se puede iniciar la transmisión de

paquetes de datos. La fase de cierre funciona exactamente igual, pero en este caso los

paquetes enviados son FIN, FIN-ACK y ACK. Vemos a continuación una imagen que

muestra ambas fases de conexión.


Figura 4.1: Fases de establecimiento y finalización de conexión

Una conexión TCP queda caracterizada por dos direcciones IP y dos puertos, los

correspondientes al origen y al destino de la conexión. De esta forma se llama

establecimiento activo a la parte que fija la dirección y el puerto de destino y transmite

desde dirección y puerto origen, y establecimiento pasivo al extremo que fija su

dirección y puerto de destino y pone un socket en escucha a la espera de que se

establezcan conexiones.

En una conexión TCP, se define el control de errores como la capacidad de detectar

cuando se produce un error en las transmisiones. De esta forma, se utilizan paquetes

ACK, de reconocimiento que se encargan de asegurar cuando se reciben en el extremo

transmisor que los paquetes enviados hasta el reconocido han sido recibidos

correctamente.

Así, existen tres posibilidades cuando se envía un paquete, primero que se reciba y se

reconozca correctamente, segundo que el paquete se pierda y tercero que haya un

reenvió del paquete debido a la pérdida del reconocimiento. Es por esta razón, que se

define el tiempo de retransmisión (RTO) antes de que se reenvíe el paquete. El valor

de este tiempo viene determinado por medidas del tiempo de transporte extremo a

extremo (“Round Trip Time”), y se utiliza con un algoritmo de backoff exponencial que

va multiplicando por 2 (RTO(n) = 2 * RTO(n – 1)), a medida que se van perdiendo

paquetes porque se asume que cuando se pierden es un indicativo de una situación de

congestión. Las tres situaciones citadas son las siguientes.


Figura 4.2: Casos de transmisión: Paquete enviado y reconocido,

retransmisión y paquete duplicado

Además, TCP dispone de control de flujo, en que mediante el mecanismo de ventana

deslizante se controla que el flujo en red sin haber sido procesado por parte del

extremo receptor no exceda el límite fijado por el tamaño de la ventana deslizante. El

funcionamiento es tal que cada vez que se transmite un determinado paquete de

tamaño N bytes, se reduce el tamaño de la ventana en dicho tamaño, llegando como

mínimo al tamaño de ventana igual a 0 bytes, caso en que se detendrá la transmisión a

la espera de que el nodo receptor envíe otro paquete indicando que el tamaño de la

ventana ha aumentado. Se muestra a continuación una imagen que contiene un

ejemplo de funcionamiento del control de flujo.


Figura 4.3: Ejemplo de control de flujo

4.1.1. Cabecera TCP:

La cabecera del protocolo de control de transporte es la siguiente:

Figura 4.4: Cabecera TCP

Los campos por los que está formado son los siguientes:

Puerto de origen.

Puerto de destino.


Número de secuencia: Número del paquete transmitido. Sigue orden

secuencial.

Número de ACK: Número de secuencia de reconocimiento hasta el que se

reconoce paquetes anteriores recibidos correctamente.

Tamaño de la cabecera: Se expresa en palabras de 4 bytes.

Code bits: Bits para enviar mensajes especiales.

o FIN: Finalizar conexión

o SYN: Establecer conexión.

o RTS: Resetear la conexión.

o PSH: Petición de envió de datos.

o ACK: Reconocimiento de paquetes.

o URG: Campo de puntero urgente valido.

Tamaño de la ventana deslizante.

Checksum: Función resumen obtenida a partir de las direcciones IP y otros

atributos.

Opciones: MSS, Window Scale y Timestamp.

A parte de los campos descritos en TCP también es posible añadir opciones en la

cabecera, se puede modificar el tamaño de segmento mediante la opción MSS, o el

escalado de ventana, y ponerle etiquetas temporales a los paquetes marcando los

tiempos de envío y recepción para poder por ejemplo obtener una estimación de RTO.

4.1.2. Control de congestión:

El control de congestión en TCP es el que se encarga de controlar las situaciones con

alto tráfico en red que conlleven reenvíos de paquetes. Consta de tres mecanismos,

inicio lento, evitar congestión y ser conservativo después de eventos de retransmisión.

Al iniciar la transmisión se empieza con “slow start”, se fija la ventana de congestión a

que solo se pueda transmitir un segmento, y cada vez que se recibe un ACK, se

multiplica por dos de forma exponencial el número de segmentos que se pueden

transmitir. Una vez se detecta que ha habido alguna perdida, se pasa a trabajar con

uno de los otros dos métodos.


Figura 4.5: Fase “slow start”

Si se detectan tres ACK duplicados, se pasa a trabajar con el mecanismo “Congestion

Avoidance”, que se basa en incremento aditivo, y decremento multiplicativo, de forma

que cuando se detectan los tres ACK duplicados se reduce la ventana de congestión a

la mitad y a partir de ese momento, con la situación de congestión detectada se pasa a

aumentar el tamaño de uno en uno. Se puede ver a continuación un ejemplo de este

mecanismo.

Figura 4.6: Ejemplo control de congestión

Por último, en el caso de que se detecte una retransmisión, se reduce el tamaño a uno

y se empieza otra vez los aumentos de forma exponencial hasta un límite fijado

normalmente en la mitad de tamaño que tenía antes de detectar la situación de

congestión.


4.2. Estimación del ancho de banda de transmisión:

Una vez vistas las principales características del protocolo de transporte TCP, vamos a

pasar a evaluar con que parámetros será posible controlar a nivel de aplicación que la

transmisión sea adaptativa al protocolo TCP. Básicamente, los parámetros principales

son el ancho de banda disponible, y el tiempo de transmisión extremo a extremo.

Es importante darse cuenta que se pueden definir varias estrategias a nivel de capa de

aplicación, como por ejemplo añadir comunicación entre los extremos transmisor y

receptor, para mediante la definición de un protocolo a nivel de aplicación conseguir

evitar transmisiones en ciertas circunstancias.

En este proyecto, a diferencia del concepto anterior se ha optado por evitar definir un

protocolo a nivel de aplicación y en su lugar, se ha elegido que mediante las medidas

estimadas por parte del sistema operativo se consiga saber aproximadamente cuál es

el ancho de banda disponible, y acotar la transmisión de forma adaptativa a las

condiciones de red existentes. A nivel de socket el ancho de banda disponible podrá

ser estimado por la siguiente expresión:

BW(bits/s) = cwnd(bits) / RTT(s)

Es por esta razón que el siguiente paso lógico de la operación es tratar de obtener en

tiempo real la estimación del ancho de banda a transmitir por parte de cada una de las

posibles combinaciones de parámetros de escalabilidad del video codificado.

4.2.1. Tamaño de las capas de extracción en tiempo real:

El primer paso para poder obtener una estimación en tiempo real que nos permita

comparar el ancho de banda disponible con el ancho de banda necesario para

transmitir hasta una capa determinada, es obtener en tiempo real el tamaño de cada

unidad NAL con una determinada combinación de DTQ, para así mediante el

conocimiento de la velocidad de transmisión del video poder estimar para cada capa el

ancho de banda necesario para su transmisión.

Con un fotograma:

BW(bits/s) = L(bits/frame)*Fps(frame/s)

Con N fotogramas:

BW(bits/s) = L(bits en N frames)*Fps(frames/s)/N(frames)


El primer punto importante, es darse cuenta, que no basta con obtener el tamaño de

una determinada unidad NAL de la DTQ, sino que en su lugar el tamaño que se tiene

que obtener en tiempo real, es el agregado, de todas las capas incluidas que habría en

la extracción de un determinado DTQ. De esta forma, se ve la necesidad de disponer

una vez analizada cada una de las unidades NAL de una estimación del ancho de banda

a transmitir para cada una de las posibles combinaciones DTQ del video codificado.

En segundo lugar, es importante ver que será necesario aplicar el algoritmo de

extracción de unidades NAL cada vez que se analice una de dichas unidades para poder

obtener la estimación de todas y cada una de las capas.

Así, el algoritmo con el que se obtendrá el tamaño de las unidades NAL en tiempo real,

básicamente lo que realizara será un incremento del tamaño de cada una de las capas

en las que la unidad NAL deba ser incluida.

4.2.2. Velocidad de reproducción del video:

El siguiente parámetro para la estimación del ancho de banda necesario para la

transmisión, es la velocidad de reproducción del video.

La obtención de dicho parámetro es totalmente dependiente del identificador de

escalabilidad temporal, parámetro ya propio de H.264 en su versión AVC. A pesar de

tener una dependencia directa con este parámetro, es importante remarcar que el

parseado entre “dependency_id” y la velocidad de reproducción necesaria para la

estimación del ancho de banda, será dependiente del tipo de video.

En general se cumple que si se aumenta el parámetro de escalabilidad temporal se

multiplica por dos la velocidad de reproducción, pero la velocidad mínima de

reproducción es dependiente de la codificación empleada, concretamente se

determina a partir de los parámetros “Frame Rate” y “GOP_size”. Por ejemplo para un

“GOP_size” de 4 con orden de reproducción IbBbPbBbI… y un “Frame Rate” máximo

de 50 frames/s, la velocidad de transmisión con “temporal_id” de 0 es de 12,5

frames/s.

4.2.3. Implementación de la estimación en tiempo real del ancho de banda de

transmisión:

El objetivo de la implementación es conseguir que en tiempo real se vayan obteniendo

los tamaños agregados, y a partir de su velocidad de reproducción y del número de

unidades NAL incluidas con el DTQ máximo de la capa se deduzca el ancho de banda

de transmisión durante los distintos tramos del video codificado.


El punto más importante a tener en cuenta es la necesidad de aplicar el algoritmo de

extracción cada vez que se analiza una unidad NAL, debido a la necesidad de

incrementar el tamaño de cada una de las combinaciones que incluyen el DTQ de la

capa analizada.

De esta forma, se valoró el desarrollo del mismo algoritmo de extracción en orden

inverso, porque se adecuaría mucho mejor al hecho de comprobar de abajo arriba en

niveles de dependencia, el hecho de si se debe añadir o no el tamaño de una unidad

NAL a una capa de extracción. Sin embargo, no se logró llegar a un algoritmo cerrado

que se adaptara al máximo número de unidades NAL.

A causa, de no encontrar dicho algoritmo cerrado que evaluara en orden inverso, se

pasó a contemplar otra opción igual de valida. Básicamente, se trata que una vez

analizada una iteración en las que se presentaran todas las combinaciones de DTQ

existentes en la secuencia de video (entre una tira I con DTQ igual a 000 a otra con las

mismas características), se aplicara el algoritmo con todas las posibles combinaciones y

se almacenaran los datos dentro de un objeto de tipo “extraction_layer” que

básicamente contendrá la información de la capa que contiene, especificada como

DTQ máximo de la extracción, y un conjunto de vectores conteniendo los DTQ que

incluye la extracción.

El “struct” correspondiente a los objetos de tipo “extraction_layer” es el siguiente:

#define NUM_LAYER N struct extraction_layer { int dependency_id_th; //DTQ de la capa que contiene el STRUCT. int quality_id_th; int temporal_id_th; int limitD[NUM_LAYER]; //Conjunto de DTQ incluidos en la extracción de la capa que contiene el STRUCT. int limitQ[NUM_LAYER]; int limitT[NUM_LAYER]; int real_time_size; //Tamaño de la capa superior aislada obtenido en la última iteración. int size_aggregated; //Tamaño agregado de todas las capas en la última iteración. int total_size; //Tamaño total. int num_NALU_included; //Número de unidades NAL con DTQ_max incluidas en size_aggregated. int total_num_NALU; //Número total de unidades NAL incluidas.


float bandwidth; //Ancho de banda estimado };

Como, se puede observar, además de contener las capas tal como se ha descrito

anteriormente, el mismo objeto almacenará los tamaños, y el número de unidades

NAL con el DTQ máximo de la capa en tiempo real. Además, mediante la fórmula

expuesta anteriormente, se va a computar en tiempo real el ancho de banda asociado

a las medidas realizadas.

Siguiendo, con la explicación de cómo se aplicará el algoritmo, una vez almacenadas

todas las combinaciones de extracción en las demás iteraciones, solo será necesario

evaluar que este contenida en alguna de las capas almacenadas.

4.2.3.1. Detalles de la implementación:

A continuación se muestra parte del código para llevar a cabo las iteraciones

anteriores.

En primer lugar, se especifica el código necesario para conseguir que una vez

almacenadas todas las capas superiores en el vector de objetos “extraction_layer”, se

analice en todos los casos que capas debe incluir, y se incluyan en las capas correctas

(código que sólo será necesario incluir en la primera iteración).

Este código, básicamente aplica el algoritmo de filtrado para obtener como resultado

en los vectores “limitT”, “limitQ” y “limitD” de cada objeto “extraction_layer”, todas

las capas incluidas según el algoritmo de filtrado. Para conseguirlo, se fija un DTQ_th

máximo, y se analizan todos los DTQ_th que se hayan detectado en la evaluación entre

la primera y segunda tira I con DTQ igual a 000, comprobando para cada caso si se

debe incluir la capa en el objeto “extraction_layer”. La decisión se toma aplicando el

algoritmo de filtrado, y en los casos que la extracción sea positiva, se contabiliza el

tamaño en la capa y se añade la capa a evaluar en los vectores “limitT”, “limitQ” y

“limitD”.

De esta forma, se consigue que mediante la evaluación de todas las capas para cada

uno de los DTQ_th, lo cual se traduce en el uso de dos bucles que recorrerán todas las

capas, una vez finalizada la iteración se consigue que cada objeto “extraction_layer”

tenga las capas incluidas según el algoritmo de extracción en sus vectores “limitT”,

“limitQ” y “limitD”.

for(int l=0; l<num_layer; l++){ pos_escritura = 0;


for(int m=0; m<num_layer; m++){ extract = 0; quality_id_tmp = extract_layer[l].quality_id_th; for(int i=extract_layer[l].dependency_id_th; i>-1; i--){ for(int j=extract_layer[l].temporal_id_th; j>-1; j--){ for(int k=quality_id_tmp; k>-1; k--){ if(extract_layer[m].dependency_id_th == i && extract_layer[m].temporal_id_th == j && extract_layer[m].quality_id_th == k){ extract = 1; break; } } if(extract == 1) break; } if(extract ==1) break; quality_id_tmp = 0; } //Comprobar que en caso de (D,T,Q) almacenado con ((D < dependency_id_th || T < dependency_id_th)&&Q>=1) // Se incluyan también (D,T,Qi) con Qi>Q int o = 0; if(extract_layer[m].quality_id_th > 0 && extract == 0){ while(!(extract_layer[l].limitD[o] == -1 && extract_layer[l].limitT[o] == -1 && extract_layer[l].limitQ[o] == -1) == true){ if((extract_layer[l].limitD[o] < extract_layer[l].dependency_id_th || (extract_layer[l].limitT[o] < extract_layer[l].temporal_id_th)) && extract_layer[l].limitQ[o] > 0){ if(extract_layer[m].dependency_id_th == extract_layer[l].limitD[o] && extract_layer[m].temporal_id_th == extract_layer[l].limitT[o] && extract_layer[m].quality_id_th > extract_layer[l].limitQ[o]){ extract = 1; break; } } o++; } } //Introducir el tamaño de las NAL Units que se deben extraer en el tamaño agregado. if(extract == 1){ if(l!=m){ extract_layer[l].size_aggregated += extract_layer[m].real_time_size; } //Introducir los DTQ que se van a extraer en "extract_layer[l]"


//Obtener posición en la que se debe escribir extract_layer[l].limitD[pos_escritura] = extract_layer[m].dependency_id_th; extract_layer[l].limitT[pos_escritura] = extract_layer[m].temporal_id_th; extract_layer[l].limitQ[pos_escritura] = extract_layer[m].quality_id_th; pos_escritura++; } } }

Por otra parte, una vez ya están almacenadas las capas extraídas, el algoritmo para

incluir el tamaño en todas las capas donde se introduce, así como el número de

unidades NAL que se han incluido en el “struct” de cada capa, es el que se muestra a

continuación.

Este código básicamente comprueba para cada unidad NAL si pertenece a alguno de

los DTQ incluidos en la extracción de cada DTQ_th, es decir recorre dos bucles, uno con

todos los DTQ_th (objetos “extraction_layer”) y el otro con todas las capas incluidas en

la extracción. De esta forma, si la unidad NAL analizada pertenece a la extracción, se

incrementan los tamaños agregados de la capa, ya que cada capa debe contener en

tiempo real el tamaño de todas las capas incluidas en la extracción.

A parte, se deben contabilizar el número de fotogramas incluidos en la extracción, en

este caso sólo se va a contabilizar las unidades NAL que tengan los mismos atributos

que la capa analizada. Se consigue como resultado que se vayan actualizando en

tiempo real los tamaños agregados de cada capa, así como el número de fotogramas

incluidos, parámetros necesarios para la correcta estimación.

for(int i=0; i<num_layer; i++){ //Para todas las capas. for(int j=0; j<num_layer; j++){ //Para todas las capas que están incluidas en la extracción. if(dependency_id == extract_layer[i].limitD[j] && temporal_id == extract_layer[i].limitT[j] && quality_id == extract_layer[i].limitQ[j]){ //Incrementar número de unidades NAL almacenadas y tamaños almacenados if(pos_final != -1){ extract_layer[i].real_time_size = (pos_final - pos); extract_layer[i].size_aggregated += (pos_final - pos); extract_layer[i].total_size += (pos_final - pos); } else{ extract_layer[i].real_time_size = (size - pos + 3); extract_layer[i].size_aggregated += (size - pos + 3);


extract_layer[i].total_size += (size - pos + 3); } break; } } if(dependency_id == extract_layer[i].dependency_id_th && temporal_id == extract_layer[i].temporal_id_th && quality_id == extract_layer[i].quality_id_th){ if(NALU_type == 1 || NALU_type == 5 || NALU_type == 20){ if(dependency_id != last_dependency_id || temporal_id != last_temporal_id || quality_id != last_quality_id){ extract_layer[i].num_NALU_included++; extract_layer[i].total_num_NALU++; } } } }

Es importante fijarse en dos puntualizaciones de la implementación. La primera de

ellas es que a veces existen tiras codificadas que ocupan más de una unidad NAL, razón

por la cual es necesario mantener en memoria el DTQ de la unidad NAL anterior

(variables “last_dependency_id”, “last_temporal_id” y “last_quality_id”). De esta

forma se comprueba que sólo se añada una unidad NAL en el cómputo del ancho de

banda estimado cuando estas son consecutivas.

En segundo lugar, en el mismo caso, el ancho de banda estimado sólo debe ser

calculado al sumarse la última unidad NAL del mismo tipo cuando aparece una tira

codificada que contiene varias unidades NAL. Para lograrlo, se pasa a obtener el ancho

de banda estimado una vez analizada la unidad NAL siguiente. El código

correspondiente se muestra a continuación:

if((dependency_id != last_dependency_id || quality_id != last_quality_id || temporal_id != last_temporal_id) && (NALU_type == 1 || NALU_type == 5 || NALU_type == 20)){ int extract_layer_pos = array_position_of_DTQ_th(extract_layer, last_dependency_id, last_temporal_id, last_quality_id, num_layer); extract_layer[extract_layer_pos].bandwidth = bandwidth(extract_layer[extract_layer_pos]); } }


Este código, se encarga de que el ancho de banda estimado incluya todas las unidades

NAL que formen parte del fotograma. Se realiza una vez analizada la siguiente unidad

NAL para evitar que se trate de un fotograma formado por varias unidades NAL. Se

consigue así, que la estimación sea realizada con todo el tamaño incluido. El método

“array_position_of_DTQ_th” se encarga de devolver la posición del vector de objetos

“extraction_layer” en que se encuentran los identificadores “last_temporal_id”,

“last_quality_id” y “last_dependency_id” como DTQ_th del objeto. Así, una vez

seleccionado el objeto “extraction_layer” se pasa a utilizar el método “bandwidth”

para obtener la estimación del ancho de banda de transmisión de la capa en tiempo

real, método que se verá en el siguiente apartado.

4.2.3.2. Función estimación ancho de banda:

Vamos a ver a continuación, el método que se encarga de calcular el ancho de banda

estimado para una capa en concreto. Se muestra a continuación el código de la función

y una breve descripción sobre su funcionamiento.

float bandwidth(extraction_layer& extract_layer){ float fps, bandwidth; if(extract_layer.num_NALU_included == 0) return 0; if(extract_layer.temporal_id_th == 0){ fps = 12.5; } else if(extract_layer.temporal_id_th == 1){ fps = 12.5; } else if(extract_layer.temporal_id_th == 2){ fps = 25; } bandwidth = (float)((float)extract_layer.size_aggregated * fps / (float)extract_layer.num_NALU_included); //Reinicializar variables extract_layer.real_time_size = 0; extract_layer.size_aggregated = 0; extract_layer.num_NALU_included = 0; return bandwidth; }


Esta función se encarga de obtener el ancho de banda estimado en tiempo real, a

partir de las estimaciones de tamaño y del número de fotogramas incluidos, mediante

la rectificación según la velocidad de reproducción, para determinar que ancho de

banda será necesario para la extracción hasta cada una de las diferentes capas.

Los detalles importantes a destacar son dos, en primer lugar, al trabajar con la

acumulación de unidades NAL incluidas de la capa superior en lugar que de todas las

capas incluidas, la velocidad de reproducción en la estimación debe ser la mitad para

todos los casos que la velocidad de reproducción real.

En segundo lugar, se ha añadido el código que reinicia el algoritmo cada vez que se

obtiene el ancho de banda estimado, concretamente, reinicializando tamaños y

número de unidades NAL incluidas.

Por último, y no menos importante, se debe tener en cuenta que esta función deberá

ser redefinida para otra codificación que no cumpla una velocidad de reproducción de

12,5 frames/s con “temporal_id” igual a 0.

4.2.4. Estrategias temporales en la estimación del ancho de banda:

Una vez vista la implementación de la estimación del ancho de banda adaptativo,

vamos a ver las distintas estrategias temporales en cuanto a instantes de estimación y

obtención de ancho de banda de transmisión, para poder tratar con dicha estimación a

nivel de aplicación a través del tiempo.

Las diferentes estrategias serán o bien secuencialmente, en que se estima y se

transmite secuencialmente cada vez, provocando un retardo a nivel de aplicación

entre transmisiones, o concurrentemente, con el uso de dos hilos, cada uno de los

cuales se encarga de una de las dos tareas.

Viendo, en primer lugar que la estrategia secuencial, puede provocar retardos a nivel

de aplicación, la elección tomada es su ejecución concurrente, lo cual ya de entrada

pasa a justificar el uso de dos hilos a nivel de aplicación, tal y como se verá en el

capítulo siguiente.

Los instantes en que se va a realizar la estimación del ancho de banda necesario para

la transmisión de una determinada capa, vendrán limitados por el filtrado adaptativo.

El hecho de que sólo sea posible un intercambio entre capas cada vez que aparezca

una tira I con DTQ igual a 000, hace que realizar estimaciones después de cada

fotograma no sea interesante, porque el algoritmo de filtrado adaptativo limita los

instantes en que se puede cambiar el DTQ_th. Como se ha visto en el capítulo 3 si se

cogieran instantes arbitrarios, la extracción daría lugar a flujos no conformantes con el

estándar.


De esta forma, se genera el concepto de iteraciones de diferencia entre los dos hilos,

entendiendo iteración, como cada instante de estimación que se avance el primer hilo

en las estimaciones al segundo hilo. Se define, cada iteración según la limitación propia

del filtrado adaptativo, es decir cada vez que se llega a una tira I con DTQ igual a 000 se

realizará la estimación del ancho de banda, y consecuentemente se avanzará una

iteración. Es por esto que será un punto clave definir cuantas iteraciones se podrá

avanzar el primer hilo haciendo estimaciones al siguiente.

4.2.4.1. Implementación del uso de iteraciones:

Para poder tratar con el uso de iteraciones se definen unas variables extras en la

estructura “extraction_layer”, tal y como se puede ver a continuación.

struct extraction_layer { … int num_iterations; //Número de veces que se ha recorrido desde 000-I hasta 000-I. float aggregated_bandwidth; //Suma de los anchos de banda de todas las iteraciones presentes hasta el momento. };

Las variables que han añadido son el número de iteraciones que se avanza la

estimación a la obtención del ancho de banda para transmitir, y el ancho de banda

agregado, que se define de forma que se vayan sumando los anchos de banda a

medida que se avancen iteraciones para obtener los resultados como el promediado

entre el ancho de banda agregado y el número de iteraciones.

void actualizate_bandwidth(extraction_layer& extract_layer){ extract_layer.bandwidth = bandwidth(extract_layer); extract_layer.num_iterations++; extract_layer.aggregated_bandwidth = extract_layer.aggregated_bandwidth + extract_layer.bandwidth; }

El método “actualízate_bandwidth” se encarga de obtener el ancho de banda según lo

expuesto anteriormente, con el único método dependiente del video en cuestión

(“bandwidth”), incrementa el número de iteraciones y suma el ancho de banda


obtenido al agregado, de forma que si es la primera iteración que se avanza el valor

agregado será exactamente el valor del ancho de banda de la iteración.

float read_bandwidth(extraction_layer& extract_layer, sem_t* s1, sem_t* s3){ float bandwidth_aux = extract_layer.aggregated_bandwidth / extract_layer.num_iterations; extract_layer.bandwidth = 0; if(extract_layer.num_iterations > 1){ extract_layer.aggregated_bandwidth = extract_layer.aggregated_bandwidth * (extract_layer.num_iterations - 1) / extract_layer.num_iterations; } else extract_layer.aggregated_bandwidth = 0; extract_layer.num_iterations--; return bandwidth_aux; }

En cambio, el método “read_bandwidth” hace un promediado entre el número de

iteraciones del ancho de banda agregado, de forma que se consigue, que si se deja una

sola iteración de diferencia como mucho, los valores estimados en tiempo real sean los

correctos.

Es importante darse cuenta, que el acceso a estos métodos deberá definir control de

acceso ya que se accederá por dos hilos a direcciones de memoria compartida. El

control de acceso se verá en el capítulo siguiente, y se realiza mediante el uso de

semáforos.

Además, se ha de notar que mediante este control de acceso, se va a controlar cuántas

iteraciones se puede avanzar la estimación a la obtención del ancho de banda a

transmitir.

Por otra parte, aunque se ha definido un control con promediados, también sería

posible definirlo permitiendo que el primer hilo se avance más de una iteración y que

los tamaños de ancho de banda fueran los valores obtenidos en la estimación

mediante el uso de vectores que contengan todas las estimaciones en lugar de una

variable agregada de ancho de banda. Aunque, obviamente, se iba a complicar

bastante más la implementación en código.


Capítulo 5:

Transmisor y receptor:

En este capítulo, vamos a ver el desarrollo del transmisor adaptativo, con cada una de

sus peculiaridades a nivel de programación de la aplicación, tales como semáforos de

control de acceso, y uso de varios hilos ejecutados concurrentemente. A parte,

también se verán los criterios de diseño del receptor, que a diferencia del transmisor

no ha sido desarrollado en el presente proyecto.

5.1. Implementación del transmisor adaptativo:

En este capítulo, se va a tratar la solución práctica empleada para diseñar la aplicación

de transmisión de flujo de video H264/SVC de forma adaptativa sobre el protocolo de

transporte TCP.

5.1.1. Justificación uso de dos hilos:

Con el objetivo de desarrollar la aplicación capaz de adaptarse a las condiciones de red

en la transmisión del flujo de datos de video codificados en H264/SVC, se ve la

necesidad de utilizar hilos ejecutados concurrentemente en el hecho que las diferentes

interacciones deben permitir estar transmitiendo continuamente para no crear

retardos secuenciales en las transmisiones de red.

Así, las tareas a llevar a cabo por parte del ejecutable final serán:

1. La estimación del ancho de banda de transmisión de cada una de las diferentes

capas, a través de computar el número de bytes a transmitir y las capas

incluidas rectificadas por la velocidad de reproducción.

2. La transmisión de las unidades NAL correspondientes a la capa con máximo

ancho de banda de transmisión inferior al ancho de banda de red disponible en

cada momento.

De esta forma, se genera la necesidad, de utilizar dos hilos ejecutados

concurrentemente y una clase intermedia compartida con todos los atributos de

caracterización del flujo de datos, el primero de los dos se encargará de analizar el

contenido, obtener el ancho de banda estimado de la forma expuesta en el capítulo 4,

y almacenarlo en el objeto compartido por los dos hilos. En cambio, el segundo se

encargará de extraer según el algoritmo de filtrado los datos y la obtención de la

estimación de red en origen del ancho de banda disponibles, para posteriormente

transmitir las unidades NAL correspondientes por red obtenidas desde el objeto

compartido por los dos hilos.


5.1.2. Clase H264BitStream:

Para poder llevar a cabo el desarrollo, se ha empezado por diseñar una clase

intermedia compartida entre los diferentes hilos, la clase se ha bautizado como

H264BitStream.

Se ha decidido desarrollarla como una cola circular con muchos campos para cada una

de las posiciones de la cola, de forma que cada unidad NAL quede caracterizada por

sus atributos facilitando así el reconocimiento por parte del segundo hilo en la

extracción adaptativa.

Los atributos propios de la cola circular son:

int capacity; //Capacidad de la cola circular int numNALUnit; //Número de elementos introducidos en la cola circular (Número de unidades NAL) int pos_set; //Posición en la que debe ser introducido el siguiente elemento int pos_get; //Posición en la que toca extraer el siguiente elemento

Se utilizan estos atributos para controlar los casos de cola llena y cola vacía que en el

acceso concurrente de los hilos implican el uso de semáforos de control de acceso,

para evitar situaciones en las que se produzcan problemas de concurrencia en la

consulta o modificación de los atributos de la cola circular, tal y como se verá en este

capítulo más adelante.

Los otros atributos propios del flujo de datos de video H264/SVC son:

char** array_NALU; //Vector de punteros de unidades NAL int size_H264BitStream; //Tamaño de H264BitStream almacenado en la cola circular int* size_NALU; //Vector con los tamaños de cada unidad NAL int* NALU_type; //Vector con los valores de tipo de unidad NAL int* dependency_id; //Vector con los valores de escalabilidad espacial int* quality_id; //Vector con los valores de escalabilidad de SNR int* temporal_id; //Vector con los valores de escalabilidad temporal int* slice_type; //Vector con los valores de tipo de tira (En el caso de no ser unidades NAL VCL tendrá valor de -1) int max_sizeNALU; //Tamaño máximo de todas las unidades NAL del H264BitStream


Se utilizan vectores correspondientes a cada uno de los atributos que permiten

clasificar si la unidad NAL se incluye en la extracción de una capa y/u otra en función

del algoritmo de extracción. Además se inicializa un doble puntero, para convertirse en

matriz correspondiente a la variable “array_NALU”, se diseña de esta forma para

asegurar que en cada uno de los índices se va a introducir el contenido de datos de

cada unidad NAL analizada, para posteriormente tener acceso a la transmisión por red

a través de la cola circular intermedia.

Se diseñan dos constructores, uno el por defecto, que se encarga de reservar el

espacio de memoria correspondiente a los vectores y la matriz que contendrá el

contenido del flujo de datos, y otro, que inicializa el contenido de la cola circular con

un determinado número de unidades NAL que se pasan como variable buffer

directamente como atributo del constructor. Para el primer caso, se puede inicializar el

contenido de la cola circular mediante el método init().

H264BitStream::H264BitStream(const int max_capacity, const int max_NALUsize) { //Inicialización parámetros cola circular pos_set = 0; pos_get = 0; capacity = max_capacity; numNALUnit = 0; size_H264BitStream = 0; max_sizeNALU = max_NALUsize; //Reserva del espacio de memoria necesario para almacenar el contenido de todas las unidades NAL array_NALU = new char* [capacity]; for(int i=0; i<capacity; i++) array_NALU[i] = new char[max_sizeNALU]; size_NALU = new int[capacity]; NALU_type = new int[capacity]; dependency_id = new int[capacity]; quality_id = new int[capacity]; temporal_id = new int[capacity]; slice_type = new int[capacity]; } H264BitStream::H264BitStream(const int max_capacity, const char* buffer, const int numNALU, int* pos_inicio_NALU, const int max_NALUsize);


void H264BitStream::init(const char* buffer, const int numNALU, int* pos_inicio_NALU);

En el segundo caso o en la combinación del primer y el tercer caso, se inicializa el

contenido de la cola circular intermedia, pasándole como parámetros un vector de

caracteres con el contenido de las unidades NAL a introducir en la cola circular, y un

vector de posiciones iniciales para identificar los puestos en que están situados los

inicios de cada unidad NAL.

Las posiciones de inicio de unidad NAL que se pasan como parámetro en los casos con

inicialización apuntan a la posición del byte ‘\1’, correspondiente al cuarto byte del

conjunto de bytes que indican el inicio de una unidad NAL (“\0\0\0\1”). De esta forma

la inicialización de los tamaños se hace restando dos posiciones de inicio consecutivas,

ya que identifican el inicio de dos unidades NAL consecutivas, y la segunda posición es

a su vez la posición final de la primera unidad NAL de las dos. A parte, se restan cuatro

bytes porque se contabiliza en la cola circular el tamaño de datos codificados sin incluir

la identificación del inicio de unidad NAL.

La inicialización del contenido de la unidad NAL en la cola circular, se hace copiando el

contenido del buffer que se pasa como parámetro entre las posiciones de inicio y final

de cada unidad NAL. De esta forma, se empieza a copiar en la posición inicial más uno,

para apuntar al primer byte de la unidad NAL, y se termina de copiar en la posición

inicial de la siguiente unidad NAL menos tres.

//Inicialización de los tamaños de las unidades NAL correspondientes a las unidades NAL que se van a introducir

for(int i=0; i<capacity; i++){ if(i < numNALUnit){ size_NALU[i] = pos_inicio_NALU[i+1]-pos_inicio_NALU[i]-4; } else size_NALU[i] = 0; } //Inicialización de la matriz que contendrá las unidades NAL for(int i=0; i<numNALUnit; i++){ pos = pos_inicio_NALU[i]+1; for(int j=0;j<size_NALU[i];j++){ array_NALU[i][j]=buffer[pos]; pos++; } pos_set = (pos_set + 1) % capacity; }


A parte, de los métodos constructores de la clase, también se han diseñado métodos

para la introducción y extracción de unidades NAL en la cola circular de forma

individual, y también métodos para la obtención de los atributos correspondientes a

cada unidad NAL. Vamos a ver en primer lugar los métodos para la introducción

(“put_NALU”) y para la extracción (“get_NALU”) de unidades NAL, que como se puede

ver modifican las variables propias de la cola circular, de forma que en cada utilización

de por ejemplo, el método “get_NALU” se incrementa el “pos_get”.

En el método “put_NALU”, se introduce una unidad NAL en la cola circular. Los

parámetros que se pasan a la función son un vector de caracteres que contiene el

contenido del flujo de datos H264/SVC, y las posiciones inicial y final del vector en las

que está contenida la unidad NAL. El funcionamiento del método es tal que se inicializa

en primer lugar el contenido de la unidad NAL de la cola circular copiando el contenido

del “buffer” entre las posiciones inicial y final. Acto seguido, se inicializan los atributos

de la unidad NAL, sacando el contenido de las cabeceras de la unidad NAL y de la

cabecera de la tira.

Los métodos “obtain_lenght_exp_Golomb” y “decod_exp_Golomb” utilizados en la

obtención del tipo de tira, se encargan de tratar con palabras codificadas con el

algoritmo Exp-Golomb. El primero de los dos obtiene el tamaño de la palabra Exp-

Golomb y el segundo se encarga de decodificar una palabra codificada según Exp-

Golomb. Los atributos que se pasan a la función son: el byte dentro del vector de

caracteres y el bit inicial de la palabra Exp-Golomb dentro del byte. En este caso se

utiliza primero la obtención de la longitud para saltarse la primera palabra Exp-Golomb

de la cabecera de la tira y se obtiene la decodificación de la segunda palabra que es la

correspondiente al tipo de tira.

//Introducción de una unidad NAL en la cola circular intermedia void H264BitStream::put_NALU(const char* buffer, const int pos_inicial, const int pos_final) { int eg_length, eg_byte_inicial; //Introducir NAL Unit en la posición "pos_set" for(int i=0; i<(pos_final-pos_inicial); i++){ array_NALU[pos_set][i] = buffer[pos_inicial + i]; } size_NALU[pos_set] = pos_final - pos_inicial; size_H264BitStream += size_NALU[pos_set];


//Obtener NALU type, DTQ y Slice_type NALU_type[pos_set] = (int)((array_NALU[pos_set][0])&0x1F); if(NALU_type[pos_set] == 14 || NALU_type[pos_set] == 20){ dependency_id[pos_set] = (int)(((array_NALU[pos_set][2])&0x70)>>4); quality_id[pos_set] = (int)((array_NALU[pos_set][2])&0x0F); temporal_id[pos_set] = (int)(((array_NALU[pos_set][3])&0xE0)>>5); } else if(NALU_type[pos_set] == 1 || NALU_type[pos_set] == 2 || NALU_type[pos_set] == 3 || NALU_type[pos_set] == 4 || NALU_type[pos_set] == 5 || NALU_type[pos_set] == 6 || NALU_type[pos_set] == 7 || NALU_type[pos_set] == 8 || NALU_type[pos_set] == 15){ dependency_id[pos_set] = 0; quality_id[pos_set] = 0; temporal_id[pos_set] = 0; } if(NALU_type[pos_set] == 1 || NALU_type[pos_set] == 5){ eg_length = obtain_length_exp_Golomb(array_NALU[pos_set],1,0); eg_byte_inicial = eg_length/8; eg_byte_inicial += 1; eg_length = eg_length % 8; slice_type[pos_set] = decod_exp_Golomb(array_NALU[pos_set], eg_byte_inicial, eg_length, &eg_length); } else slice_type[pos_set] = -1; numNALUnit++; pos_set = (pos_set + 1) % capacity; }

El método “get_NALU” extrae una unidad NAL de la cola circular. En concreto copia la

información de la posición “pos_get”, en los parámetros pasados como atributos, es

decir, copia el contenido de la unidad en el atributo “NALU” y de los atributos de

caracterización de la unidad NAL en los demás atributos de la función.

void H264BitStream::get_NALU(char* NALU, int& NALU_size, int& d_id, int& t_id, int& q_id); void H264BitStream::get_NALU(char* NALU, int& NALU_size, int& d_id, int& t_id, int& q_id, int& type_slice); void H264BitStream::get_NALU(char* NALU, int& NALU_size, int& d_id, int& t_id, int& q_id, int& type_slice, int& type_NALU)


{ //Copiar el contenido de la unidad NAL en la posición "pos_get" for(int i=0; i<size_NALU[pos_get]; i++){ NALU[i] = array_NALU[pos_get][i]; } type_NALU = NALU_type[pos_get]; NALU_size = size_NALU[pos_get]; d_id = dependency_id[pos_get]; t_id = temporal_id[pos_get]; q_id = quality_id[pos_get]; type_slice = slice_type[pos_get]; type_NALU = NALU_type[pos_get]; numNALUnit--; pos_get = (pos_get + 1) % capacity; }

Vamos a ver a continuación los demás métodos utilizados en la clase H264BitStream,

usados para obtener externamente los atributos de una determinada unidad NAL, se

muestran las cabeceras de los métodos debido a la simpleza de dichos métodos.

//Obtención de atributos //Obtener tamaño total de las unidades NAL almacenadas en la cola circular int H264BitStream::get_size_H264BitStream(); //Obtener el número de unidades NAL almacenadas en la cola circular int H264BitStream::get_numNALU(); //Obtener el tamaño maximo en unidades NAL para almacenar en la cola circular int H264BitStream::get_capacity(); //Obtener el tamaño de la unidad NAL en la posición numNALU int H264BitStream::get_sizeNALU(const int numNALU); //Obtener "array_NALU[numNALU][pos]" char H264BitStream::get_content(const int numNALU,const int pos); //Obtener contenido de la unidad NAL número numNALU void H264BitStream::get_content(char *buffer, const int numNALU); //Obtener NALU_type en la posición numNALU int H264BitStream::get_NALU_type(const int numNALU); //Obtener dependency_id en la posición numNALU


int H264BitStream::get_dependency_id(const int numNALU); //Obtener quality_id en la posición numNALU int H264BitStream::get_quality_id(const int numNALU); //Obtener temporal_id en la posición numNALU int H264BitStream::get_temporal_id(const int numNALU); //Obtener slice_type en la posición numNALU int H264BitStream::get_slice_type(const int numNALU); //Obtener tamaño maximo de unidades NAL int H264BitStream::get_max_sizeNALU(); //Obtener la siguiente posición en la que se va a introducir una unidad NAL int H264BitStream::get_pos_set(); //Obtener la siguiente posición de la que se va a extraer una unidad NAL int H264BitStream::get_pos_get();

5.1.3. Justificación de semáforos en la cola circular:

Como se ha comentado antes, el uso de dos hilos con acceso concurrente a la cola

circular intermedia implica la necesidad de combatir las situaciones de contorno en la

modificación de variables compartidas. Por esta razón, aunque se hayan mostrado los

métodos sin control de acceso mediante semáforos, realmente se ha trabajado con

semáforos para solucionar los problemas.

De esta forma, se va a mostrar la solución elegida para tratar con la clase

H264BitStream. Al ser una cola circular compartida, y haber accesos por parte de dos

hilos, uno para introducir y el otro para extraer el contenido de una posición de la cola

circular, se ha tenido que definir el control de acceso en los métodos “get_NALU” y

“put_NALU”.

La solución utilizada consta de dos semáforos, uno de acceso a zona crítica y el otro de

control de las situaciones en que el hilo que accede concurrentemente debe ser

detenido, casos de cola bacía para extraer unidades NAL y cola llena para introducirlas.

La solución utilizada en el método “put_NALU” es la siguiente:

void H264BitStream::put_NALU(const char* buffer, const int pos_inicial, const int pos_final, const int is_last_NALU) {


//Coger Exclusión Mutua sem_wait(&s1); if(numNALUnit == capacity && pos_set == pos_get){ num_wait_s2++; sem_post(&s1); sem_wait(&s2); sem_wait(&s1); } //Introducir unidad NAL //Liberar exclusión mutua if(numNALUnit == 1 && num_wait_s2 > 0){ num_wait_s2--; sem_post(&s2); } sem_post(&s1); }

Como se puede observar en el código anterior se controla el acceso a la zona crítica

controlando el caso en que no se puede introducir ninguna unidad NAL, que se

corresponde con que la cola este llena en el momento de ir a introducir una nueva

unidad NAL.

Para controlar entre los dos extremos que haya algún hilo detenido en la cola se utiliza

la variable número de hilos en espera en el segundo semáforo, que cuando tenga un

valor superior a cero, indicara o que se encuentra en caso de cola llena o de cola bacía

con hilos en espera a que cambie la situación actual.

De esta forma, en el caso del método “put_NALU” se controla al final del método si se

sale de una situación de cola bacía con hilos detenidos en el método “get_NALU”

debido a que la cola este bacía, comprobando que haya hilos detenidos en el segundo

semáforo y que el número de unidades NAL introducidas en la cola al salir sea de una,

la que se acaba de introducir, y en tal caso se pone un recurso para los hilos detenidos.

La solución utilizada en el método “get_NALU” es la siguiente:

void H264BitStream::get_NALU(char* NALU, int& NALU_size, int& d_id, int& t_id, int& q_id, int& type_slice, int& type_NALU) { //Coger Exclusión Mutua sem_wait(&s1); if(numNALUnit == 0 && pos_set == pos_get){


num_wait_s2++; sem_post(&s1); sem_wait(&s2); sem_wait(&s1); } //Obtener unidad NAL //Liberar exclusión mutua if(numNALUnit == (capacity-1) && num_wait_s2 > 0){ num_wait_s2--; sem_post(&s2); } sem_post(&s1); }

En el método “get_NALU”, la situación en que se tiene que detener la ejecución del

hilo concurrente es en el caso de que al ir a extraer la cola circular esta bacía. Se

implementa la misma solución que antes, se utiliza el primer semáforo para entrar en

exclusión mutua a la zona donde comprobar si se trata del caso cola bacía, y detener el

hilo en dicho caso. En la salida del método debe comprobarse que no se salga de la

situación de cola llena con algún hilo en espera para poner un recurso en el semáforo

dos en tal caso.

La solución compatibiliza el uso de dos semáforos tratando los dos casos extremos, ya

que en el segundo semáforo que es donde realmente se detienen los hilos, solo puede

encontrarse uno de los dos casos a la vez, es decir en ningún caso puede haber hilos

detenidos en cola bacía y llena a la vez. Se consigue así, el funcionamiento deseado de

la cola circular en que los accesos concurrentes al mismo recurso compartido (misma

posición en la cola circular) se controla mediante semáforos como control de acceso.

Además, en los demás métodos de acceso a atributos de la cola circular o de una

determinada unidad NAL, se implementa un control de acceso mediante el primer

semáforo de entrada y salida de la zona critica.

//Los demás métodos sem_wait(&s1) //Metodo Sem_post(&s1);

5.1.4. Solución de semáforos en la aplicación:


Tal y como se ha comentado en el último apartado del capítulo 4, también se utilizaran

semáforos para controlar los instantes de actualización del ancho de banda estimado

de transmisión por parte del primer hilo concurrente, y en los instantes de lectura de

la estimación del ancho de banda de transmisión de cada una de las posibles capas a

transmitir.

En el capítulo 4 se han visto las diferentes estrategias que se pueden seguir en la

diferencia en el número de iteraciones entre lectura por parte del primer hilo y

transmisión por parte del segundo, pudiendo dejar un mínimo de una iteración entre

actualización y un máximo indeterminado de iteraciones de diferencia, teniendo en

cuenta que con la solución utilizada cuando hay más de una iteración de diferencia

entre los dos hilos se realizan promediados del ancho del ancho de banda de

transmisión de las diferentes capas entre el número de iteraciones avanzadas.

A pesar, de haber expuesto las diferentes estrategias, no se ha presentado la solución

con semáforos correspondiente, solución que se va a ver a continuación. Los métodos

en los que se va a utilizar semáforos son “actualizate_bandwidth” y “read_bandwidth”

de la forma que se muestra en los párrafos siguientes:

void actualizate_bandwidth(extraction_layer& extract_layer, sem_t* s1, sem_t* s3){ sem_wait(s1); //Actualizar ancho de banda de transmisión de la capa if(num_wait_s3 > 0){ sem_post(s3); } sem_post(s1); } float read_bandwidth(extraction_layer& extract_layer, sem_t* s1, sem_t* s3){ sem_wait(s1); if(extract_layer.num_iterations == 0){ num_wait_s3++; sem_post(s1); sem_wait(s3); sem_wait(s1); } //Leer ancho de banda estimado de la capa sem_post(s1); return bandwidth_aux;


}

Como se puede ver en las actualizaciones solo se coge el semáforo de exclusión mutua,

mientras que en la lectura de los valores estimados se detiene al hilo en caso que el

número de iteraciones de diferencia entre los dos hilos sea de cero debido a que

cuando este valor es cero no hay lecturas posibles del ancho de banda estimado,

situación que se corresponde cuando los dos hilos se sincronizan.

De esta forma, en el “actualízate_bandwidth”, cuando se detectan hilos en espera

(variable “num_wait_s3” más grande que cero), se ponen recursos para que los hilos

en espera sean despertados. El funcionamiento, es tal que en la actualización del

ancho de banda sólo se va a despertar hilos en la lectura, cuando la lectura se avance a

la actualización, es decir el caso en que se hayan quedado detenidos.

Para que no haya problemas de concurrencia el primer semáforo debe ser compartido

con el primero de la clase H264BitStream razón por la que se añade el siguiente

método a dicha clase.

//Obtener la dirección de memoria sem_t* H264BitStream::get_s1_memdir() { sem_t* sem; sem_wait(&s1); sem = &s1; sem_post(&s1); return sem; }

Así, el control de acceso a los métodos de actualización y lectura de la estimación del

ancho de banda de transmisión solo permite detener el caso de lectura del valor

almacenado por parte de la actualización pero no limita el número de iteraciones que

se puede avanzar el hilo de actualización. Se ha diseñado así para a posteriori controlar

a nivel de aplicación el número de iteraciones de diferencia a nivel de aplicación.

La solución final por la que se ha optado es la de dejar una sola iteración de diferencia

entre actualizaciones y lecturas, lo que se traduce en un máximo de dos iteraciones en

el análisis de unidades NAL por parte del primer hilo antes de que sean analizadas por

parte del segundo.

Es por esta razón que teniendo en cuenta la limitación propia del filtrado adaptativo en

los instantes de actualización del ancho de banda que se producen al final de una


iteración, entendiendo una iteración como el número de unidades NAL entre una tira I

con DTQ igual a 000 y la siguiente con las mismas características; el tamaño de la cola

circular para evitar que la aplicación se detenga debe cumplir la siguiente restricción,

debido a que al inicio de la ejecución debe haber estimado como mínimo una iteración

sin que haya comenzado a transmitir:

CAPACIDAD COLA CIRCULAR > NUMERO DE UNIDADES NAL EN UNA ITERACIÓN

Además en el caso de una iteración como máximo se debe cumplir que:

CC_CAPACITY <= NUM_NALU_IN_1_ITER * (NUM_ITER + 1)

Vamos a ver a continuación la solución de semáforos a nivel de aplicación con la

restricción de un máximo de una iteración entre actualizaciones y lecturas del ancho

de banda estimado, y a analizar si podría aparecer algún problema de concurrencia o

de detención de la aplicación debido a los posibles entrelazados.

HILO 1{ 1_iter_to_circular_queue(); actualizate_BW(); while(!end_of_execution){ 1_iter_to_circular_queue(); sem_wait(&s4); actualizate_BW(); } } HILO 2{ while(!end_of_execution){ read_BW(); obtain_DTQ_th(); tx_1_iter_with_DTQ_th(); sem_post(&s4); } }

Esta solución, permite cumplir los criterios de diseño debido a que con el semáforo

que se ha añadido se asegura que la ejecución concurrente nunca se avance más de

una iteración de actualizar a leer, o dos en el análisis del contenido. Los casos críticos

serán:


1. La combinación de cola bacía con que se detenga el primer hilo en el semáforo

cuatro, lo cual no sucederá nunca debido a que cuando se detiene en el

semáforo el primer hilo, va con dos iteraciones de diferencia.

2. Cola llena y que se detenga en “read_BW”, que tampoco sucederá porque con

la cola llena cumpliendo la restricción antes impuesta habrá como mínimo un

recurso para leer el ancho de banda estimado.

Por otro, lado tampoco se produce ningún caso en que ambos hilos queden detenidos

a la vez, razón por la que la solución propuesta es correcta.

5.1.5. Solución de ancho de banda adaptativo:

Para conseguir que la solución final sea adaptativa al protocolo de red, se hacen

estimaciones del ancho de banda disponible para poder transmitir, ancho de banda

que vendrá limitado por el protocolo TCP, y se compara cogiendo el valor máximo

menor que el disponible con los anchos de banda de transmisión de las capas, de

forma que siempre se va a transmitir a la máxima velocidad posible.

De esta forma el método del hilo 2 “obtain_DTQ_th”, en el que se obtiene el DTQ_th

tal que el ancho de banda de transmisión sea el máximo menor que el disponible,

queda de la forma siguiente.

void obtain_DTQ_th(int d_th, int t_th, int q_th, const float* read_BW, const extraction_layer* extract_layer) { int bandwidth_th = obtain_BW_th_from_socket_options(); int BW_pos = 0; for(int i=1; i<num_layer; i++){ if(read_BW[i] < bandwidth_th && read_BW[i] > read_BW[BW_pos]) BW_pos = i; } d_th = extract_layer[BW_pos].dependency_id_th; t_th = extract_layer[BW_pos].temporal_id_th; q_th = extract_layer[BW_pos].quality_id_th; }

Se consigue así, que en cada iteración se trabaje con la extracción de la capa de

tamaño máximo con la que el ancho de banda de red disponible permite extraer a

tiempo real.


En esta versión, se ha hecho que en caso que el ancho de banda no fuera suficiente

para poder transmitir la capa 000, la transmita igualmente, caso que se controlara

mediante el uso de un buffer de recepción, que se encargara de almacenar cuando no

se transmita a tiempo real. De igual forma, se podría definir un valor de menos uno de

inicio que a la postre se interpretara en caso de ser el valor elegido, como que en esta

iteración no se transmitiera.

5.1.6. Medidas para reducir el alto número de intercambios entre capas:

Durante el transcurso del desarrollo de las pruebas de red (ver capítulo 6) se ha

detectado que existe en las pruebas un gran número de intercambios entre capas

debido a la alta variabilidad del video codificado. Esto puede llegar a ser un poco

desquiciante ya que durante la reproducción del video, en caso de no indicarle una

resolución fija para el video, se va a redimensionar el video constantemente.

Por esta razón, se buscan estrategias que permitan reducir el número de intercambios

entre capas, para conseguir una reproducción más suave de la secuencia de video.

La primera estrategia que se va a utilizar es utilizar un segundo estimador de ancho de

banda que suavice los saltos que existen con el estimador a partir de las opciones del

“socket”. El estimador hará un seguimiento del tamaño transmitido hasta un

determinado momento rectificado por el tiempo de ejecución. Así, el ancho de banda

disponible vendrá determinada por la siguiente expresión:

BW(n) = a * BW_socket + (1 - a) * BW(n – 1)

donde: BW(n – 1) = tamaño_transmitido (bit) / tiempo_ejecución (s)

Con esta estrategia, se consigue una variabilidad del ancho de banda disponible más

suave que con el primer estimador. Esto podría provocar que haya casos de congestión

en que se transmita por encima del ancho de banda disponible, pero estos posibles

errores van a ser resueltos en el buffer de entrada de los “socket”, haciendo que se

precargue el buffer sin llegar a transmitir, porque vendrá controlado por el control de

congestión de TCP.

La segunda estrategia para evitar este problema, será utilizar un ciclo de histéresis en

el intercambio entre capas. Hacer que para subir de capa necesite el ancho de banda

necesario para hacerlo más un umbral extra, y para bajar el necesario menos un

umbral extra. Se muestra en la siguiente figura un ejemplo, en el que el ancho de

banda necesario para cambiar de capa es de 700 Kbit/s, se sube con 800 Kbit/s y se

baja con 600 kbit/s.


Figura 5.1: Ciclo de histéresis

Finalmente, el ciclo de histéresis solo se aplicara a los casos en que se suba de capa,

porque en el caso de intercambios entre capas hacia abajo, podría provocar problemas

de transmitir más de lo disponible. En concreto, solo se va a aplicar en el caso de

cambio de resolución de inferior a mayor, porque en los demás casos no habrá cambio

de resolución del video.


5.2. Criterios de diseño del receptor:

La parte del receptor a diferencia del transmisor se va a tratar con un marco de trabajo

en el que se adaptara el transmisor, en concreto se va a utilizar un receptor de TCP,

que solo se encargara de recibir el contenido transmitido sin tener en cuenta las

características del video transmitido.

Se deben diferenciar dos aplicaciones objetivo, en primer lugar la transmisión de video

con buffers de recepción, que son el caso principal, y en segundo lugar las aplicaciones

orientadas a reproducción en tiempo real. El primer caso se contempla mediante el

uso de un receptor estándar al que se le añade la peculiaridad de utilizar un buffer de

recepción en el destino, para poder almacenar parte del video antes de reproducirlo, y

como se verá en el capítulo siguiente será el caso analizado. Para el segundo caso se

van a mostrar los criterios de diseño pertinentes pero no se va a desarrollar dejándolo

como posible mejora al presente proyecto.

5.2.1. Relación entre tiempo de reproducción y tiempo de transmisión:

El parámetro más crítico en el receptor orientado a funcionar en tiempo real, serán los

tiempos de transmisión extremo a extremo. Así, en características del video esto se

traduce en la diferencia entre los tiempos de transmisión y los tiempos de

reproducción, ya que la naturaleza del estándar hace que se transmitan antes algunas

tiras que otras que se reproducen antes debido a los niveles de dependencia temporal

propios del H264.

Es por esta razón que en primer lugar se deberá hacer una conmutación entre tiempos

de transmisión y tiempos de reproducción, para a posteriori controlando el tiempo de

reproducción en el receptor poder hacer comparaciones de tiempo y en caso de que

alguna unidad NAL llegara fuera del intervalo de reproducción descartar el contenido

recibido.

Vamos a ver a continuación como relacionar los tiempos de reproducción con los de

transmisión, para así poder hacer a posteriori dichas comparaciones. Es importante

darse cuenta que las relaciones serán dependientes del parámetro “GOP_size” elegido

y de los identificadores de dependencia temporal asociados a cada tamaño de GOP.

Así, en primer lugar se va a mostrar el código para determinar los identificadores de

dependencia temporal, a partir del tamaño de GOP.

void obtain_B_structure(const int GOP_size, int* B_t_id_structure){ int num_B_t_max = 0; int num_slice = 0; int dist_B = 0;


num_t = log2(GOP_size); for(int i=0 ; i<(GOP_size - 1); i++){ B_t_id_structure[i] = 0; } for(int i=0; i<num_t; i++) B_t_id_structure[i] = i + 1; num_slice += num_t; for(int i=0; i<num_t; i++){ if((dist_B = obtain_dist_B(B_t_id_structure[i], num_t)) == -1){ std::cout << "Internal error while computing dist_B\n"; return; } if(B_t_id_structure[i] == num_t) num_B_t_max ++; if(dist_B == 0 && (B_t_id_structure[i] != num_t || num_B_t_max == 2)){ if(num_B_t_max == 2) num_B_t_max = 0; } else if((i + dist_B + 2 < GOP_size)){ B_t_id_structure[i + dist_B + 1] = B_t_id_structure[i]; num_slice ++; } } num_B_t_max = 0; int i = 0; while(num_slice < (GOP_size - 1)){ int aux; while(B_t_id_structure[i] != 0){ i++; } i--; aux = i; while(B_t_id_structure[i] < num_t){ B_t_id_structure[i+1] = B_t_id_structure[i] + 1; num_slice ++; /*DEBUG std::cout << "t[" << (i + 1) << "] = " << t[i + 1] << '\n'; //END DEBUG*/ i++; } i = aux;


while(B_t_id_structure[i] != 0){ if((dist_B = obtain_dist_B(B_t_id_structure[i], num_t)) == -1){ std::cout << "Internal error while computing dist_B\n"; return; } if(B_t_id_structure[i] == num_t) num_B_t_max ++; if(dist_B == 0 && (B_t_id_structure[i] != num_t || num_B_t_max == 2)){ if(num_B_t_max == 2) num_B_t_max = 0; } else if((i + dist_B + 2) < GOP_size){ int j = 0; while(B_t_id_structure[i + j + dist_B + 1] != 0 && B_t_id_structure[i] != B_t_id_structure[i + j + dist_B + 1]){ j++; } if(B_t_id_structure[i] != B_t_id_structure[i + j + dist_B + 1]){ B_t_id_structure[i + j + dist_B + 1] = B_t_id_structure[i]; num_slice ++; if(num_slice == (GOP_size - 1)) break; } } i++; } } return; }

Lo que hace este código es obtener los identificadores de dependencia temporal para

todos los casos con identificador mayor que uno y durante un tamaño de GOP. Está

basado en la estructura diádica de los GOP, y consigue pasándole como parámetro el

tamaño de GOP, devolver un vector que contiene en orden secuencial los valores de

los identificadores de dependencia temporal según su orden de transmisión.

Como se puede observar en el código se utiliza el método “obtain_dist_B”, que

básicamente lo que hace es calcular en qué posición se va a repetir el siguiente

identificador temporal, aunque a medida que avanzan las posiciones hay que añadir

rectificaciones para que cada valor se ponga en la posición correcta. El código de la

función es el siguiente:

int obtain_dist_B(const int t_id, const int num_t){


int dist_B = 0; for(int i=1; i<(num_t - t_id + 1); i++){ int aux; if((aux = exp2(2,i)) == -1) return -1; dist_B += aux; } return dist_B; }

Como se puede apreciar, las distancias entre la repetición de los mismos

identificadores temporales vienen determinados por la suma de las exponenciales de

dos elevado a cada valor entre uno y el número de identificadores temporales menos

el valor del identificador temporal. De forma que se generan distancias de 2, 6, 14, …

Por ejemplo para el caso de un tamaño de GOP igual a 8, en el que los identificadores

temporales según su orden de transmisión es: 1, 2, 3, 3, 2, 3, 3; para el caso con

identificador temporal igual a dos se obtiene una distancia 2, lo que colocaría el

segundo dos en la cuarta posición.

El el código general, la estructura obtenida se genera llenando las posiciones y cuando

se detecta que una posición relativa está ocupada se desplaza la posición a la derecha.

En este caso como se habría generado la estructura 1, 2, 3, 3, al obtener la distancia de

2 se pondría en la quinta posición. La estructura se genera analizando en primer lugar

los identificadores temporales menores y subiendo hasta los mayores, de forma que

las rectificaciones van saliendo en orden correcto para que el resultado sea el

esperado.

Una vez visto cómo obtener el orden de identificadores de dependencia temporal,

vamos a pasar a ver el código que permite obtener la relación buscada entre instantes

de transmisión, los que tenemos actualmente, e instantes de reproducción.

Para esto vamos a distinguir de igual forma que antes los valores con identificador

temporal superior a cero, para obtener la relación directa entre unos y otros. Es

importante darse cuenta que los valores que se buscan son el de las B, por lo que

siempre serán valores negativos respecto al valor de una I o una P anteriores en

tiempo de transmisión.

Vamos a ver a continuación, el código correspondiente a la obtención de los retardos

de reproducción respecto al orden de transmisión.

void obtain_num_frames_in_tr(int* n_frames, cons tint* temporal_id, cons tint GOP_size)


{ Int* array_pos = new int[2]; Int adding_size; n_frames[0] = -GOP_size / 2; for(int i=1; i<GOP_size; i++){ //Buscar las siguientes dos posiciones con mismo temporal_id search_next_2_positions(temporal_id, array_pos, i); adding_size = obtain_adding_size(GOP_size, temporal_id[i]); n_frames[array_pos[0]] = n_frames[i-1] – adding_size; n_frames[array_pos[1]] = n_frames[i-1] + adding_size; } return; }

Este código, se encarga de encontrar la relación entre identificadores temporales e

instantes de reproducción. Para ello se inicializa la primera posición correspondiente a

“temporal_id” igual a uno a la mitad del tamaño de GOP. Esto, será siempre así, según

la estructura diádica. A partir de la primera posición, lo que sucede es que para cada

repetición del identificador temporal, se obtiene una posición relativa que se suma y

se resta respecto a la posición anterior en tiempo para obtener su posición de orden

de reproducción.

Para realizar estas dos funcionalidades, se utilizan los métodos

“search_next_2_positions”, que se encarga de encontrar las dos posiciones siguientes

con el mismo identificador temporal; y “obtain_adding_size”, para obtener la posición

relativa que se debe sumar y restar en las dos nuevas posiciones obtenidas. El código

de estos dos métodos se muestra a continuación:

void search_next_2_positions(const int* temporal_id, int* array_pos, cons tint pos_inicial) { int tmp = pos_inicial + 1; array_pos[0] = pos_inicial; array_pos[1] = 0; while(array_pos[1] == 0){ if(temporal_id[tmp] == temporal_id[pos_inicial]){ array_pos[1] = tmp; } tmp ++; } return;


}

El método “obtain_adding_size” devuelve la diferencia relativa de la posición de la tira

en orden de reproducción respecto a la tira anterior, y está basada en la estructura

diádica. En concreto se obtiene la exponencial de dos elevado al número de

identificadores temporales menos el identificador temporal, dando lugar a resultados,

para por ejemplo un tamaño de GOP igual a 8, de 2 y de 1 para los identificadores

temporales de 2 y de 3.

Su funcionamiento es tal que teniendo como parámetro de entrada los identificadores

temporales: 1, 2, 3, 3, 2, 3, 3; las posiciones con “temporal_id” igual a 2 obtendrán

unas diferencias relativas de +/- 2, que respecto a la posición -4 del “temporal_id”

igual a 1, darán lugar a las posiciones -2 y -6. Lo mismo sucede con los “temporal_id”

igual a 3, que dan lugar a +/-1. Finalmente se obtiene un orden de reproducción: -4, -2,

-1, -3, -6, -5, -7.

Int obtain_adding_size(cons tint GOP_size, const int t_id) { Int dif = log2(GOP_size) – t_id; return (exp(2, dif)); }

El concepto sobre el que se ha trabajado es la correlación existente entre los

diferentes retardos relativos, que se basa en que a medida que se incrementa el

identificador temporal se va dividiendo por dos el tamaño que hay que añadir entre

retardos relativos.

Finalmente, el paso de número de tiras relativas a retardo relativo se obtiene

mediante la velocidad de reproducción.

Tiempo de reproducción = Número de fotogramas / fps

5.2.2. Estrategia de filtrado en recepción:

Una vez visto cómo obtener el vector de diferencias relativas entre tiempo de

reproducción y tiempo de transmisión se debe comprobar si el instante de recepción

de una unidad NAL es anterior o posterior al instante de entrega para reproducción,

para que en caso de que sea posterior dicha unidad NAL sea filtrada en recepción.


De esta forma, debido al comportamiento del filtrado de unidades NAL, el hecho de

filtrar en función de los tiempos de recepción podría provocar la conformación de

flujos de datos que no fueran decodificables.

Por esta razón, se van a usar dos hilos, el primero de los cuales se encargara de

comprobar los instantes de tiempo de recepción y en caso de que alguna unidad NAL

llegara fuera de tiempo, de redefinir el DTQ máximo de la extracción en función de que

capa se descarte en una determinada iteración. Así, el segundo hilo, se encargara de

aplicar el algoritmo de filtrado al flujo resultante de la extracción hecha por el primer

hilo en la cola circular intermedia, fijando como DTQ máximo el obtenido en dicha

iteración por parte del primer hilo, para que el flujo resultante sea conformante con el

estándar H264/SVC.

Así, en primer lugar se muestra, como se va a tratar por parte del primer hilo el

descartar las unidades NAL en función de los tiempos de recepción, partiendo de que

se conoce previamente el vector de diferencias relativas “n_frames” y el vector de

identificadores temporales “t_id”.

HILO 1{ while(receive_NALU()){ if(temporal_id == 0){ num_frames[DQ] += GOP_size; num_frame = num_frames[DQ]; position = 0; } else if(temporal_id > 0){ position = search_next_temporal_id_position(temporal_id, t_id, position, GOP_size); num_frame = num_frames[DQ] + n_frames[position]; } If((num_frame / fps) < tiempo_recepcion){ discart(); obtain_new_DTQ_th(dependency_id, temporal_id, quality_id, dependency_id_th, temporal_id_th, quality_id_th); } else NAL_UNIT_to_cc(); } }

En el filtrado se distingue entre identificadores temporales iguales a cero y mayores

que cero. Esto se hace porque para el caso de iguales a cero, se va a añadir


exactamente un tamaño de GOP al número de fotogramas, mientras que en el caso de

identificadores temporales mayores que cero, se va a obtener la posición en orden de

reproducción a partir del vector que contiene las diferencias relativas en orden de

reproducción. Funciona de forma, que en primer lugar se obtiene la siguiente posición

con ese identificador temporal (método “search_next_temporal_id_position”), para

localizar la posición en que está situada la diferencia relativa, para posteriormente

sumarla al número de fotograma absoluto.

A continuación, se muestra el método “search_next_temporal_id_position”:

El funcionamiento, es tal que todas las unidades NAL en que el tiempo de recepción

sea mayor que el tiempo de reproducciónvan a ser filtradas. Para conseguirlo se usa el

método “search_next_temporal_id_position” que se muestra a continuación.

Int search_next_temporal_id_position(cons tint temporal_id, cons tint* t_id, cons tint initial_position, cons tint GOP_size) { for(int i=initial_position; i<GOP_size; i++){ if(t_id[i] == temporal_id) return i; } }

Así, una vez obtenida la posición absoluta en orden de reproducción, todas las

unidades NAL en que su tiempo de recepción sea mayor que el tiempo de

reproducción van a ser filtradas. En cambio, siempre que se llegue a tiempo para la

correcta reproducción las unidades NAL son almacenadas en la cola circular intermedia

(objeto de la clase H264BitStream).

En el caso, en que se filtra además de descartar la unidad NAL, se va a redefinir la capa

máxima a la que se podrá filtrar para que el segundo hilo, usando este dato pueda

filtrar el flujo entero de una iteración según el DTQ_th resultante de dicha iteración.

5.2.3. Solución de semáforos de la aplicación:

Finalmente, la aplicación constara de dos hilos, tal y como se ha descrito

anteriormente. De esta forma las variables compartidas serán el objeto de la clase

H264BitStream y el valor máximo de la extracción. El pseudocódigo correspondiente a

cada uno de los dos hilos en los que se deberá definir una solución de control de

acceso mediante semáforos es el siguiente.

HILO 1{


while(!end_of_execution){ receive_1_iter_filter_and_modify_DTQ_th(); modify_DTQ_th2(dependency_id_th, temporal_id_th, quality_id_th); } } HILO2{ while(!end_of_execution){ obtain_DTQ_th2(dependency_id_th, temporal_id_th, quality_id_th); filter_1_iter_and_send_to_play(); } }

Como se había comentado antes, el primer hilo se encarga de llevar a cabo el filtrado

de unidades NAL según los tiempos de recepción y la actualización en cada iteración

del DTQ_th. El segundo hilo, se encarga de filtrar al DTQ_th obtenido por el primer hilo

y enviar a reproducir el video.

En esta solución se implementa de forma que cada hilo tiene su valor de DTQ_th, y la

aplicación comparte las variables globales DTQ_th2. En los accesos a los métodos de

actualización y modificación de dicha variable, se define control de acceso mediante

semáforos, para evitar situaciones conflictivas en tiempo de ejecución.

En cada uno de los métodos se accede en primer lugar mediante el semáforo principal

de la aplicación que es el correspondiente a la cola circular intermedia, de igual forma

que se hacía en el transmisor. Una vez introducido el control de acceso, los métodos

quedan de la forma siguiente.

void_modify_DTQ_th2(const int dependency_id_th, const int temporal_id_th, const int quality_id_th, sem_t* s1, sem_t* s3) { sem_wait(s1); if(actualized){ nw_sem3 ++; sem_post(s1); sem_wait(s3); sem_wait(s1); } actualized = true; dependency_id_th2 = dependency_id_th; temporal_id_th2 = temporal_id_th; quality_id_th2 = quality_id_th; if(nw_sem3 > 0)


sem_post(s3); sem_post(s1); }

void obtain_DTQ_th2(int dependency_id_th, int temporal_id_th, int quality_id_th) { sem_wait(s1); if(!actualized){ nw_sem3 ++; sem_post(s1); sem_wait(s3); sem_wait(s1); } actualized = false; dependency_id_th = dependency_id_th2; temporal_id_th = temporal_id_th2; quality_id_th = quality_id_th2; if(nw_sem3 > 0) sem_post(s3); sem_post(s1); }

La solución propuesta, usa la variable “actualized” como método de control de acceso,

variable que sólo se modifica dentro de los métodos y siempre en exclusión mutua. La

variable indica si se ha actualizado el DTQ_th. De esta forma, se quedara detenido en

el segundo hilo cuando su valor sea falso, porque indicara que no ha sido actualizado, y

en primer hilo cuando sea cierto. Así, en el primer hilo lo actualiza a cierto y en el

segundo lo actualiza a falso. El funcionamiento de los semáforos es el mismo, se entra

a zona crítica y en caso que deba detenerse lo hace en el segundo semáforo. Al salir de

los métodos se da recursos para el semáforo detenido, en caso que haya algún hilo

detenido y en espera.

Esta solución permite que la ejecución sea concurrente entre los dos hilos con un

máximo de una iteración de diferencia entre actualizaciones de DTQ_th2 y con un

máximo de dos iteraciones entre los dos hilos, aunque el primero quedándose

detenido en el semáforo de espera. Además, no hay ninguna interacción que haga que

los dos hilos se queden parados y entre ellos se van abriendo la puerta en los casos de

detención de uno de ellos con lo que se considera una buena solución.


Capítulo 6:

Evaluación del sistema:

Para la evaluación del sistema se ha elegido la secuencia de video BigBuckBunny con

una duración de 9 minutos y 56 segundos. En concreto se va a hacer una codificación

de tres capas con resoluciones de 640x360 en la capa superior y su versión diezmada

de 360x180 en la capa base y en la capa de mejora de calidad, con una velocidad de

reproducción de 24 fotogramas por segundo cada una de ellas.

Se verán a continuación la elección de las principales características de codificación.

6.1. Características de la codificación:

En JSVM se utilizan unos ficheros de codificación en los que se especifica diferentes

atributos de codificación. En concreto, se eligen el número de capas, el tamaño de

GOP, el periodo de intra-predicción, que indica cada cuantos fotogramas aparece una

tira I, el periodo IDR, que indica cada cuantos fotogramas aparece una tira de IDR, la

capa base a partir de la que se predice entre capas, …

Sin embargo, el parámetro más importante que se elige es el parámetro de

cuantificación, que será el principal determinante de la PSNR obtenida. Se puede

demostrar que una PSNR de 40 dB proporciona una secuencia decodificable

visualmente aceptable para el ojo humano.

En primer lugar vamos a centrarnos en la elección de la estructura diádica. Se elige un

tamaño de GOP igual a 2 y un periodo de intra-predicción igual a 4, para cada una de

las tres capas. La elección ha sido tomada porque cuanto mayor es el tamaño de GOP,

cuando hay cambios repentinos de escena, se va a bi-predecir de fotogramas que no se

van a parecer en nada. Es por esto que se eligen valores pequeños que permitan

obtener una secuencia reconstruida con mejor PSNR. Esta combinación da lugar a la

secuencia de tiras en orden de reproducción siguiente:

IBPBIBP…

En cuanto a la elección del periodo de tiras de instante de refresco instantáneo, se ha

optado por un periodo de 16 tiras, de forma que cada cuatro tiras I una de ellas sea de

decodificación instantánea. La elección ha sido tomada para que los errores

propagados, sean reseteados cada un número razonable de tiras.

De esta forma la codificación da lugar a una secuencia de video codificado con seis

capas de extracción posible, dos capas de escalabilidad temporal por cada una de las

tres capas principales, de forma que habrán seis resultados posibles al aplicar el

algoritmo de filtrado.


En cuanto a la capa de la que predicen, se ha optado por hacer predecir tanto la capa

de resolución superior como la de mejora de la capa base. La elección de la capa base

en el caso de la capa de mejora de resolución, ha sido tomada porque con el algoritmo

de filtrado se consigue una mejor relación PSNR a ancho de banda de transmisión, ya

que se filtrara la capa de mejora de calidad al filtrar hasta la capa superior.

6.1.1. Elección de los parámetros de cuantificación:

Para la elección de los parámetros de cuantificación se ha tenido en cuenta la PSNR de

la secuencia reconstruida. De esta forma buscando unas PSNR similares a 40 dB se han

obtenido los siguientes parámetros de cuantificación:

D Q T QP

0 0 0 32

0 0 1 33

0 1 0 25

0 1 1 26

1 0 0 27

1 0 1 28

Tabla 6.1: Parámetros de cuantificación

Como se puede observar, se han elegido los parámetros de cuantificación de 32, 25 y

27 para cada una de las tres capas. En cuanto a las capas temporales superiores se ha

utilizado el mismo parámetro de cuantificación más uno.

Por último, en las componentes de crominancia, se les ha aplicado una rectificación de

más dos en el parámetro de cuantificación debido a la naturaleza del ojo humano a

reconocer con más precisión la componente de luminancia.

Se considera una buena elección de los parámetros de cuantificación porque se

obtienen las siguientes PSNR en la secuencia reconstruida:

CAPA PSNR (Y) PSNR (Cr) PSNR (Cv)

0 36.2303 dB 42.9990 dB 41.7011 dB

1 41.0125 dB 45.2626 dB 44.4091 dB

2 41.2202 dB 45.8067 dB 45.1039 dB

Tabla 6.2: PSNR obtenidas

Como se puede ver se consiguen PSNR superiores a los 40 dB en todos los casos

menos en la capa base que es de 36 dB. Se considera aceptable, por el hecho de que

existe una capa de mejora de PSNR para esta capa.

6.2. Resultados al aplicar el algoritmo de filtrado:


A continuación, se muestran los flujos de datos resultantes una vez aplicado el

algoritmo de filtrado, donde se pueden observar las capas incluidas en cada extracción,

tal y como se ha explicado en el ejemplo del capítulo 3:

Hasta capa 000:

Figura 6.1: Algoritmo extracción hasta la capa 000

Hasta 001:


Hasta 100:


Hasta 010:



Hasta 011:


Hasta 110:


6.3. Perfiles de ancho de banda de transmisión:

A continuación, se verán los perfiles de ancho de banda de transmisión de las

diferentes extracciones posibles, es decir con cada una de las diferentes

combinaciones de identificadores de dependencia.

Lo que se muestra en las figuras es el ancho de banda necesario para transmitir hasta

una determinada capa a través del tiempo. El resultado ha sido obtenido a través de la

estimación de ancho de banda en tiempo real. Por lo tanto, se verá para cada capa cual

sería la velocidad de transmisión necesaria para transmitir hasta esa capa en cada

instante temporal de la duración del video.

Hasta capa 000:


Figura 6.7: Perfil de ancho de banda: Capa 000

Hasta capa 010:


Hasta capa 001:



Hasta capa 011:


Hasta capa 100:



Hasta capa 110:


Como era de esperar, las capas superiores necesitan un ancho de banda mayor que las

inferiores. Vamos a ver a continuación los anchos de banda de transmisión medios, así

como sus desviaciones típicas para poder valorar objetivamente la variación del video

a través del tiempo, aunque ya podemos ver en las gráficas que se trata de una

secuencia de video que contiene escenas con mucho y con poco movimiento porque

las desviaciones típicas serán de un valor considerablemente grande.

Capa Ancho de banda medio Desviación típica (Kbit/s)


(Kbit/s)

000 202,87 100,13

010 298,86 184,88

001 533,16 237,12

011 576,51 278,39

100 1195,90 743,28

110 1294,00 846,80

Tabla 6.3: Medias y desviaciones típicas del ancho de banda de transmisión

Como se puede ver en la tabla 6.3, se obtienen unas desviaciones típicas desde el 45

por ciento al 66 por ciento. Esto indica que la variabilidad del video es grande, es decir,

que existen escenas con poco y con mucho movimiento, lo que provoca que el tamaño

del video codificado sea tan variante.

A parte, las medias obtenidas de aproximadamente 300 Kbit/s, 600 Kbit/s y 1,3 Mbit/s

para cada una de las tres capas principales, se consideran un buen ejemplo de las

capacidades del estándar H264/SVC, ya que para el objetivo del presente proyecto que

es la transmisión de la secuencia de video, permiten una estrategia que divida las

capas de forma clara y concisa.

6.4. Puesta en escena:

El último apartado del capítulo 6, será la puesta en escena del sistema de

comunicaciones diseñado en un escenario real. Se va a emular una red con un

transmisor (“sender”), dos routers intermedios (“routerA” y “routerB”) y un

destinatario (“sink”) usando la herramienta de emulación “Simtools”. A parte, el

dispositivo “host” tendrá acceso a las tres interfaces de red generadas. El esquema de

red es el siguiente:

Figura 6.13: Escenario de red para las pruebas


En el primer router se configura el ancho de banda máximo que puede aceptar la

transmisión, así como su RTT. En cambio, en el segundo router se configura el tamaño

máximo de la cola de espera y su retardo de transmisión, obteniendo el ancho de

banda disponible como el producto del tamaño de la cola por dos veces el retardo

introducido, que se corresponde con tamaño de la cola por RTT.

Las pruebas de red que se van a realizar son las cinco siguientes:

1. Transmisión de la secuencia BigBuckBunny con una limitación de ancho de

banda que permita extraer hasta la capa base, es decir un ancho de banda

disponible de 300 Kbit/s.


banda que permita extraer hasta la capa de mejora de calidad, es decir un

ancho de banda disponible de 600 Kbit/s.


banda que permita extraer hasta la capa de mejora de resolución, es decir un

ancho de banda disponible de 1,3 Mbit/s.


banda variable. La elección tomada es de 1,3 Mbit/s durante los primeros 200

segundos, 600 Kbit/s durante los siguientes 200 segundos y 1,3 Mbit/s hasta el

final.

5. Transmisión simultánea de dos flujos de datos, por un lado la secuencia

BigBuckBunny, y por otro lado una secuencia de video codificada según

H264/SVC. Se va a utilizar una limitación de ancho de banda de 1,3 Mbit/s, y el

objetivo de esta prueba será observar cómo se adapta la transmisión en un

entorno en el que se comparte el ancho de banda.

Para poder realizar las pruebas, se debe configurar en primer lugar el dispositivo

“host” para recepción de flujo en la tercera interfaz, ya que las transmisiones van a ser

realizadas por parte del dispositivo “sender” y recibidas por parte del “host” en dicha

interfaz. Se muestra a continuación, los comandos de configuración que se ejecutan en

el “host”:

host$ifconfig tap0 0

host$ifconfig tap2 172.16.5.2/24

host$route add -net 192.168.1.0/24 gw 172.16.5.1

De esta forma, queda configurado el dispositivo “host” con una dirección IP de la

tercera interfaz de red, y como pasarela para llegar a la primera interfaz se utiliza el

“routerB”.


Para la prueba cinco, se va a transmitir simultáneamente hacia el “host” (secuencia

BigBuckBunny), y hacia el “sink” (secuencia H264/AVC).

6.4.1. Prueba 1 - Ancho de banda límite de 300 Kbit/s:

Se configura el primer router con un ancho de banda límite de 300 Kbit/s para obtener

un perfil de transmisión que se adecue a la transmisión de la capa base. Viendo el

perfil de las capas 000 y 010 ya se puede observar que la variabilidad en tamaño del

video puede que provoque que no haya suficiente ancho de banda para poder

transmitir en la capa base durante todo el tiempo.

A continuación se muestra el flujo transmitido capturado con la herramienta de red

“Wireshark”:

Figura 6.14: Flujo transmitido: Prueba 300 Kbit/s

Como se puede observar la transmisión se detiene a los 220 segundos. Esto se debe al

hecho que no puede asumir en tiempo real la transmisión del flujo de datos, lo que

provoca que “mplayer” se congele y no se consiga el objetivo de poder reproducir la

secuencia en tiempo real.

A continuación, vemos el perfil generado de transmisión a partir de los valores

estimados de ancho de banda por parte del “socket” y la figura correspondiente al

intercambio entre capas realizado durante los 220 segundos de transmisión.


Figura 6.15: Perfil de transmisión según opciones del socket: Prueba 300 Kbit/s

Leyenda

Valor Capa

1 000

2 010

3 001

4 011

5 100

6 110


Figura 6.16: Intercambio entre capas: Prueba 300 Kbit/s

La diferencia de duración entre la simulación y las otras dos figuras se debe a los

instantes temporales en que se transmite con una capa con identificador temporal

menor al máximo, ya que en estos casos se reduce la duración del video. Esta

diferencia podría deberse al hecho que siempre se transmite con un ancho de banda

menor al disponible y por lo tanto las transmisiones se avanzan al instante de

reproducción. Sin embargo, este no es el caso, porque si se debiera a esta segunda

razón el video no se detendría.

Como puede verse en la figura 6.16, la mayor parte del tiempo se transmite hasta las

capas 000 y 010, por lo que se obtiene el resultado esperado para la prueba realizada.

Sin embargo, como no puede llegar a transmitir todo el flujo, se llega a la conclusión

que será necesario introducir un buffer de entrada en recepción que cargue parte del

video antes de empezar a reproducir, porque en caso contrario la reproducción se

detiene.

Se ha repetido la prueba introduciendo el uso del buffer, y se ha obtenido el flujo de

transmisión siguiente:



Como puede esperarse se obtiene un flujo aproximado de 300 Kbit/s durante toda la

transmisión. La duración de 515 segundos queda justificada porque como se verá

durante gran parte de la transmisión se extrae hasta la capa 000, razón por la que se

reduce la duración del video.

El buffer intermedio que se ha elegido en este caso es de 3 Mbyte, de forma que antes

de empezar a transmitir se ponen 3 Mbyte en el buffer, haciendo que se inicie

aproximadamente un minuto después de empezar a transmitir. Esto nos indica que la

duración del video es de 465 segundos, por lo que se deduce, que aproximadamente el

25 % del tiempo se transmite con identificador temporal menor al máximo.

A continuación, se muestran las figuras correspondientes al perfil generado por las

estimaciones del “socket” y el intercambio entre capas realizado en la transmisión.




Como puede observarse la mayor parte del tiempo se transmite hasta las capas 000 y

010.

6.4.2. Prueba 2 - Ancho de banda límite de 600 Kbit/s:

La segunda prueba realizada, está orientada a la reproducción de la secuencia de video

hasta la capa de mejora de PSNR, razón por la que se limita la transmisión a 600 Kbit/s.

En esta, y en las siguientes pruebas se ha decidido poner otra limitación al ancho de

banda para quede limitado por la velocidad de reproducción del video, aparte de por


el propio ancho de banda disponible. Para conseguirlo, se ha utilizado la opción “-

nocache” en el reproductor multimedia, para que no utilice un buffer interno de

almacenamiento. La razón de esta elección, es para evitar que la duración de la

transmisión sea mucho más reducida que la duración del video.

Se considera una buena estrategia, porque existe suficiente ancho de banda disponible

para poder reproducir como mínimo la capa base en tiempo real y se evita así que se

avance demasiado la transmisión. Esta estrategia se convierte en una limitación

porque la cola de espera hasta nivel de aplicación será la ventana de control de flujo

de TCP, y habrá instantes en que esta quedara bacía, y por lo tanto limitara las

transmisiones.

A continuación, se muestra el flujo transmitido de la segunda prueba capturado con

“Wireshark”:



Como puede observarse se consigue un flujo de duración de 530 segundos. La razón

por la que termina antes es los instantes temporales en que se transmite con

identificador temporal menor al máximo. Además, como puede observarse, se obtiene

un flujo que en la mayor parte del tiempo está cerca de los 600 Kbit/s tal y como se

esperaba. Las razones por las que hay instantes de tiempo con menor ancho de banda

son el hecho de no utilizar buffer interno en el reproductor o situaciones de

congestión.

A continuación, se muestran las figuras correspondientes al perfil generado de flujo

máximo que se puede transmitir según las estimaciones obtenidas del “socket” y el

intercambio entre capas realizado en la transmisión:



Figura 6.22: Intercambio entre capas: Prueba

Como puede observarse en el perfil el ancho de banda medio disponible es

aproximadamente de 600 Kbit/s, tal y como se esperaba. Los casos en que este

disminuye significativamente son casos de perdida de paquetes, razón por la que se

activa el control de congestión. Como se ha podido ver en la reproducción de la

secuencia el sistema a 600 Kbit/s se adapta correctamente a las fases de inicio y de

control de congestión.


A parte, como puede observarse en la figura 6.22, la mayor parte del tiempo se

transmite hasta las capas 000, 010, 001 y 011, lo cual se corresponde con al ancho de

banda necesario para transmitir dichas capas.

6.4.3. Prueba 3 - Ancho de banda límite de 1,3 Mbit/s:

La tercera prueba tiene como objetivo la transmisión del flujo a la máxima resolución

durante la mayor parte del tiempo, ya que como se ha visto en los perfiles de

transmisión de las capas la variabilidad en los tamaños hace que no pueda ser

transmitido a la máxima capa durante todo el tiempo.

A continuación, se muestra el flujo transmitido en esta prueba (capturado con

“Wireshark”):


Figura 6.23: Flujo transmitido: Prueba 1,3 Mbit/s

Como puede observarse se consigue un flujo de duración de 560 segundos. La razón

por la que termina antes es la misma que en la segunda prueba, ya que no se utiliza

buffer en el reproductor. Además, como puede observarse, se obtiene un flujo que en

la mayor parte del tiempo está cerca de los 1,3 Mbit/s tal y como se esperaba. Se

detectan casos con pérdida de paquetes como a los 460 segundos, pero al seguir

reproduciendo a tiempo real se observa que el sistema se adapta bien a los errores

debido al hecho que siempre transmite por debajo del ancho de banda disponible.

A continuación, se muestran las figuras correspondientes al perfil generado de flujo

máximo que se puede transmitir según las estimaciones obtenidas del “socket” y el

intercambio entre capas realizado en la transmisión:


Figura 6.24: Perfil de transmisión según opciones del socket: Prueba 1,3 Mbit/s


En la figura 6.25, se observan varias situaciones con pérdida de paquetes, pero como

puede observarse el sistema reacciona a gran velocidad a la bajada de ancho de banda

disponible. Sin embargo, es importante darse cuenta que se deben a pérdidas de la

propia transmisión, razón por la que se recupera con gran velocidad, y en ninguno de

los tres casos analizados hasta ahora ha habido ancho de banda compartido con otras

transmisiones, caso que se verá en la prueba cinco.

A parte, como puede observarse en la figura 6.25, la transmisión ha estado

principalmente concentrada en las capas 100 y 110, tal y como se esperaba.

6.4.4. Prueba 4 - Ancho de banda variable de 1,3 Mbit/s y 600 Kbit/s:


Esta prueba, será evaluado con ancho de banda variable, los primeros 200 segundos se

dispondrá de 1,3 Mbit/s, los siguientes 200 segundos de 600 Kbit/s y hasta el final de la

secuencia 1,3 Mbit/s.

A continuación, se puede ver la figura correspondiente al flujo transmitido capturada

con “Wireshark”:


Figura 6.26: Flujo transmitido: Prueba 1300-600-1300 Kbit/s

Como se puede observar, se obtiene el perfil deseado de 1,3 Mbit/s, 600 Kbit/s y 1,3

Mbit/s con intercambios de flujo en los instantes indicados. Se obtiene una duración

de 540 segundos, como en los anteriores casos debido al acortamiento del video al

filtrar con identificadores temporales menores que el máximo.

A continuación, se muestran las figuras correspondientes al perfil de transmisión según

las estimaciones realizadas por el “socket” y el intercambio entre capas realizado en la

transmisión:

Figura 6.27: Perfil de transmisión según opciones del socket: Prueba 1300-600-1300

Kbit/s


Figura 6.28: Intercambio entre capas: Prueba 1300-600-1300 Kbit/s

Como puede observarse en la figura 6.28, se extrae mayormente a las capas 100 y 110

cuando el ancho de banda disponible es de 1,3 Mbit/s, y a las capas 000, 010, 001 y

011 cuando el ancho de banda disponible es de 600 Kbit/s.

6.4.5. Prueba 5 - Ancho de banda de 1,3 Mbit/s compartido:

En esta prueba, se han realizado dos transmisiones simultáneas desde el dispositivo

“sender”, una dirigida al dispositivo “host” con la secuencia codificada según

H264/SVC, y la otra dirigida al dispositivo “sink” con una secuencia codificada según

H264/AVC. El objetivo de esta prueba es observar cómo se reparte el ancho de banda

disponible (1,3 Mbit/s) entre las dos transmisión. Es una prueba más similar a los

entornos reales en que simultáneamente se comparte el ancho de banda con otras

aplicaciones.

En esta prueba, se ha prescindido de mostrar el flujo capturado con “Wireshark”

porque es el agregado por las dos transmisiones y se va a trabajar con el perfil de

transmisión obtenido a través de las estimaciones por parte del “socket”. A

continuación, se muestran las figuras correspondientes al perfil de transmisión y al

intercambio entre capas de esta prueba:


Figura 6.29: Perfil de transmisión según opciones del socket: Prueba 1,3 Mbit/s

compartido

Figura 6.30: Intercambio entre capas: 1,3 Mbit/s compartido

Como puede observase en la figura 6.29, se obtiene un ancho de banda disponible de

entre 300 y 900 Kbit/s, lo que nos indica que ambos flujos luchan por el ancho de

banda disponible durante todo el tiempo repartiéndoselo entre ambos.

Es importante darse cuenta de que existen situaciones con pérdidas en la transmisión

como se puede observar, y el sistema es capaz de restablecerse incluso en el caso de

flujo compartido con otras transmisiones, lo que indica una cierta robustez a las

situaciones de “congestion avoidance” por parte del sistema desarrollado. Sin,

embargo, es igual de importante percatarse que habrán situaciones de congestión

límite para todos los caos que harán que la transmisión se detenga debido a las

colisiones.


Por último, debido al flujo disponible, principalmente se extrae a las capas 000, 010,

001 y 011.


Capítulo 7:

Conclusiones:

Después de analizar la evaluación del sistema se llega a las conclusiones siguientes:

1. El algoritmo de filtrado desarrollado da lugar a flujos de datos conformantes

con el estándar H264/SVC.

2. Los resultados de aplicar las estrategias de filtrado adaptativo planteadas

aunque no dan lugar a flujos de datos conformantes estrictamente hablando,

son reproducibles por parte de “OpenSVCDecoder”, con cambios de resolución,

calidad y velocidad apreciables a simple vista. Por lo que se puede considerar

los flujos resultantes como conformantes con H264/SVC.

3. Las pruebas de red sin compartir el ancho de banda disponible reaccionan

correctamente a las pérdidas de paquetes permitiendo reproducir la secuencia

de video en tiempo real, siempre que se disponga del ancho de banda

necesario para transmitir como mínimo hasta la capa base.

4. En los casos en que no se dispone del ancho de banda necesario para transmitir

hasta la capa base, el uso de un buffer que almacene parte del flujo antes de

reproducir garantiza la correcta reproducción del video, con el retardo

introducido por el buffer. Cuanto menor sea el ancho de banda disponible, más

retardo se deberá introducir.

5. Las pruebas de red compartiendo el ancho de banda disponible reaccionan

correctamente a las pérdidas de paquetes permitiendo reproducir la secuencia

de video en tiempo real, siempre que se disponga de “n” veces” el ancho de

banda necesario para transmitir como mínimo hasta la capa base, donde “n” es

el número de transmisiones simultáneas, ya que tienden a repartirse el ancho

de banda a partes iguales, a menos que se definan los anchos de banda limite

por aplicación.

6. Obviamente, con situaciones de alta congestión, las transmisiones a tiempo

real no serán posible debido a las colisiones.

7. El sistema desarrollado es una alternativa real a los sistemas de video bajo

demanda existentes siempre que se disponga de una conexión de banda ancha.

7.1. Líneas futuras:

Existen muchas mejoras que se podrían llevar a cabo para mejorar el sistema

desarrollado. A continuación, se muestran tanto posibles mejoras para el sistema

como proyectos futuros continuación del presente proyecto:


1. Desarrollar el receptor orientado a aplicaciones a tiempo real, diseñado en el

apartado 2 del capítulo 5.

2. Desarrollar un codificador H264/SVC a tiempo real, lo cual sería condición

necesaria para poder desarrollar sistemas de videoconferencia que trabajaran

con el estándar H264/SVC, ya que actualmente con “JSVM” las codificaciones

no son a tiempo real.

3. Modificar “OpenSVCDecoder” para que detecte cuando se transmite con

identificador temporal menor que el máximo, y conseguir que adapte la

velocidad de reproducción.

4. Desarrollar “plugins” para los principales navegadores web que permitan

incorporar el códec H264/SVC para poder reproducir las secuencias H264/SVC

en el navegador web.

5. Incorporar el sistema de comunicaciones trabajando sobre HTTP, ya sea en

forma de aplicación programada con PHP, o con “servlets” de JAVA, o

incluyéndolo de forma nativa en el estándar HTML5.


APÉNDICES


Apéndice A:

Ficheros de configuración del codificador de JSVM

utilizados en las simulaciones:

Los siguientes ficheros han sido utilizados para la configuración de la codificación

hecha en la secuencia de video “BigBuckBunny”. Concretamente, se han codificado dos

capas de escalabilidad temporal para cada una de las capas, siendo las capas: capa

base, capa de calidad mejorada (ambas con resolución 320x180) y capa de resolución

superior a 640x320.

El archivo principal, “confSVC.cfg” es el siguiente:

# JSVM Main Configuration File

#========================GENERAL================================

OutputFile stream.264 # Bitstream file

FrameRate 24.0 # Maximum frame rate [Hz]

FramesToBeEncoded 14000 # Number of frames (at input

frame rate)

NonRequiredEnable 0 # NonRequiredSEI enable

(0:disable, 1:enable)

CgsSnrRefinement 1 # SNR refinement as 1: MGS; 0:

CGS

EncodeKeyPictures 1 # Key pics at T=0 (0:none,

1:MGS, 2:all)

MGSControl 1 # ME/MC for non-key pictures in

MGS layers

# (0:std, 1:ME with EL, 2:ME+MC

with EL)

#===================== CODING STRUCTURE ========================

GOPSize 2 # GOP Size (at maximum frame

rate)

IntraPeriod 4 # Intra Period

NumberReferenceFrames 1 # Number of reference pictures

BaseLayerMode 0 #Base layer mode (0,1: AVC

compatible, 2: AVC w subseq SEI)

ConstrainedIntraUps 0 # constrained intra upsampling

#======================= MOTION SEARCH =========================

SearchMode 4 # Search mode (0:BlockSearch,

4:FastSearch)

SearchFuncFullPel 3 # Search function full pel

# (0:SAD, 1:SSE, 2:HADAMARD,

3:SAD-YUV)

SearchFuncSubPel 2 # Search function sub pel

# (0:SAD, 1:SSE, 2:HADAMARD)

SearchRange 32 # Search range (Full Pel)

ELSearchRange 4 # Enh. layer search range

FastBiSearch 1 # Fast bi-directional search

(0:off, 1:on)


BiPredIter 4 # Max iterations for bi-pred

search

IterSearchRange 8 # Search range for iterations

(0: normal)

#========?================ LOOP FILTER =========================

LoopFilterDisable 0 # Loop filter idc (0: on, 1:

off, 2: on except for slice boundarieS, 3: Se aplica 2 etapas de

filtrado (limite bloques y limite tiras)

# 4: Luma on but Chroma off in

enh. layer # (w.r.t. idc=0)

# 5: Luma on except on slice

boundaries but Chroma off in enh. layer # (w.r.t. idc=2)

# 6: Como 3 en las muestras

luma y sin filtrado croma # Loop filter idc (0: on,

1: off, 2:

# on except for slice

boundaries,

# 3: Luma on but Chroma off in

enh. layer # (w.r.t. idc=0)

# 4: Luma on except on slice

boundaries.

# but Chroma off in enh. layer

# (w.r.t. idc=2)

LoopFilterAlphaC0Offset 0 # AlphaOffset(-6..+6): valid

range

LoopFilterBetaOffset 0 # BetaOffset (-6..+6): valid

range

InterLayerLoopFilterDisable 0 # filter idc for inter-layer

deblocking

InterLayerLoopFilterBetaOffset 0 # BetaOffset for inter-layer

deblocking

#======================= LAYER DEFINITION ======================

NumLayers 3 # Number of layers

LayerCfg confSVC_layer0.cfg # Layer configuration file



#====================== WEIGHTED PREDICTION ====================

WeightedPrediction 0 # Weighting IP Slice

(0:disable, 1:enable)

WeightedBiprediction 1 # Weighting B Slice (0:disable,

1:explicit,

# 2:implicit)

#===================== LOSS-AWARE RDO ==========================

LARDO 0 # Loss-aware RDO (0:disable,

1:enable)

#========================= HRD =================================

EnableVclHRD 0 # Type I HRD (default 0:Off,

1:on)

EnableNalHRD 0 # Type II HRD (default 0:Off,

1:on)

#======================= RATE CONTROL ==========================

RateControlEnable 0 # Enable base-layer rate

control (0=off, 1=on)

#====================== FRAME-COMPATIBLE =======================

MuxMethod 0 # Enable 3D mux method (0:

none, 1: SbS, 2: TaB)


MuxFilter 15 # 3D Muxing/DOwnsampling Filter

# 0: decimate,

# 1: average

# 2: [-1 2 6 2 -1]/8

# 3: [-1 2 -1]

# 4: [-1 4 26 4 -1]/32

# 5: [ 1 -2 5 56 5 -2 1]/64

# 6: HF1

# 7: HF0

# 8: SVC

# 9: CDF9

# 10: CDF7

# 11: "1024"•

# 12: low-pass (fractional-pixel

offset)

# 13: JVT-R006 (fractional-pixel

offset)

# 14: JVT-R070 (fractional-pixel

offset)

# 15: SVC (fractional-pixel offset)

# 16: HF0 (fractional-pixel offset)

MuxOffset0 1 # offset for input to layer 0

(view 0)

MuxOffset1 1 # is not zero; offset for

Layer1;

Los archivos de configuración de las tres capas son los siguientes. A continuación se

muestra “confSVC_layer0.cfg”:

# JSVM Layer Configuration File

#=========================== INPUT ============================

SourceWidth 320 # Input frame width

SourceHeight 180 # Input frame height

FrameRateIn 24 # Input frame rate [Hz]

FrameRateOut 24 # Output frame rate [Hz]

InputFile BigBuckBunny_320x180@24_000-000s.yuv

# Input file

SymbolMode 0 # 0=CAVLC, 1=CABAC

IDRPeriod 16 # IDR period (should be (GOP

size)*N)

IntraPeriod 4 # Intra period (should be (GOP

size)*N)

#=========================== CODING ===========================

ProfileIdc 77 # value of profile_idc (or 0

for auto detection)

MinLevelIdc 10 # minimum level (level_idc * 10

)

CbQPIndexOffset 2 # QP index offset for the Cb

component

CrQPIndexOffset 2 # QP index offset for the Cr


component

MaxDeltaQP 1 # Max. absolute delta QP

QP 32.0 # Quantization parameters

#========================= CONTROL ============================

InterLayerPred 0 # Inter-layer Pred. (0:no,

1:yes, 2:adap.)

ILModePred 0 # Inter-layer mode pred. (0:no,

1:yes, 2:adap.)

ILMotionPred 0 # Inter-layer motion pred.

(0:no, 1:yes, 2:adap.)

ILResidualPred 0 # Inter-layer residual pred.


#================ EXTENDED SPATIAL SCALABILITY ================

UseESS 0 # ESS mode

#============================= MGS ============================

MGSVectorMode 0 # MGS vector usage selection

#====================== QP Cascading ==========================

ExplicitQPCascading 1 # QP Cascading (0:auto,

1:explicit)

DQP4TLevel0 0 # Delta QP for temporal level 0


#=================== SVC TO AVC REWRITE =======================

AvcRewriteFlag 0 # Enable SVC to AVC rewrite (0:

no, 1: yes)

El archivo “confSVC_layer1.cfg” es el siguiente:


#==================== INPUT / OUTPUT ==========================






# Input file



size)*N)


size)*N)

#======================== CODING ==============================


for auto detection)


)


component


component




BaseLayerId 0 # Layerd ID for the base layer

#======================== CONTROL =============================


1:yes, 2:adap.)


1:yes, 2:adap.)






UseESS 1 # ESS mode

ESSCropWidth 320 # base layer upsampled frame

width

ESSCropHeight 180 # base layer upsampled frame

height

ESSOriginX 0 # base layer upsampled frame x-

pos

ESSOriginY 0 # base layer upsampled frame y-

pos

#=========================== MGS ==============================


#====================== QP Cascading ==========================


1:explicit)



#=================== SVC TO AVC REWRITE =======================


no, 1: yes)

El archivo “confSVC_layer2.cfg” es el siguiente:


#===================== INPUT / OUTPUT =========================





InputFile [email protected]

# Input file



size)*N)


size)*N)

#========================= CODING =============================


for auto detection)


)



component


component



BaseLayerId 0 # Layerd ID for the base layer

#======================= CONTROL ==============================


1:yes, 2:adap.)


1:yes, 2:adap.)





#=============== EXTENDED SPATIAL SCALABILITY =================

UseESS 1 # ESS mode

ESSCropWidth 640 # base layer upsampled frame

width

ESSCropHeight 360 # base layer upsampled frame

height

ESSOriginX 0 # base layer upsampled frame x-

pos

ESSOriginY 0 # base layer upsampled frame y-

pos

#========================== MGS ===============================


#===================== QP Cascading ===========================


1:explicit)



#================= SVC TO AVC REWRITE =========================


no, 1: yes)


Apéndice B:

Sintaxis H264/SVC:


0


Apéndice C:

Manual de utilidades del proyecto:

C.1. Utilidades de video:

Reproducción de una secuencia YUV en Mplayer:

Una secuencia YUV, es aquella secuencia de video que está representado por las tres

componentes de representación de imagen YUV, es decir, una secuencia de video

decodificada.

La forma de indicarle a Mplayer que se va a reproducir una secuencia YUV es la

siguiente:

mplayer -demuxer rawvideo -rawvideo fps=FPS_IN:w=W_IN:h=H_IN in.yuv

En primer lugar se le indica que el formato de la secuencia de video no está codificado

(“rawvideo”), acto seguido para que Mplayer pueda reproducirlo se le indican la

velocidad de reproducción y su resolución. Mplayer con estos atributos es capaz de

detectar las diferentes combinaciones en número de bits para la representación de

todas sus componentes.

Reproducción de una secuencia codificada con H264:

Mplayer detecta automáticamente cuando se inicia la reproducción de una secuencia

de video codificada con H264, aunque para conseguir una respuesta más rápida por

parte de Mplayer es útil utilizar la extensión “.264”. El único parámetro que se le debe

indicar es la velocidad de reproducción.

Vemos a continuación el comando a ejecutar para reproducir una secuencia H264:

mplayer –fps FPS_IN in.264

Para la reproducción de un archivo codificado con SVC se utiliza exactamente el mismo

comando, y Mplayer ya se encarga de detectar que esta codificado con SVC. Para que

Mplayer detecte las codificaciones de SVC se debe compilar configurando el código

para que utilice este decodificador. Para más información sobre como realizar la

compilación, ver [4].

Descomprimir un fichero codificado:

Vamos a ver a continuación, el comando para obtener un fichero descomprimido en

formato YUV a partir de un fichero de entrada que use una de las siguientes


codificaciones o multiplexores de video y audio: AVI, MP4, H264; MPEG2, MPEG4. La

utilidad utilizada es “ffmpeg” y el comado correspondiente es el siguiente:

ffmpeg -i in.avi -v FPS_IN -s W_INxH_IN –pix-fmt yuv420p out.yuv

Los parámetros que se le indican son el fichero de entrada (“in.avi”), la velocidad de

reproducción de la secuencia de entrada, su resolución (se indica con un carácter “x”

en el medio) y el formato de codificación del archivo no comprimido de la salida. Se

elige por defecto “yuv420p”.

Obtención de versiones sub-muestreadas y sobre-muestreadas de una secuencia

YUV:

Para la obtención de versiones sub-muestreadas y sobre-muestreadas de una

secuencia YUV utilizaremos la utilidad “DownConvertStatic” del paquete de software

JSVM. El comando a utilizar es el siguiente:

DownConvertStatic W_IN H_IN in.yuv W_OUT H_OUT out.yuv NUM_METHOD

En los parámetros se indica las secuencias de entrada y de salida, y sus resoluciones. Es

decir, se indica la resolución del archivo de entrada, y la resolución deseada para el

archivo de salida. Además, se indica el o los filtros que se utilizaran para el sub-

muestreo o el sobre-muestreo, mediante el parámetro “NUM_METHOD. Existen otros

parámetros, para aprender a utilizarlos o ver los distintos tipos de filtrado se

recomienda la lectura de [3]. El resultado de ejecutar esta utilidad será la versión sub o

sobre-muestreada de la entrada utilizando el método indicado.

Codificación de una secuencia H264/SVC:

El siguiente paso lógico, en las funcionalidades sobre utilidades de video, es la

codificación de una secuencia utilizando el estándar H264/SVC. Para codificar con AVC

se cogerá el caso particular de la siguiente explicación, en que solo se incluye una capa.

El proceso de codificación se realiza con la siguiente instrucción:

H264AVCEncoderLibTestStatic –pf confSVC.cfg

Existen muchos parámetros adicionales que se le pueden indicar, pero estos serán

equivalentes a los parámetros que se indicaran en el fichero de configuración. De esta

forma el único parámetro que se pasa es el archivo de configuración, donde se

inicializan todas las variables necesarias para la codificación.

Vemos a continuación las principales variables de codificación. No se van a presentar

todas las posibilidades del codificador “H264AVCEncoderLibTestStatic”. Para obtener

más información se recomienda la lectura de [3].


La codificación consta de varios ficheros de configuración, el principal (“confSVC.cfg”) y

uno por cada capa de las que conste la codificación (“confSVC_layer*i+”). Empezamos

presentando las opciones de configuración más importantes del archivo principal. En

ellas veremos la identificación del flujo de salida, su estructura de codificación, los

métodos utilizados en la búsqueda de muestras realizada en intra e inter-predicción y

la identificación de los ficheros correspondientes a las distintas capas que forman

parte de la codificación.

Empezamos, viendo la identificación del fichero de salida. Los parámetros que deberán

especificarse son los siguientes:

#============================ GENERAL ================================ OutputFile path/stream.264 # Bitstream file FrameRate 24.0 # Maximum frame rate [Hz] FramesToBeEncoded 14000 # Number of frames (at input frame rate)

Especificamos el nombre del fichero de salida, su velocidad de reproducción, y el

número de fotogramas de la secuencia de entrada que van a ser codificados. Como

punto importante, remarcar que para que no haya errores en la codificación el número

de fotogramas a codificar debe ser múltiplo del tamaño de GOP especificado en los

atributos que veremos a continuación.

En segundo lugar, se especifica la estructura de codificación, para conseguirlo

debemos fijar el tamaño de GOP de la secuencia y el periodo entre fotogramas intra-

predecidos. La estructura en SVC se genera siguiendo los principios de funcionamiento

de la estructura diádica, de forma que con el tamaño de GOP determinaremos el

número de tiras B que habrá entre las tiras I y P.

#======================== CODING STRUCTURE =========================== GOPSize 2 # GOP Size (at maximum frame rate) IntraPeriod 4 # Intra Period

Seguimos en tercer lugar viendo las principales opciones en cuanto a los algoritmos de

búsqueda de muestras y el tamaño máximo sobre el que se van a realizar las

búsquedas. Es importante darse cuenta, que la velocidad de la codificación dependerá

bastante de la elección de estos parámetros.

#========================== MOTION SEARCH ============================


SearchMode 4 # Search mode (0:BlockSearch, 4:FastSearch) SearchFuncFullPel 3 # Search function full pel # (0:SAD, 1:SSE, 2:HADAMARD, 3:SAD-YUV) SearchFuncSubPel 2 # Search function sub pel # (0:SAD, 1:SSE, 2:HADAMARD) SearchRange 32 # Search range (Full Pel) ELSearchRange 4 # Enh. layer search range FastBiSearch 1 # Fast bi-directional search (0:off, 1:on) BiPredIter 4 # Max iterations for bi-pred search IterSearchRange 8 # Search range for iterations (0: normal)

Con estos atributos, decidimos si utilizamos búsqueda rápida o por bloques, el tipo de

algoritmo utilizado para búsqueda a nivel de muestra o de sub-muestra, el tamaño

máximo de distancias en las búsquedas, así, como otros atributos más.

Por último, en el archivo de configuración principal, tenemos unos atributos que nos

permiten identificar donde encontrar los archivos de configuración de cada una de las

capas. Habrá una variable por cada capa de las que conste la codificación.

#========================== LAYER DEFINITION =========================== NumLayers 3 # Number of layers LayerCfg confSVC_layer0.cfg # Layer configuration file LayerCfg confSVC_layer1.cfg # Layer configuration file LayerCfg confSVC_layer2.cfg # Layer configuration file

Pasamos a ver a continuación los principales atributos que se deben definir en los

archivos de configuración de cada una de las capas. En concreto veremos la

identificación de la secuencia de entrada en formato YUV, las características de la

estructura, las características de la codificación, si se utiliza predicción entre capas y si

se utiliza escalabilidad de resolución.

En primer lugar vamos a ver, la identificación de la secuencia YUV de entrada, su

resolución y su velocidad de reproducción de entrada. Además podemos fijar el valor

de la velocidad de reproducción de salida, con lo que en caso de que sean valores

distintos aumentaría o disminuiría el número de fotogramas codificados. Esta opción

nos permite por ejemplo fijar una secuencia de entrada a 50 fotogramas por segundo,

y en la capa base solo codificar la mitad de estos fotogramas fijando la velocidad de

salida a 25 fotogramas por segundo.

#==================== INPUT / OUTPUT ==========================







# Input file

Se verá a continuación, los parámetros correspondientes el periodo de tiras intra-

predecidas, que indica para cada capa la periodicidad de las tiras I; y el periodo de tiras

IDR, que nos indicara la periodicidad en instantes de refresco, que seran tiras

decodificables por sí mismas, y como consecuencia instantes en los que se dejaran de

propagar errores.

#======================== CODING STRUCTURE =========================== IDRPeriod 16 # IDR period (should be (GOP size)*N)

IntraPeriod 4 # Intra period (should be (GOP size)*N)

En tercer lugar, se verán los atributos que fijaran si se utilizara predicción entre capas

en la capa actual, y en caso que sea así, a partir de que capa se va a predecir.

#======================== CODING ============================== BaseLayerId 0 # Layerd ID for the base layer

#======================== CONTROL =============================


1:yes, 2:adap.)


1:yes, 2:adap.)





En este caso, decidimos para cada capa de mejora la capa sobre la que se realizaran las

predicciones, normalmente la inferior; aunque existen casos como cuando se utiliza

una capa intermedia con calidad mejorada, en que la capa de resolución superior se

hace predecir sobre la capa base por temas de eficiencia entre tamaños de extracción

utilizando el algoritmo de filtrado y calidad visual obtenida. En el caso de la capa base

este atributo no se utiliza ya que no va a predecir de ninguna capa.

Además, se especifica el tipo de predicciones entre capas que se va a utilizar, pudiendo

elegir un tipo para todas las predicciones entre capas (primer atributo), o un tipo para


cada uno de los tres tipos de predicción entre capas. En las capas superiores se deberá

especificar un valor de 1 o de 2, mientras que en la capa base se elegirá el valor de 0,

ya que no existe predicción entre capas.

Pasamos a ver, los atributos correspondientes al parámetro de cuantificación que

vamos a utilizar. En primer lugar veremos la forma de fijar el parámetro de

cuantificación que vamos a utilizar. Además vamos a ver como fijar parámetros de

cuantificación diferentes en las componentes de crominancia, y en las distintas capas

temporales que se generan.

#======================== CODING ============================== MaxDeltaQP 1 # Max. absolute delta QP


Con estos dos parámetros fijamos el parámetro de cuantificación para la capa, y la

máxima desviación absoluta que se permitirá respecto al valor fijado, en este caso el

parámetro de cuantificación quedaría entre 24 y 26.

#======================== CODING ==============================

CbQPIndexOffset 2 # QP index offset for the Cb component

CrQPIndexOffset 2 # QP index offset for the Cr component

Con estos dos parámetros fijamos la diferencia relativa de cada una de las dos

componentes de crominancia respecto al valor de la capa. Normalmente se utilizara

estos atributos con diferencias positivas ya que el ojo humano es más sensible a la

componente de luminancia, y consecuentemente nos podremos permitir

normalmente el hecho de que no se obtengan unas PSNR tan altas en las componentes

de crominancia.

Para conseguir, diferentes parámetros de cuantificación en las distintas capas

temporales generadas dentro de cada capa utilizamos “QPCascading”, en el que

definimos de la misma forma que antes las diferencias relativas respecto al valor de la

capa, para cada una de las capas de escalabilidad temporal. Es necesario especificar un

valor para cada capa en caso de especificarse su uso.

#======================= QP Cascading =========================

ExplicitQPCascading 1 # QP Cascading (0:auto, 1:explicit)




En quinto lugar, veremos como determinar si vamos a utilizar escalabilidad espacial.

Tendremos un atributo que nos permitirá activar su uso, y deberemos indicar la

resolución de la capa en la que estamos trabajando. Este atributo se deberá activar

tanto cuando estemos utilizando una capa con resolución superior, como cuando

estemos generando una capa de calidad mejorada con el uso de MGS. Se muestran a

continuación estos atributos:


UseESS 1 # ESS mode

ESSCropWidth 320 # base layer upsampled frame width

ESSCropHeight 180 # base layer upsampled frame height

ESSOriginX 0 # base layer upsampled frame x-pos

ESSOriginY 0 # base layer upsampled frame y-pos

En penúltimo lugar se va a explicar cómo se debe hacer para realizar una codificación

usando MGS y generando varias capas de mejora con partición de los coeficientes.

Para ello, disponemos de un atributo que se encarga de permitir activar el uso de MGS

con partición de coeficiente, y posteriormente asignaremos valores para cada capa de

mejora, la suma de los cuales debe ser 8, correspondientes al número de coeficientes

disponibles. Se muestran a continuación estos atributos:

#=========================== MGS ==============================


MGSVector0 4 # Specifies 0th position of the vector

MGSVector1 2 # Specifies 1st position of the vector

MGSVector2 2 # Specifies 2nd position of the vector

Decodificación de una secuencia H264/SVC:

La utilidad para decodificar una secuencia H264, tanto AVC como SVC, es

“H264AVCDecoderLibTestStatic”. Esta utilidad convierte una secuencia codificada

según H264 en una secuencia de video no comprimida en formato YUV. A continuación

se muestra el comando para decodificar, donde sus atributos son la secuencia H264 de

entrada, y el fichero en el que almacenar el flujo decodificado:

H264AVCDecoderLibTestStatic in.264 out.yuv

C.2. Utilidades de compilación:


Compilación con make:

Para realizar la compilación del código que se haya desarrollado utilizaremos el

compilador de GNU: GCC. Veremos a continuación la plantilla de un Makefile que

utilizara este compilador. En concreto, el ejemplo que se propone trabaja con la

utilidad c++, que se corresponde con el compilador del lenguaje de programación c++

del conjunto de compiladores GCC.

Para compilar vamos a utilizar el siguiente comando. Este debe ejecutarse en el

directorio raíz en que se encuentran los archivo de código fuente.

cd project_dir

make

Vemos a continuación el conjunto de instrucciones que forman parte del Makefile:

EXEC := application_name

DIRSRC := src/

DIROBJ := obj/

DIRHDR := include/

CXXFLAGS := -I $(DIRHDR)

OBJS := $(subst $(DIRSRC), $(DIROBJ),$(patsubst %.cpp, %.o,

$(wildcard $(DIRSRC)*.cpp)))

.PHONY: all clean

all: info $EXEC

$(EXEC): $(OBJS)

$(CXX) -o $@ $^

$(DIROBJ) %.o: $(DIRSRC) %.cpp

$(CXX) $(CXXFLAGS) -c $< -o $@

clean:

rm -f *.log $(EXEC) *~ $(DIROBJ)* $(DIRSRC)*~ $(DIRHEA)*~

El Makefile anterior se encarga de realizar la compilación del fichero por etapas. En

primer lugar a partir los ficheros de código fuente obtiene los ficheros objeto

resultantes y los almacena en el directorio “obs/”. Acto seguido, se realiza el proceso

de enlazado para obtener el ejecutable resultante.

Además hemos definido el comportamiento cuando se ejecute “make clean”, para que

elimine todos los ficheros temporales.


El siguiente comando realiza la misma funcionalidad. En él se deben especificar todas

las cabeceras y ficheros de código fuente necesarios para la compilación.

c++ -o application_name hdr1.h … hdrN.h src1.cpp … srcN.cpp

Compilación con KDevelop4:

En el programa KDevelop4, se trabaja con Makefiles que van a ser compilados

utilizando CMake. Para compilar en KDevelop solo es necesario incluir todos los

ficheros en el proyecto y sus nombres, tanto de cabecera como de código fuente en el

archivo “CMakeLists.txt”. Así, es el propio programa el que se encarga de generar los

ficheros de compilación.

En concreto deben ponerse utilizando la siguiente línea de texto:

add_executable(application_name hdr1.h … hdrN.h src1.cpp … srcN.cpp)

C.3. Utilidades desarrolladas en el proyecto:

Obtener los atributos de una secuencia H264/SVC:

La primera utilidad desarrollad, se encarga de mostrar por pantalla los atributos de

cada una de sus unidades NAL. En concreto muestra tipo de unidad NAL, capa a la que

pertenece y en caso de ser una tira codificada, tipo de tira (I, P o B). Además, en todos

los casos muestra el número de unidad NAL, y su tamaño en bytes.

El comando correspondiente es el siguiente:

obtain_NALU_parameters in.264

El único parámetro que tiene es el flujo de entrada.

Filtrado hasta una capa máxima:

La segunda utilidad desarrollada en el proyecto se encarga de obtener una versión

filtrada de la secuencia de video H264/SVC de entrada. De esta forma, eligiendo en la

línea de comandos el DTQ máximo de la extracción obtenemos a la salida otra

secuencia H264/SVC, que es a su vez conformante con el estándar, es decir, la

secuencia resultante será decodificable y reproducible.

El comando correspondiente para esta utilidad es el siguiente:

extract_DTQ in.264 out.264 D_th T_th Q_th

Como se puede observar se fijan los atributos máximos de la extracción, el archivo de

entrada, y el archivo de salida en que será almacenada la versión filtrada.


Extracción con ancho de banda fijo:

Esta utilidad, se encarga de extraer según el algoritmo de filtrado siempre hasta la

capa con ancho de banda necesario para transmitir hasta esa capa máximo pero

menor al disponible, que en este caso será fijo y será uno de los atributos que se le

pasaran al ejecutable.


fixedBW_extraction in.264 out.264 max_BW(KB/s)

Como se puede observar los atributos que se le van a pasar son el archivo de entrada,

el de salida y el ancho de banda disponible. Este ancho de banda limite será

comparado con las estimaciones del ancho de banda necesario para transmitir hasta

cada una de las posibles capas, y servirá para limitar la extracción. Se ve así, que

cuanto mayor sea el ancho de banda disponible, más calidad tendrá la secuencia

extraída.

Extracción con ancho de banda variable:

Este caso, será igual que el anterior pero utilizando intercambios de ancho de banda

disponible a través del tiempo. Para conseguirlo se ha utilizado un fichero auxiliar en el

que se indicaran los diferentes anchos de banda y se pasa como atributo el periodo de

actualización entre cambios de ancho de banda máximo (se indica en segundos).


variableBW_extraction in.264 out.264 BW.txt time(s)

Sus atributos son la secuencia de entrada, el fichero donde almacenar la secuencia de

salida, el fichero auxiliar en el que se almacena un valor de ancho de banda (KB/s) por

línea y el intervalo de actualización.

Este ejecutable funciona de tal forma que cuando transcurre el tiempo indicado, se

actualiza el ancho de banda disponible. Conseguimos así, emular el funcionamiento de

situaciones en que el ancho de banda disponible es variante.

Extracción por red:

Finalmente, se va a explicar el funcionamiento del sistema de transmisión diseñado.

Esta vez al trabajar a través de redes, ha sido necesario definir dos utilidades distintas,

el transmisor se encargara de enviar el flujo de dato filtrado según el ancho de banda

disponible y el receptor de enviarlo al reproductor.

El comando correspondiente a la transmisión del flujo de datos es el siguiente:

network_extraction in.264 @dst_IP dst_PORT


Los parámetros son los correspondientes al fichero de entrada y la identificación del

servidor formada por su dirección IP y su puerto. De esta forma fijamos el destino de la

transmisión y vamos extrayendo hasta la capa con mayor ancho de banda inferior al

disponible, que obtenemos con la estimación de TCP, es decir, tamaño de la ventana

de congestión dividido por el RTT, o con la estimación de tamaños enviados dividido

por el tiempo de ejecución o una combinación entre los dos casos.

Una vez realizadas las pruebas en la puesta en escena del proyecto se ha visto que el

estimador reaccionaba de forma muy agresiva debido a la detección de pérdidas. Por

esta razón se ha desarrollado una última versión en la que se puede elegir el peso de

cada uno de los estimadores. El comando correspondiente es el siguiente:

network_extractor in.264 @dst_IP dst_PORT TCP_est_height(%)

En este caso se indica además el peso que tendrá el estimador de TCP en tanto por

ciento.

La otra utilidad necesaria para el funcionamiento del sistema es un receptor TCP

estándar, que se encargue de almacenar el contenido recibido, o de enviarlo al

reproductor. Es importante darse cuenta que el receptor se deberá ejecutar siempre

antes que el transmisor ya que funcionara como servidor, y en caso de hacerlo en

orden inverso, el transmisor no encontraría el socket escuchando en el puerto y

dirección IP correspondientes.

El comando correspondiente al receptor es el siguiente:

tcp_server @src_IP src_PORT

Se le indica la dirección IP y el puerto en la que realizar la escucha y se envía a la salida

estándar el contenido de video recibido.

Para terminar vamos a ver la utilización de estas comandas y otra adicional (bfr), para

la realización de las pruebas que se han detallado en el capítulo 6.

En primer lugar creamos un fichero FIFO, que utilizaremos como punto intermedio

entre el receptor y el buffer que se encargara de cargar parte del fichero antes de

empezar a reproducirse.

mkfifo fifo_name

En segundo lugar utilizamos el comando bfr para disponer del buffer, que nos va a

permitir precargar parte de la secuencia antes de empezar a reproducir y redirigimos

su salida estándar para ser reproducida con Mplayer.

bfr fifo_name -v -pk1m -m 10% -i 99% --throttle 90% --speedcap 8000K


--buffersize BUFFER_SIZE -o - | mplayer -nocache - 1>/dev/null

En tercer lugar ponemos el receptor en escucha:

tcp_server @src_IP src_PORT

Para finalizar ejecutamos en el origen de la transmisión el comando

“network_extraction”:

network_extraction in.264 @dst_IP dst_PORT

Lo que conseguimos con estas instrucciones es que empiece la transmisión y que se

vaya cargando el video en el buffer intermedio. Entonces cuando ha terminado de

cargar el buffer que le hemos indicado, empezara la reproducción de la secuencia de

video en Mplayer.


Bibliografía:

[1] ITU-T, “H264, advanced video coding for generic audiovisual services”,

2012

[2+ Marc Torrent Vernetta, “Diseño de un sistema de transmisión de video

escalable sobre un sistema de redes P2P”, 2010

[3] ITU-T, “JSVM software manual”, 2011

*4+ Médéric Blestel y Mickaël Raulet, “Open SVC Decoder: a flexible SVC

library”, 2010

[5] Universidad Politécnica de Catalunya. Departamento de telemática.

Jorge Mata *et al.+, “Multimedia communications. TCP Flows Practice”,

2014

Estudio de viabilidad técnica e implementación de un...

Documents

Transcript of Estudio de viabilidad técnica e implementación de un...