ES2399331T3

ES2399331T3 - Método y aparato de procesado de información y soporte de grabación

Info

Publication number: ES2399331T3
Application number: ES05076079T
Authority: ES
Inventors: Motoki Kato; Toshiya Hamada
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2000-04-21
Filing date: 2001-04-20
Publication date: 2013-03-27
Anticipated expiration: 2021-04-20
Also published as: NO20016292L; US7738776B2; JP2012130019A; JP2011166801A; EP2256737A2; CN100348033C; JP2011166800A; JP4919129B2; EP2256738A2; US8670646B2; US20050025461A1; JP4599740B2; KR20020020918A; JP4919130B2; EP2256738A3; AU779673B2; US20020135607A1; RU2005117968A; SK18982001A3; CA2377690A1

Abstract

Aparato de procesado de información (2) para grabar flujos continuos AV en un soporte de grabación (100) comofragmentos, comprendiendo cada fragmento información de fragmento y datos de flujo continuo AVcorrespondientes, estando la información de fragmento y los datos de flujo continuo AV correspondientesalmacenados en archivos respectivos, incluyendo los flujos continuos AV datos de marca de tiempo de presentación,comprendiendo dicho aparato: un controlador (23) que se puede hacer funcionar para generar (a) información de fragmento que incluye unmapa de puntos de entrada que describe la relación entre una marca de tiempo de presentación de una imagen Ique proporciona un punto de entrada a los datos de flujo continuo AV de dicho fragmento, y un número depaquete fuente relativo que representa la dirección de datos de una unidad de acceso para el punto de entradacorrespondiente, siendo contado el número de paquete fuente relativo desde el primer paquete fuente del archivode datos de flujo continuo AV, y (b) una lista de reproducción que incluye información de ruta principal que indicauna ruta principal compuesta por un primer elemento de reproducción AV e información de ruta secundaria queindica una ruta secundaria compuesta por un segundo elemento de reproducción de audio, correspondiendocada elemento de reproducción a un fragmento, e incluyendo dicha información de ruta secundaria una marca detiempo de presentación que indica un tiempo de inicio de presentación, basándose en el eje de tiempo de la rutaprincipal, para iniciar la reproducción de la ruta secundaria de dicho segundo elemento de reproducción, demanera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se puedasincronizar con la reproducción de dicho primer elemento de reproducción sobre la ruta principal; yuna unidad de escritura (22) que se puede hacer funcionar para grabar fragmentos, incluyendo la información defragmento y los datos de flujo continuo AV de fragmento, y la lista de reproducción, incluyendo la información deruta principal y la información de ruta secundaria, en el soporte de grabación.

Description

Método y aparato de procesado de información y soporte de grabación.

Campo técnico

La presente invención se refiere a un método y a un aparato de procesado de información, a un programa y a un soporte de grabación. Más particularmente, se refiere a un método y a un aparato de procesado de información, a un programa y a un soporte de grabación para grabar un archivo que incluye la información indicada para la explicación en la GUI, la información sobre la ruta de reproducción principal, la información sobre la ruta de reproducción secundaria, información de conexión entre dominios de reproducción respectivos que constituyen la ruta de reproducción principal, o la información sobre marcadores o puntos de reanudación útiles para que el usuario fije una escena deseada.

Antecedentes de la técnica

Recientemente, se han propuesto varios tipos de discos ópticos como soporte de grabación que puede extraerse de un aparato de grabación. Estos discos ópticos grabables se han propuesto como soporte de gran capacidad de varios GB y se consideran prometedores como soporte para grabar señales AV (audio visuales). Por ejemplo, el documento EP-A-0 991 072 da a conocer un método para direccionar un flujo continuo de bits que se va a grabar o se está grabando en un soporte de almacenamiento, por ejemplo, un disco óptico. Entre las fuentes (fuentes de suministro) de señales AV digitales, grabadas en el disco óptico grabable, existen, por ejemplo, emisiones de radiodifusión digitales por satélite CS y emisiones de radiodifusión digitales BS. Para un uso futuro, también se ha propuesto la radiodifusión de televisión por ondas terrestres del sistema digital.

Debería observarse que las señales de vídeo digitales, proporcionadas desde estas fuentes, se comprimen rutinariamente de acuerdo con el sistema MPEG (Grupo de Expertos en Imágenes en Movimiento) 2. Para el aparato de grabación, se fija una velocidad de grabación apropiada para el aparato. Si las señales de vídeo digitales, obtenidas a partir de la emisión de radiodifusión digital, se graban mediante un soporte de almacenamiento de vídeo convencional para uso doméstico, de acuerdo con un sistema de grabación analógico, las señales de vídeo digitales en primer lugar se decodifican y posteriormente se limitan en cuanto a banda para su grabación. Alternativamente, con el sistema de grabación digital, ejemplificado principalmente por el sistema de vídeo MPEG1, vídeo MPEG2 ó de DV, las señales de vídeo digitales se decodifican una vez y posteriormente se re-codifican de acuerdo con la velocidad de grabación y el sistema de codificación apropiados para que el aparato realice la grabación.

Sin embargo, con un método de grabación de este tipo, en el cual el flujo continuo de bits suministrado se decodifica una vez y posteriormente se limita en ancho de banda o se re-codifica antes de la grabación, la calidad de la imagen se deteriora necesariamente. Si, en la grabación de señales digitales comprimidas, la velocidad de transmisión para señales digitales de entrada no es más alta que la velocidad de grabación del aparato de grabación y/o reproducción, un método tal en el que el flujo continuo de bits suministrado se graba directamente sin decodificación

o re-codificación padece en menor medida un deterioro de la calidad de la imagen. Sin embargo, si la velocidad de transmisión de las señales digitales comprimidas supera la velocidad de grabación del disco como soporte de grabación, es realmente necesario decodificar primero las señales digitales en el aparato de grabación y/o reproducción, y re-codificar las señales digitales para la grabación de manera que la velocidad de transmisión no sea mayor que el límite superior de la velocidad de grabación del disco.

Si las señales se transmiten de acuerdo con un sistema de velocidad variable en el cual la velocidad de bits de las señales digitales de entrada se incrementa o reduce con el tiempo, en un sistema de grabación de discos tal en el que se pueden almacenar datos una vez en una memoria intermedia y los mismos se graban por ráfagas la capacidad del soporte de grabación se puede aprovechar de una manera menos derrochadora que con un sistema de grabación en el cual el cabezal rotatorio presenta unas rpm fijas y por tanto la velocidad de grabación es una velocidad de grabación fija.

En el futuro próximo, cuando la radiodifusión digital se convierta en la tendencia predominante, se puede prever que existirá una demanda clara de un aparato de grabación y/o reproducción tal en el que las señales emitidas se graben en su estado de señales digitales, sin decodificación o re-codificación, como en el caso de una unidad de flujos continuos (data streamer), y en el que se use un disco como soporte de grabación.

Mientras tanto, en la grabación de datos de flujos continuos AV en un soporte de grabación mediante el aparato de grabación descrito anteriormente, los datos de los flujos continuos AV se pueden analizar para permitir que una reproducción rápida detecte la posición de una imagen I con el fin de efectuar una grabación, tal como posibilitar el acceso a una imagen I. Alternativamente, el flujo continuo AV se puede grabar directamente sin análisis.

En tal caso, la práctica convencional ha consistido en proporcionar programas de aplicación dedicados respectivos por medio de los cuales el flujo continuo AV se graba en el soporte de grabación como flujos continuos AV de diferentes formatos. El resultado es que el desarrollo de un programa de aplicación tiende a ser costoso y consume

mucho tiempo. En los flujos continuos AV grabados en programas de aplicación respectivos, el formato es diferente, de un flujo continuo AV a otro, con el resultado de que los flujos continuos AV respectivos no se pueden reproducir en el mismo aparato debido a la falta de compatibilidad.

Además, el aparato de grabación convencional tiene un inconveniente según el cual resulta difícil, por ejemplo, realizar una post-grabación de datos de audio.

El documento EP-A 0 949 825 da a conocer un soporte de grabación que comprende una cadena de programa que define una primera celda en un objeto de vídeo y una segunda celda en otro objeto de vídeo que comprende datos de audio tras la grabación.

El documento EP-A 1103974, que se considera técnica anterior según el Artículo 54(3) EPC con respecto a esta solicitud, describe un sistema que tiene Listas de Reproducción, Elementos de Reproducción y Fragmentos (en inglés "clips"). Un Fragmento comprende un archivo de flujo continuo AV y un archivo de información de flujo continuo AV. Una Lista de Reproducción tiene una Ruta Principal, y una Ruta Auxiliar para la post-grabación de audio. Un campo en la Lista de Reproducción indica un tiempo de inicio para la Ruta Auxiliar con el fin de sincronizar la reproducción entre la Ruta Principal y la Ruta Auxiliar.

Exposición de la invención

Es por lo tanto un objetivo de las enseñanzas dadas a conocer en la presente, proporcionar una disposición en la cual se puedan supervisar en común un flujo continuo AV con capacidad de llevar a cabo una grabación de alta velocidad y un flujo continuo AV sin capacidad de llevar a cabo una grabación de alta velocidad.

Es otro objetivo de las enseñanzas dadas a conocer en la presente, proporcionar una disposición en la cual resulte posible la post-grabación.

Esta invención se define en las reivindicaciones adjuntas.

Otros objetivos, características y ventajas de la presente invención se pondrán más claramente de manifiesto a partir de la lectura de las formas de realización de la presente invención según se muestra en los dibujos.

Breve descripción de los dibujos

La Fig. 1 muestra una configuración de una forma de realización de un aparato de grabación y/o reproducción según

la presente invención. La Fig. 2 ilustra el formato de datos correspondiente a datos grabados en un soporte de grabación mediante un aparato de grabación y/o reproducción 1.

La Fig. 3. ilustra una Real PlayList (ListaReproducción Real) y una Virtual PlayList (ListaReproducción Virtual). Las Figs. 4A, 4B y 4C ilustran la creación de la Real PlayList. Las Figs. 5A, 5B y 5C ilustran la eliminación de la Real PlayList. Las Figs. 6A y 6B ilustran la edición de montaje. La Fig. 7 ilustra la provisión de una sub-ruta en la Virtual PlayList. La Fig. 8 ilustra el cambio de la secuencia de reproducción de la PlayList. La Fig. 9 ilustra una marca en la PlayList y una marca en el Clip (Fragmento). La Fig. 10 ilustra una imagen en miniatura de menú. La Fig. 11 ilustra una marca añadida a la PlayList. La Fig. 12 ilustra una marca añadida al Clip. La Fig. 13 ilustra la relación entre la PlayList, el Clip y el archivo de la imagen en miniatura. La Fig. 14 ilustra una estructura de directorios. La Fig. 15 ilustra una sintaxis de infr.dvr.

La Fig.16 muestra una sintaxis de DVRVolume (VolumenDVR). La Fig.17 muestra una sintaxis del ResumeVolume (VolumenReanudación).

5 La Fig. 18 muestra una sintaxis de UIAppInfoVolume (InfoApliUIVolumen). La Fig. 19 muestra una tabla de valores de conjuntos de caracteres. La Fig. 20 muestra una sintaxis de TableOfPlayList (TablaDeListaReproducción). La Fig. 21 muestra otra sintaxis de TableOfPlayList. La Fig. 22 muestra una sintaxis del MakersPrivateData (DatosPrivadosFabricante).

15 La Fig. 23 muestra una sintaxis de xxxx.rpls e yyyy.vpls. Las Figs. 24A a 24C ilustran la PlayList. La Fig. 25 muestra una sintaxis de PlayList. La Fig. 26 muestra una tabla de PlayList_type (tipo_ListaReproducción). La Fig. 27 muestra una sintaxis de UIAppInfoPlayList.

25 Las Figs. 28A a 28C ilustran banderas en la sintaxis de UIAppInfoPlayList mostrada en la Fig. 27. La Fig. 29 ilustra un Playltem (ElementoReproducción). La Fig. 30 ilustra un Playltem. La Fig. 31 ilustra un Playltem. La Fig. 32 muestra una sintaxis del Playltem.

35 La Fig. 33 ilustra IN-time (tiempo-ENTRADA). La Fig. 34 ilustra OUT-time (tiempo-SALIDA). La Fig. 35 muestra una tabla de Connection_Condition (Condición_Conexión). Las Figs. 36A a 36D ilustran Connection_Condition. La Fig. 37 ilustra BridgeSequencelnfo (InfoSecuenciaPuente).

45 La Fig. 38 muestra una sintaxis de BidgeSequencelnfo. La Fig. 39 ilustra SubPlayItem (SubElementoReproducción). La Fig. 40 muestra una sintaxis de SubPlayltem. La Fig. 41 muestra una tabla de Mark_type (Tipo_marca). La Fig. 42 muestra una sintaxis de PlayListMark (MarcaListaReproducción).

55 La Fig. 43 muestra una tabla de Mark_type. La Fig. 44 ilustra Mark_time_stamp (Indicación_tiempo_marca). La Fig. 45 muestra una sintaxis de zzzzz.clip (zzzz.fragmento). La Fig. 46 muestra una sintaxis de Cliplnfo (InfoFragmento). La Fig. 47 muestra una tabla de Clip_stream_type (Tipo_flujoContinuo_fragmento).

65 La Fig. 48 ilustra offset_SPN (desplazamiento_SPN).

La Fig. 49 ilustra offset_SPN. Las Figs. 50A y 50B ilustran el dominio de STC.

5 La Fig. 51 ilustra STC_Info (Info_STC). La Fig. 52 muestra una sintaxis de STC_Info. La Fig. 53 ilustra Programlnfo (InfoPrograma). La Fig. 54 muestra una sintaxis de Programlnfo. La Fig. 55 muestra una sintaxis de VideoCodinglnfo (InfoCodificaciónVídeo).

15 La Fig. 56 muestra una tabla de Video_format (Formato_vídeo). La Fig. 57 muestra una tabla de frame_rate (velocidad_cuadro). La Fig. 58 muestra una tabla de display_aspect_ratio (relación_aspecto_visualización). La Fig. 59 muestra una sintaxis de AudioCodinglnfo (InfoCodificaciónAudio). La Fig. 60 muestra una tabla de audio_coding (codificación_audio).

25 La Fig. 61 muestra una tabla de audio_component_type (tipo_componente_audio). La Fig. 62 muestra una tabla de sampling_frequency (frecuencia_muestreo). La Fig. 63 ilustra CPI. La Fig. 64 ilustra CPI. La Fig. 65 muestra una sintaxis de CPI.

35 La Fig. 66 muestra una tabla de CPI_type (tipo_CPI). La Fig. 67 ilustra un EP_map (mapa_EP) de vídeo. La Fig. 68 ilustra EP_map. La Fig. 69 ilustra EP_map. La Fig. 70 muestra una sintaxis de EP_map.

45 La Fig. 71 muestra una tabla de EP_typevalues (valorestipo_EP). La Fig. 72 muestra una sintaxis de EP_map_for_one_stream_PID (mapa_EP_para_un_PID_flujoContinuo). La Fig. 73 ilustra TU_map (mapa_TU). La Fig. 74 muestra una sintaxis de TU_map. La Fig. 75 muestra una sintaxis de ClipMark (MarcaFragmento).

55 La Fig. 76 muestra una tabla de Mark_type (Tipo_marca). La Fig. 77 muestra una tabla de Mark_type_stamp (Indicación_tipo_marca). La Fig. 78 muestra una sintaxis de menu.thmb (menú.thmb) y mark.thmb (marca.thmb). La Fig. 79 muestra la sintaxis de la imagen en miniatura. La Fig. 80 muestra una tabla de thumbnail_picture_format (formato_imagen_miniatura).

65 Las Figs. 81A y 81B ilustran tn_block (bloque_tn).

La Fig. 82 ilustra una estructura de un flujo continuo de transporte de DVR MPEG2. La Fig. 83 muestra un modelo de grabador de un flujo continuo de transporte de DVR MPEG2. La Fig. 84 muestra un modelo de reproductor de un flujo continuo de transporte de DVR MPEG2. La Fig. 85 muestra la sintaxis de un paquete fuente. La Fig. 86 muestra la sintaxis de TP_extra_header (encabezamiento_adicional_TP). La Fig. 87 muestra una tabla de un indicador de permiso de copias. La Fig. 88 ilustra una conexión sin interrupciones. La Fig. 89 ilustra una conexión sin interrupciones. La Fig. 90 ilustra una conexión sin interrupciones. La Fig. 91 ilustra una conexión sin interrupciones. La Fig. 92 ilustra una conexión sin interrupciones. La Fig. 93 ilustra un solapamiento de audio. La Fig. 94 ilustra una conexión sin interrupciones que utiliza BridgeSequence. La Fig. 95 ilustra una conexión sin interrupciones que no utiliza BridgeSequence. La Fig. 96 muestra un modelo de DVR STD. La Fig. 97 es un diagrama de temporización para decodificación y visualización. La Fig. 98 muestra la sintaxis de un archivo de PlayList. La Fig. 99 muestra la sintaxis de UIAppInfoPlayList en el archivo de PlayList de la Fig. 98. La Fig. 100 muestra la sintaxis de la PlayList() en el archivo de PlayList de la Fig. 98. La Fig. 101 muestra la sintaxis de SubPlayltem. La Fig. 102 es un diagrama de flujo para ilustrar el método para formar RealPlayList. La Fig. 103 es un diagrama de flujo para ilustrar el método para formar VirtualPlayList. La Fig. 104 es un diagrama de flujo para ilustrar el método para reproducir la PlayList. La Fig. 105 es un diagrama de flujo para ilustrar el método para reproducir una sub-ruta de PlayList. La Fig. 106 es un diagrama de flujo para ilustrar el método para formar PlayListMark. La Fig. 107 es un diagrama de flujo para ilustrar el método de localización de reproducción que utiliza PlayListMark. La Fig. 108 ilustra un soporte.

Mejor modo de poner en práctica la invención

En referencia a los dibujos, se explicará detalladamente la presente forma de realización de la presente invención. La Fig. 1 muestra una estructura interna típica de un aparato de grabación y/o reproducción 1 que materializa la presente invención. En primer lugar se explica la estructura de una unidad de grabación 2, configurada para grabar señales introducidas desde el exterior. El aparato de grabación y/o reproducción 1 se configura para ser alimentado con y grabar datos analógicos o digitales.

Las señales de vídeo analógicas y las señales de audio analógicas se alimentan a terminales 11, 12, respectivamente. A las señales de vídeo, introducidas en el terminal 11, se les da salida hacia una unidad de análisis 14 y hacia un codificador AV 15. A las señales de audio, introducidas en el terminal 12, se les da salida hacia la

unidad de análisis 14 y al codificador AV 15. La unidad de análisis 14 extrae puntos característicos, tales como cambios de escena, a partir de las señales de audio y vídeo de entrada.

El codificador AV 15 codifica señales de vídeo y audio de entrada para dar salida a la información del sistema (S), tal como un flujo continuo de vídeo codificado (V), un flujo continuo de audio codificado (A) y una sincronización AV, hacia un multiplexor 16.

El flujo continuo de vídeo codificado es un flujo continuo de vídeo codificado, por ejemplo, con el sistema MPEG (Moving Picture Expert Group) 2, mientras que el flujo continuo de audio codificado es un flujo continuo de audio codificado de acuerdo con el sistema MPEG1, siendo el flujo continuo de audio codificado, por ejemplo, un flujo continuo de audio codificado, por ejemplo, en el sistema MPEG1, o un flujo continuo de audio codificado de acuerdo con el sistema Dolby AC3 (marca comercial). El multiplexor 16 multiplexa los flujos continuos de audio y vídeo de entrada, sobre la base de la información del sistema de entrada, para dar salida a un flujo continuo multiplexado, a través de un conmutador 17 hacia una unidad de análisis de flujos continuos multiplexados 18 y hacia un formador de paquetes fuente 19.

El flujo continuo multiplexado es, por ejemplo, un flujo continuo de transporte MPEG-2 ó un flujo continuo de programa MPEG2. El formador de paquetes fuente 19 codifica el flujo continuo de entrada multiplexado, en un flujo continuo AV compuesto por paquetes fuente de acuerdo con un formato de aplicación de un soporte de grabación 100 en el cual se graba el flujo continuo. El flujo continuo AV se procesa en la unidad de ECC (corrección y codificación de errores) 20 y una unidad de modulación 21 con la anexión de códigos de ECC y con modulación, antes de dársele salida hacia una unidad de escritura 22, la cual escribe (graba) a continuación un archivo de flujo continuo AV sobre la base de las señales de control obtenidas a la salida del controlador 23.

El flujo continuo de transporte, tal como una emisión de radiodifusión de televisión digital, introducido desde una interfaz digital o un sintonizador de televisión digital, se introduce en un terminal 13. Existen dos sistemas de grabación para grabar el flujo continuo de transporte introducido en el terminal 13, siendo uno de ellos un sistema de grabación transparente y siendo el otro un sistema en el cual a la grabación le precede una re-codificación destinada a reducir, por ejemplo la velocidad de bits de grabación. La información de órdenes del sistema de grabación se introduce desde un terminal 24 como interfaz de usuario, en un controlador 23.

En la grabación transparente del flujo continuo de transporte de entrada, a un flujo continuo de transporte, introducido en un terminal 13, se le da salida a través de un conmutador 17 hacia una unidad de análisis de flujos continuos multiplexados 18 y hacia el formador de paquetes fuente 19. El procesado consiguiente de grabación de un flujo continuo AV en un soporte de grabación es el mismo que el correspondiente para codificar y grabar señales de audio y vídeo analógicas de entrada, tal como se ha descrito anteriormente, y por ello no se explica en este caso por motivos de simplicidad.

Si el flujo continuo de transporte de entrada se re-codifica y posteriormente se graba, el flujo continuo de transporte, introducido en el terminal 13, se alimenta a un demultiplexor 26, el cual demultiplexa el flujo continuo de transporte de entrada para extraer un flujo continuo de vídeo (V), un flujo continuo de audio (A) y la información de sistema (S).

Del flujo continuo (información), según es extraído por el demultiplexor 26, se da salida al flujo continuo de vídeo hacia un decodificador de audio 27, mientras que al flujo continuo de audio y a la información del sistema se les da salida hacia el multiplexor 16. El decodificador de audio 27 decodifica el flujo continuo de transporte de entrada para dar salida al flujo continuo de vídeo (V) codificado hacia el multiplexor 16.

El flujo continuo de audio y la información del sistema, obtenidos a la salida del demultiplexor 26 e introducidos en el multiplexor 16, y el flujo continuo de vídeo, obtenido a la salida del codificador AV 15, se multiplexan, sobre la base de la información del sistema de entrada, y se les da salida hacia la unidad de análisis de flujos continuos multiplexados 18 y hacia el formador de paquetes fuente 19 a través de un conmutador 17, como flujo continuo multiplexado. El procesado consiguiente para grabar un flujo continuo AV en un soporte de grabación es el mismo que el correspondiente para codificar y grabar señales de audio y vídeo analógicas, según se ha descrito anteriormente, y por lo tanto, no se explica en este caso por motivos de simplicidad.

El aparato de grabación y/o reproducción 1 de la presente forma de realización graba un archivo del flujo continuo AV en el soporte de grabación 100, aunque también se graba la información de base de datos de aplicación que responde del archivo. La información de entrada al controlador 23, es la información característica para la imagen en movimiento de la unidad de análisis 14, la información característica del flujo continuo AV de la unidad de análisis de flujos continuos multiplexados 18 y la información de órdenes de usuario introducida en un terminal 24.

La información característica de la imagen en movimiento, suministrada desde la unidad de análisis 14, se genera por medio de la unidad de análisis 14 cuando el codificador AV 15 codifica señales de vídeo. La unidad de análisis 14 analiza el contenido de las señales de audio y de vídeo de entrada para generar la información pertinente de las imágenes característica de las señales de imágenes en movimiento de entrada (marca de fragmento). Esta información es la información que indica una imagen de puntos de marca de fragmento característicos, tales como

puntos de inicio de programas, puntos de cambio de escena, puntos de inicio y finales de comerciales CM, el título o telop en señales de vídeo de entrada, y también incluye una miniatura de la imagen y la información pertinente de puntos de conmutación de estéreo/monoaural y porciones silenciadas de señales de audio.

La anterior información indicadora de imágenes se alimenta a través del controlador 23 al multiplexor 16. Cuando se multiplexa una imagen codificada especificada como marca de fragmento por el controlador 23, el multiplexor 16 devuelve la información para especificar la imagen codificada en el flujo continuo AV al controlador 23. Específicamente, esta información es la PST (marca de tiempo de presentación) de una imagen o la información de dirección en el flujo continuo AV de una versión codificada de la imagen. El controlador 23 almacena la clase de imágenes características y la información para especificar la imagen codificada, en el flujo continuo AV en asociación mutua.

La información característica del flujo continuo AV de la unidad de análisis de flujos continuos multiplexados 18 es la información pertinente de la información de codificación del flujo continuo AV a grabar, y se graba por medio de una unidad de análisis 18. Por ejemplo, la información característica incluye la indicación de tiempo e información de dirección de la imagen I en el flujo continuo AV, información de puntos discontinuos de relojes de tiempo del sistema, parámetros de codificación del flujo continuo AV e información de puntos de cambio de los parámetros de codificación en el flujo continuo AV. Cuando se graba de manera transparente el flujo continuo de transporte, intrducido desde el terminal 13, la unidad de análisis de flujos continuos multiplexados 18 detecta la imagen de la marca de fragmento mencionada anteriormente, a partir del flujo continuo de transporte de entrada, y genera la información para especificar una imagen designada por la marca de fragmento y su tipo.

La información de designación de usuario del terminal 24 es la información que especifica el dominio de reproducción, designado por el usuario, letras de caracteres para explicar el contenido del domino de reproducción,

o la información tal como marcadores o puntos de reanudación establecidos por el usuario para su escena favorita.

Sobre la base de la información de entrada mencionada anteriormente, el controlador 23 crea una base de datos del flujo continuo AV (Clip), una base de datos de un grupo (PlayList) de dominios de reproducción (Playltem) del flujo continuo AV, información de gestión del contenido grabado del soporte de grabación 100 (info.drv) y la información sobre imágenes en miniatura. De manera similar al flujo continuo AV, la información de base de datos de aplicación, construida a partir de la información anterior, se procesa en la unidad de ECC 20 y la unidad de modulación 21, y se introduce en la unidad de escritura 22, la cual a continuación graba un archivo de base de datos en el soporte de grabación 100.

La información de base de datos de aplicación, antes descrita, se explicará posteriormente de forma detallada.

Cuando el archivo de flujo continuo AV grabado en el soporte de grabación 100 (archivos de datos de imágenes y datos de voz) y la información de base de datos de aplicación, grabada de este modo en el soporte de grabación 100, se reproducen por medio de una unidad de reproducción 3, el controlador 23 ordena en primer lugar a una unidad de lectura 28 que lea la información de base de datos de aplicación desde el soporte de grabación 100. La unidad de lectura 28 lee la información de base de datos de aplicación desde el soporte de grabación 100, el cual a continuación lee la información de base de datos de aplicación desde el soporte de grabación 100 para enviar la información de base de datos de aplicación a través del procesado de demodulación y corrección de errores mediante una unidad de demodulación 29 y un decodificador de ECC 30 al controlador 23.

Sobre la base de la información de base de datos de aplicación, el controlador 23 da salida a una lista de PlayList grabada en el soporte de grabación 100 hacia una interfaz de usuario del terminal 24. El usuario selecciona la PlayList, que se desea reproducir, a partir de la lista de PlayLists. La información pertinente de PlayList, especificada para ser reproducida, se introduce en el controlador 23. El controlador 23 ordena a la unidad de lectura 28 que lea el archivo de flujo continuo AV necesario en la reproducción de la PlayList. De acuerdo con la orden, la unidad de lectura 28 lee el flujo continuo AV correspondiente desde el soporte de grabación 100 para dar salida al flujo continuo AV leído hacia la unidad de demodulación 29. El flujo continuo AV, introducido de este modo en la unidad de demodulación 29, se demodula mediante el procesado preestablecido y se le da salida a través del procesado del decodificador de ECC 30 hacia un desempaquetador de paquetes fuente 31.

El desempaquetador de paquetes fuente 31 convierte el flujo continuo AV del formato de la aplicación, leído desde el soporte de grabación 100 y procesado según el modo preestablecido, en un flujo continuo procesable por el demultiplexor 26. El demultiplexor 26 da salida a la información del sistema (S), tal como el flujo continuo de vídeo (V), el flujo continuo de audio (A) o la sincronización AV, que forman el dominio de reproducción (Playltem) del flujo continuo AV especificado por el controlador 23, hacia el decodificador de audio 27, decodificando dicho decodificador AV 27 el flujo continuo de vídeo y el flujo continuo de audio para dar salida a la señal de vídeo de reproducción y la señal de audio de reproducción hacia terminales asociados 32, 33, respectivamente.

Si se alimenta desde el terminal 24, como interfaz de usuario, con la información que da instrucciones para la reproducción de acceso aleatorio o la reproducción especial, el controlador 23 determina la posición de lectura del flujo continuo AV desde el soporte de grabación 100, sobre la base del contenido de la base de datos (Clip) del flujo

continuo AV, para ordenar a la unidad de lectura 28 que lea el flujo continuo AV. Si la PlayList según es seleccionada por el usuario se va a reproducir a partir de un instante de tiempo preestablecido, el controlador 23 ordena a la unidad de lectura 28 que lea datos desde una imagen I que tiene una indicación de tiempo más próxima al instante de tiempo especificado.

Cuando el usuario ha seleccionado una cierta marca de fragmento a partir de puntos de indexación o puntos de cambio de escena para el programa almacenado en la ClipMark en el Clip Information (Información de Fragmento), como cuando el usuario selecciona una cierta imagen de entre una lista de imágenes en miniatura, según se muestra en una interfaz de usuario, de los puntos de indexación o puntos de cambio de escena almacenados en la ClipMark, el controlador 23 determina la posición de lectura del flujo continuo AV desde el soporte de grabación 100 para ordenar a la unidad de lectura 28 que lea el flujo continuo AV. Es decir, el controlador 23 ordena a la unidad de lectura 28 que lea datos desde una imagen I que tiene una dirección más próxima a la dirección en el flujo continuo AV que ha almacenado la imagen seleccionada por el usuario. La unidad de lectura 28 lee datos desde la dirección especificada. Los datos leídos se procesan mediante la unidad de demodulación 29, el decodificador de ECC 30 y mediante el formador de paquetes fuente 19, para ser suministrados al demultiplexor 26 y ser decodificados por el decodificador de audio 27 con el fin de reproducir datos AV indicados por una dirección de la imagen del punto de marca.

Si el usuario ha ordenado la reproducción de avance rápido, el controlador 23 ordena a la unidad de lectura 28 que lea secuencialmente datos de imagen I en el flujo continuo AV de manera sucesiva basándose en la base de datos (Clip) del flujo continuo AV.

La unidad de lectura 28 lee datos del flujo continuo AV desde un punto de acceso aleatorio especificado. Los datos leídos de esta manera se reproducen a través del procesado de varios componentes en la parte de aguas abajo.

Se explica a continuación el caso en que el usuario edita el flujo continuo AV grabado en el soporte de grabación

100. Si se desea especificar un dominio de reproducción para el flujo continuo AV grabado en el soporte de grabación 100, por ejemplo, si se desea crear un trayecto de reproducción para reproducir una porción cantada por un cantante A desde un programa de canciones A, y reproducir posteriormente una porción cantada por el mismo cantante A desde otro programa de canciones B, la información pertinente de un punto de comienzo (punto-ENTRADA) y un punto final (punto-SALIDA) del dominio de reproducción se introduce en el controlador 23 desde el terminal como interfaz de usuario. El controlador 23 crea una base de datos del grupo (PlayList) de dominios de reproducción (Playltem) de los flujos continuos AV.

Cuando el usuario desea borrar una porción del flujo continuo AV grabada en el soporte de grabación 100, la información pertinente del punto-ENTRADA y el punto-SALIDA del dominio de borrado se introduce en el controlador 23, el cual modifica a continuación la base de datos de la PlayList para referirse solamente a los flujos continuos AV necesarios. El controlador 23 ordena también a la unidad de escritura 22 que borre una porción de flujo continuo no necesaria del flujo continuo AV.

Se explica a continuación el caso en el cual el usuario desea especificar dominios de reproducción de un flujo continuo AV grabado en el soporte de grabación, para crear un nuevo trayecto de reproducción, y para interconectar los dominios de reproducción respectivos en un modo sin interrupciones. En tal caso, el controlador 23 crea una base de datos de un grupo (PlayList) de los dominios de reproducción (Playltem) del flujo continuo AV y se ocupa de recodificar y re-multiplexar parcialmente el flujo continuo de vídeo en las proximidades de los puntos de unión de los dominios de reproducción.

La información de imagen en el punto-ENTRADA y la del punto-SALIDA de un dominio de reproducción se introducen desde un terminal 24 en un controlador 23. El controlador 23 ordena a la unidad de lectura 28 que lea datos necesarios para reproducir las imágenes en el punto-ENTRADA y en el punto-SALIDA. La unidad de lectura 28 lee datos desde el soporte de grabación 100. A los datos leídos de esta manera se les da salida a través de la unidad de demodulación 29, el decodificador de ECC 30 y el formador de paquetes fuente 19 hacia el demultiplexor

26.

El controlador 23 analiza datos introducidos en el demultiplexor 26 para determinar el método de re-codificación para el flujo continuo de vídeo (cambio de picture_coding_type (tipo_codificación_película) y asignación de la cantidad de bits de codificación para la re-codificación) y el sistema de re-multiplexado con el fin de enviar el sistema al codificador AV 15 y al multiplexor 16.

El demultiplexor 26 separa entonces el flujo continuo de entrada en el flujo continuo de vídeo (V), el flujo continuo de audio (A) y la información del sistema (S). El flujo continuo de vídeo se puede clasificar en datos introducidoes en el decodificador de audio 27 y datos introducidos en el multiplexor 16. Los primeros son datos necesarios para la recodificación y se decodifican mediante el decodificador de audio 27, re-codificándose a continuación la imagen decodificada mediante el codificador AV 15 y provocándose así que se convierta en un flujo continuo de vídeo. Los segundos datos son datos copiados desde un flujo continuo original sin re-codificación. El flujo continuo de audio y la información del sistema se introducen directamente en el multiplexor 16.

El multiplexor 16 multiplexa un flujo continuo de entrada, sobre la base de la información introducida desde el controlador 23, para dar salida a un flujo continuo multiplexado, el cual se procesa mediante la unidad de ECC 20 y la unidad de modulación 21 para ser enviado a la unidad de escritura 22. La unidad de escritura 22 graba un flujo continuo AV en el soporte de grabación 100 sobre la base de las señales de control suministradas desde el controlador 23.

En lo sucesivo se explica en la presente la información de base de datos de aplicación y el funcionamiento basado en esta información, tal como la reproducción y edición. La Fig. 2 muestra la estructura de un formato de aplicación que tiene dos capas, es decir, PlayList y Clip, para la gestión de flujos continuos AV. La Información de Volumen gestiona todos los Clips y PlayLists en el disco. En este caso, un flujo continuo AV y la información auxiliar del mismo, emparejados entre sí, se consideran como un objeto, y se les denomina Clip. Al archivo de flujo continuo AV se le denomina Clip AV stream (Flujo continuo AV de fragmento), denominándose archivo Clip Information (Información de Fragmento) a la información auxiliar.

Un archivo de Flujo continuo AV de fragmento almacena datos correspondientes a un flujo continuo de transporte MPEG-2 dispuesto en una estructura prescrita por el formato de aplicación. En términos generales, un archivo se trata como una cadena de bytes. El contenido del archivo de Flujo continuo AV de fragmento se expande en el eje de tiempo, especificándose principalmente los puntos de entrada en el Clip (imagen I) sobre la base del tiempo. Cuando se proporciona una indicación de tiempo de un punto de acceso a un Clip preestablecido, el archivo de Información de Fragmento es útil para encontrar la información de dirección en la cual iniciar la lectura de datos en el archivo de Flujo continuo AV de fragmento.

Se explica a continuación la PlayList en referencia a la Fig. 3, la cual se proporciona para que un usuario seleccione un dominio de reproducción que se desea ver desde el Clip y para editar fácilmente el dominio de reproducción. Una PlayList es un conjunto de dominios de reproducción en el Clip. A un dominio de reproducción en un Clip preestablecido se le denomina Playltem y se representa mediante un par de un punto-ENTRADA y un punto-SALIDA en el eje de tiempo. Así, la PlayList se forma mediante un conjunto de diversos Playltems.

La PlayList se clasifica en dos tipos, uno de las cuales es la Real PlayList y la otra es la Virtual PlayList. La Real PlayList es co-propietaria de porciones de flujo continuo del Clip al que remite. Es decir, la Real PlayList ocupa en el disco la capacidad de datos correspondiente a una porción de flujo continuo del Clip al que remite, y cuando la Real PlayList se borra, los datos de la porción de flujo continuo del Clip al que remite también se borran.

La Virtual PlayList no es co-propietaria de los datos de Clip. Por lo tanto, si la Virtual PlayList se cambia o borra, el contenido del Clip no cambia en modo alguno.

Se explica la edición de la Real PlayList. La Fig. 4A muestra la creación de Real PlayList y, si el flujo continuo AV se graba como un nuevo Clip, la Real PlayList que remite al Clip completo es una operación recién creada.

La Fig. 4B muestra la división de la Real PlayList, es decir, la operación de división de la Real PlayList por un punto deseado para dividir la Real PlayList en dos Real PlayLists. Esta operación de división se lleva a cabo cuando se gestionan dos programas en un clip gestionado por una sola PlayList y cuando el usuario pretende re-registrar o regrabar los programas como programas individuales independientes. Esta operación no conduce a la alteración del contenido de Clip, es decir, a la división del propio Clip.

La Fig. 4C muestra la operación de combinación de la Real PlayList, la cual es la operación de combinación de dos Real PlayLists en una nueva Real PlayList. Esta operación de combinación se lleva a cabo por ejemplo cuando el usuario desea re-registrar dos programas como un solo programa. Esta operación no conduce a la alteración del contenido del Clip, es decir a combinar el propio clip en uno.

La Fig. 5A muestra la eliminación de la Real PlayList completa. Si la operación para borrar la Real PlayList preestablecida completa, se borra también la porción del flujo continuo asociada del Clip al que remite la Real PlayList eliminada.

La Fig. 5B muestra la eliminación parcial de la Real PlayList. Si se elimina una porción deseada de la Real PlayList, el PlayItem asociado se altera para remitir solamente la porción necesaria del flujo continuo de Clip. Se elimina la porción correspondiente del flujo continuo del Clip.

La Fig. 5C muestra la minimización de la Real PlayList. Es una operación para provocar que el PlayItem asociado a la Real PlayList remita solamente a la porción de flujo continuo del Clip, necesaria para la Virtual PlayList. La porción correspondiente del flujo continuo del Clip no necesaria para la Virtual PlayList se elimina.

Si la Real PlayList se cambia mediante la operación descrita anteriormente, de manera tal que la porción del flujo continuo del Clip a la que remite la Real PlayList se elimina, existe una posibilidad de que la Virtual PlayList que

utiliza el Clip eliminado esté presente, de tal modo que pueden surgir problemas en la Virtual PlayList debido al Clip eliminado.

Para evitar que esto ocurra, se visualiza para el usuario un mensaje tal que dice: "Si existe la Virtual PlayList que remite a la porción del flujo continuo del Clip al que está remitiendo la Real PlayList, y la Real PlayList se elimina, se elimina la propia Virtual PlayList – ¿está de acuerdo?'' como respuesta a la operación, por parte del usuario, de eliminación, a modo de confirmación o aviso, tras lo cual se ejecuta o cancela el procesado de eliminación en función de las órdenes del usuario. Alternativamente, se lleva cabo la operación de minimización para la Real PlayList en lugar de eliminar la Virtual PlayList.

Se explica a continuación la operación para la Virtual PlayList. Si se lleva a cabo una operación para la Virtual PlayList, el contenido del Clip no cambia. Las Figs. 6A y 6B muestran el montaje y edición (edición de ENTRADA-SALIDA). Es una operación para crear PlayItem del domino de reproducción que el usuario ha deseado ver para crear Virtual PlayList. La conexión sin interrupciones entre PlayItems viene soportada por el formato de la aplicación, tal como se explica posteriormente.

Si existen dos Real PlayLists 1, 2 y fragmentos 1, 2 asociados a las Real PlayLists respectivas, el usuario especifica un dominio preestablecido en la Real PlayList 1 (dominio desde ENTRADA1 a SALIDA1: Playltem 1) como dominio de reproducción, y también especifica, como dominio a reproducir a continuación, un dominio preestablecido en la Real PlayList 2 (dominio desde ENTRADA2 a SALIDA2: Playltem 2) como dominio de reproducción, tal como se muestra en la Fig. 6A, se prepara una sola Virtual PlayList compuesta por Playltem 1 y el Playltem2, tal como se muestra en la Fig. 6B.

Se explica a continuación la re-edición de la Virtual PlayList. La re-edición se puede enumerar mediante la alteración de puntos de ENTRADA o SALIDA en la Virtual PlayList, la inserción o anexión de nuevos Playltems a la Virtual PlayList y la eliminación de Playltems en la Virtual PlayList. La propia Virtual PlayList también se puede eliminar.

La Fig. 7 muestra el doblaje de audio (post-grabación) en la Virtual PlayList. Es una operación para registrar la postgrabación de audio en la Virtual PlayList como una subruta. Esta post-grabación de audio está soportada por el software de aplicación. Un flujo continuo de audio adicional se añade como subruta al flujo continuo AV de la ruta principal de la Virtual PlayList.

Una operación para cambiar (mover) la secuencia de reproducción de la PlayList mostrada en la Fig. 8 es común a la Real PlayList y la Virtual PlayList. Esta operación es una alteración de la secuencia de reproducción de la PlayList en el disco (volumen) y está soportada por TableOfPlayList según se define en el formato de aplicación, tal como se explicará posteriormente en referencia a, por ejemplo, la Fig. 20. Esta operación no conduce a la alteración del contenido de Clip.

Se explica a continuación la marca (Mark). La marca se proporciona para especificar un momento relevante o característico en el Clip y en la PlayList, tal como se muestra en la Fig. 9. A la marca añadida al Clip se le denomina ClipMark (Marca de Fragmento). La ClipMark es, por ejemplo, un punto de indexación de programa o un punto de cambio de escena para especificar una escena característica atribuible a contenido en el flujo continuo AV. La ClipMark se genera mediante, por ejemplo, la unidad de análisis 14 de la Fig. 1. Cuando se reproduce la PlayList, se puede efectuar una remisión a la marca del Clip al que remite la PlayList y la misma se puede utilizar.

A la marca adjuntada a la PlayList se le denomina PlayListMark (marca de lista de reproducción). La PlayListMark es, por ejemplo, un punto de marcador o un punto de reanudación según establezca el usuario. El establecimiento de la marca en el Clip y en la PlayList se realiza añadiendo una indicación de tiempo que señala el instante de tiempo de la marca con respecto a la lista de marcas. Por otro lado, la eliminación de la marca se realiza eliminando de la lista de marcas la indicación de tiempo de la marca. Consecuentemente, el flujo continuo AV no cambia en modo alguno por el establecimiento de marcas o la eliminación de marcas.

Como formato adicional de la ClipMark, se puede especificar una imagen a la que remite la ClipMark basándose en direcciones en el flujo continuo AV. El establecimiento de marcas en el Clip se realiza añadiendo la información basada en direcciones que indica la imagen del punto de marca a la lista de marcas. Por otro lado, la eliminación de la marca se realiza eliminando de la lista de marcas la información basada en direcciones que indica la imagen del punto de marca. Consecuentemente, el flujo continuo AV no cambia en modo alguno por el establecimiento de marcas o la eliminación de marcas.

Se explica a continuación una imagen en miniatura. La imagen en miniatura es una imagen fija añadida al Volumen, la PlayList y el Clip. Existen dos tipos de imágen en miniatura, siendo uno de ellos una imagen en miniatura como imagen representativa que indica el contenido. Esto se usa generalmente en una imagen principal para que el usuario seleccione lo que desea ver actuando sobre un cursor, no mostrado. Otro tipo de imagen en miniatura es una imagen que indica una escena señalada por la marca.

El Volumen y las PlayLists respectivas necesitan poseer imágenes representativas. Se presupone que las imágenes representativas del Volumen se usan para mostrar inicialmente una imagen fija que representa el contenido del disco cuando el disco se monta en posición en el aparato de grabación y/o reproducción 1. Se observa que disco significa el soporte de grabación 100, que se presupone que tiene forma de disco. Se presupone que la imagen representativa de la PlayList se usa como imagen fija para representar contenido de la PlayList.

Como imagen representativa de la PlayList, se puede contemplar el uso de la imagen inicial de la PlayList como imagen en miniatura (imagen representativa). Sin embargo, la imagen inicial en el tiempo de reproducción de 0 no es necesariamente una imagen óptima que representa el contenido. Así, se permite al usuario establecer una imagen opcional como imagen en miniatura de la PlayList. A los dos tipos de imágenes en miniatura, es decir, a la imagen en miniatura como imagen representativa que indica el Volumen y a la imagen en miniatura como imagen representativa que indica PlayList, se les denomina imágenes en miniatura de menú. Puesto que las imágenes en miniatura de menú se muestran frecuentemente, estas imágenes en miniatura necesitan ser leídas a una velocidad elevada desde el disco. De esta manera, resulta eficaz almacenar la totalidad de las imágenes en miniatura de menú en un solo archivo. No es necesario que las imágenes en miniatura de menú sean imágenes extraídas a partir de las imágenes en movimiento en el volumen, pero pueden ser una imagen capturada desde un ordenador personal o una cámara fotográfica digital, tal como se muestra en la Fig. 10.

Por otro lado, el Clip y la PlayList necesitan ser marcados con diversas marcas, mientras que las imágenes de los puntos de marca necesitan ser visualizadas fácilmente para captar el contenido de las posiciones de las marcas. A la imagen que indica dicho punto de marca se le denomina imagen en miniatura de marca. Por lo tanto, la imagen que es el original de la imagen en miniatura de marca, es normalmente una imagen de punto de marca extraída en lugar de una imagen capturada desde el exterior.

La Fig. 11 muestra la relación entre la marca adjuntada a la PlayList y la imagen en miniatura de marca, mientras que la Fig. 12 muestra la relación entre la marca adjuntada al Clip y la imagen en miniatura de marca. A diferencia de la imagen en miniatura de menú, la imagen en miniatura de marca se usa, por ejemplo, en un sub-menú para representar detalles de la PlayList, aunque no se requiere que sea leída con un tiempo de acceso corto. Así, cada vez que se requiere una imagen en miniatura, el aparato de grabación y/o reproducción 1 abre un archivo y lee una porción del archivo, mientras que no se presenta ningún problema ni siquiera si la abertura del archivo y la lectura de una porción del archivo por el aparato de grabación y/o reproducción 1 consume cierto tiempo.

Para reducir el número de archivos presentes en un volumen, se prefiere que la totalidad de las imágenes en miniatura de marcas se almacenen en un solo archivo. Aunque la PlayList puede poseer una imagen en miniatura de menú y diversas imágenes en miniatura de marca, no se requiere que el usuario seleccione el Clip directamente (habitualmente, el Clip se selecciona a través de la PlayList), y por ello no existe necesidad de proporcionar imágenes en miniatura de menú.

La Fig. 13 muestra la relación entre las imágenes en miniatura de menú, las imágenes en miniatura de marcas, la PlayList y Clips. En el archivo de imágenes en miniatura de menú, se archivan imágenes en miniatura de menú proporcionadas desde una PlayList a otra. El archivo de imágenes en miniatura de menú contiene una imagen en miniatura de volumen que representa el contenido de datos grabados en el disco. En el archivo de imágenes en miniatura de menú, se archivan imágenes en miniatura creadas desde una PlayList a otra y desde un Clip a otro.

En lo sucesivo se explica en la presente la CPI (Información de Puntos Característicos). La CPI son datos contenidos en el archivo de Información de fragmento y se usa principalmente para encontrar una dirección de los datos en el Flujo continuo AV de fragmento en la cual iniciar la lectura de los datos cuando se proporciona una indicación de tiempo del punto de acceso para el Clip. En la presente forma de realización, se usan dos clases de la CPI, una de ellas es EP-map y la otra TU-map.

El EP_map es datos de una lista de punto de entrada (EP) extraídos desde el flujo continuo elemental y el flujo continuo de transporte. Tiene la información de direcciones usada para encontrar el lugar de los puntos de entrada en el flujo continuo AV en los cuales iniciar la decodificación. Los datos de un EP están compuestos por una marca de tiempo de presentación (PTS) y una dirección de los datos en el flujo continuo AV de la unidad de acceso asociada a la TPS, emparejándose la dirección de los datos con la PTS.

El EP_map se usa principalmente para dos propósitos. En primer lugar, se usa para encontrar una dirección de los datos en el flujo continuo AV en la unidad de acceso a la que remite la PTS en la PlayList. En segundo lugar, el EP_map se usa para la reproducción de avance rápido o reproducción de retroceso rápido. Si, en la grabación del flujo continuo AV de entrada por el aparato de grabación y/o reproducción 1, se puede analizar la sintaxis del flujo continuo, se crea el EP_map y el mismo se graba en el disco.

El TU_map tiene una lista de los datos de unidades de tiempo (TU), la cual se obtiene a partir del instante de tiempo de llegada del paquete de transporte introducido a través de una interfaz digital. Esto proporciona la relación entre el tiempo basado en el tiempo de llegada y la dirección de los datos en el flujo continuo AV. Cuando el aparato de

grabación y/o reproducción 1 graba un flujo continuo AV de entrada, y la sintaxis del flujo continuo no se puede analizar, se crea un TU_map y el mismo se graba en el disco.

La STCInfo almacena la información de puntos discontinuos en el archivo de flujo continuo AV que almacena el flujo 5 continuo de transporte MPEG-2.

Cuando el flujo continuo AV tiene puntos discontinuos de STC, los mismos valores de PTS pueden aparecer en el archivo de flujo continuo AV. De esta manera, si un instante de tiempo en el flujo continuo AV se especifica sobre la base de la PTS, la PTS del punto de acceso es insuficiente para especificar el instante. Además, se requiere un

10 índice del dominio de STC continuo que contiene la PTS. En este formato, al dominio de STC continuo y a su índice se les denomina secuencia de STC e id de secuencia de STC, respectivamente. La información de la secuencia de STC se define mediante la STCInfo del archivo de Información de Fragmento.

La id de secuencia de STC se usa en un archivo de flujo continuo AV y es opcional en el archivo de flujo continuo AV 15 que tiene el TU_map.

Los programas son cada uno de ellos una colección de flujos continuos elementales y poseen conjuntamente una sola base de tiempos del sistema para la reproducción sincronizada de estos flujos continuos.

20 Es útil que un aparato de reproducción (aparato de grabación y/o reproducción 1 de la Fig. 1) conozca el contenido de un flujo continuo AV antes de su decodificación. Este contenido incluye, por ejemplo, valores del PID de un paquete de transporte que transmite un flujo continuo elemental de audio o vídeo o el tipo de los componentes de audio o vídeo, tales como flujo continuo de vídeo HDTV o audio MPEG-2 AAC. Esta información es útil para crear una pantalla de menú para ilustrar al usuario el contenido de la PlayList que remite al flujo continuo AV. Es útil de

25 manera similar para establecer el estado inicial del decodificador AV y el demultiplexor del aparato respectivo.

Por esta razón, el archivo de Información de Fragmento posee Programlnfo para ilustrar el contenido del programa.

Puede darse el caso de que cambie el contenido del programa en el archivo de flujo continuo AV en el cual se

30 almacena el flujo continuo de transporte MPEG-2. Por ejemplo el PID del paquete de transporte que transmite el flujo continuo elemental de vídeo se puede cambiar, o el tipo de componente del flujo continuo de vídeo se puede cambiar de SDTV a HDTV.

El Programlnfo almacena la información sobre puntos de cambio del contenido del programa en el archivo de flujo

35 continuo AV. El dominio del archivo de flujo continuo AV en el cual el contenido del programa permanece constante se denomina secuencia del programa.

Esta secuencia del programa se usa en un archivo de flujo continuo AV que tiene EP_map y es opcional en un archivo de flujo continuo AV que tiene TU_map.

40 La presente forma de realización define el formato del flujo continuo de auto-codificación (SEFS). El SESF se usa para codificar señales analógicas de entrada y para decodificar señales digitales de entrada con el fin de codificar posteriormente la señal decodificada en un flujo continuo de transporte MPEG-2.

45 El SESF define un flujo continuo elemental pertinente del flujo continuo de transporte MPEG-2 y el flujo continuo AV. Cuando el aparato de grabación y/o reproducción 1 codifica y graba señales de entrada en el SESF, se crea un EP_map y el mismo se graba en el disco.

Un flujo continuo de radiodifusión digital utiliza uno de los siguientes sistemas para grabar en el soporte de

50 grabación 100: En primer lugar, el flujo continuo de radiodifusión digital se transcodifica en un flujo continuo de SESF. En este caso, el flujo continuo grabado debe ajustarse al SESF y el EP_map se debe preparar y grabar en el disco.

Alternativamente, un flujo continuo elemental que forma un flujo continuo de radiodifusión digital, se transcodificar en

55 un nuevo flujo continuo elemental y se re-multiplexa a un nuevo flujo continuo de transporte que se ajuste al formato del flujo continuo prescrito por la organización para normalizar el flujo continuo de radiodifusión digital. En este caso, se debe crear un EP_map y el mismo se debe grabar en el disco.

Por ejemplo, se supone que el flujo continuo de entrada es un flujo continuo de transporte MPEG-2 que se ajusta a

60 la ISDB (denominación normalizada de la BS digital de Japón), conteniendo el flujo continuo de transporte el flujo continuo de vídeo HDTV y el flujo continuo de audio MPEG AAC. El flujo continuo de vídeo HDTV se transcodificar en un flujo continuo de vídeo SDTV, re-multiplexándose dicho flujo continuo de vídeo SDTV y el flujo continuo de audio ACC original al TS. El flujo continuo SDTV y el flujo continuo de transporte necesitan ambos ajustarse al formato ISDB.

Otro sistema de grabación del flujo continuo de radiodifusión digital en el soporte de grabación 100 es realizar una grabación transparente del flujo continuo de transporte de entrada, es decir, grabar el flujo continuo de transporte de entrada sin cambios, en cuyo caso el EP_map se formula y se graba en el disco.

5 Alternativamente, el flujo continuo de transporte de entrada se graba transparentemente, es decir, un flujo continuo de transporte de entrada se graba sin cambios, en cuyo caso, se crea el TU_map y el mismo se graba en el disco.

En lo sucesivo se explican en la presente el directorio y el archivo. El aparato de grabación y/o reproducción 1 se describe en lo sucesivo como DVR (grabación de vídeo digital). La Fig. 14 muestra una estructura de directorios

10 típica en el disco. Los directorios del disco del DVR se pueden enumerar por medio de un directorio raíz que incluye el directorio "DVR", y el directorio "DVR", que incluye el directorio "PLAYLIST", el directorio "CLIPINF", el directorio "M2TS" y el directorio "DATA", tal como se muestra en la Fig. 14. Aunque bajo el directorio raíz se pueden crear directorios diferentes a los mencionados, estos se omiten en el formato de la aplicación de la presente forma de realización.

15 Bajo el directorio "DATA", hay almacenados todos los archivos y directorios prescritos por el formato de la aplicación de DVR. El directorio "DVR" incluye cuatro directorios. Bajo el directorio "PLAYLIST" se colocan archivos de base de datos de Real PlayList y Virtual PlayList. El último directorio puede existir en un estado desprovisto de PlayList.

20 Bajo "CLIPINF" se coloca una base de datos de Clip. También este directorio puede existir en un estado desprovisto de archivos de flujos continuos AV. En el directorio "DATA", hay almacenados archivos de radiodifusión de datos, tales como la radiodifusión de TV digital.

El directorio "DVR" almacena los siguientes archivos: Es decir, se crea un "info.dvr" bajo el directorio DVR para

25 almacenar la información exhasutiva de una capa de aplicación. Bajo el directorio DVR, debe haber un solo info.dvr. Se supone que el nombre de archivo se fija a info.dvr. El "menu.thmb" almacena la información pertinente de las imágenes en miniatura de menú. Bajo el directorio DVR, debe haber 0 ó 1 imagen en miniatura de marca. Se supone que el nombre de archivo se fija a "menu.thmb". Si no existe ninguna imagen en miniatura de menú, este archivo puede no existir.

30 El archivo "mark.thmb " almacena la información pertinente de la imagen en miniatura de marca. Bajo el directorio DVR, debe haber 0 ó 1 imagen en miniatura de marca. Se supone que el nombre de archivo se fija a "menu.thmb". Si no existe ninguna imagen en miniatura de menú, este archivo puede no existir.

35 El directorio "PLAYLIST" almacena dos clases de los archivos de PlayList, los cuales son Real PlayList y Virtual PlayList. Un archivo "xxxxx.rpls" almacena la información pertinente de una Real PlayList. Se crea un archivo para cada Real PlayList. El nombre de archivo es "xxxxx.rpls", donde "xxxxx" indica cinco cifras numéricas de 0 a 9. Una extensión del archivo debe ser "rpls".

40 El "yyyyy.vpls" almacena la información pertinente de una Virtual PlayList. Se crea un archivo con un nombre de archivo "yyyyy.vpls" de una Virtual PlayList a otra, donde “yyyyy” indica cinco cifras numéricas de 0 a 9. Una extensión del archivo debe ser "vpls".

El directorio "CLIPINF" almacena un archivo en asociación con cada archivo de flujo continuo AV. El "zzzzz.clpi" es

45 un archivo de Información de Fragmento que se corresponde con un archivo de flujo continuo AV (archivo de Flujo continuo AV de fragmento o archivo de flujo continuo de Fragmento-Puente (Bridge-Clip)). El nombre de archivo es "zzzzz.clpi", donde "zzzzz" indica cinco cifras numéricas de 0 a 9. Una extensión del archivo debe ser "clpi".

El directorio "M2TS" almacena un archivo de flujo continuo AV. El archivo "zzzzz.m2ts" es un archivo de flujo

50 continuo AV gestionado por el sistema de DVR. Es decir, un archivo de Flujo continuo AV de fragmento o un archivo de flujo continuo AV de Fragmento-Puente. El nombre de archivo es "zzzzz.m2ts", donde "zzzzz" indica cinco cifras numéricas de 0 a 9. Una extensión del archivo debe ser "m2ts".

El directorio "DATA" almacena datos transmitidos desde la radiodifusión de datos. Estos datos pueden ser, por 55 ejemplo, archivos XML o MPEG.

Se explican a continuación la sintaxis y la semántica de cada directorio (archivo). La Fig. 15 muestra la sintaxis del archivo "info.dvr". El archivo "info.dvr" está compuesto por tres objetos, es decir, DVRVolume(), TableOfPlayLists() y MakersPrivateData().

60 Se explica la sintaxis de info.dvr que se muestra en la Fig. 15. La TableOfPlayLists_Start_adress (Dirección_inicio_TablaDeListasReproducción) indica la dirección inicial de la TableOfPlayLists() en términos del número relativo de bytes desde el byte inicial del archivo "info.dvr". El número relativo de bytes se cuenta comenzando desde 0.

La MakersPrivateData_Start_address (Dirección_inicio_DatosPrivadosFabricante) indica la dirección inicial del MakersPrivateData(), en términos del número relativo de bytes desde el byte inicial del archivo "info.dvr". El número relativo de bytes se cuenta desde 0. La padding_word (palabra_relleno) se inserta en asociación con la sintaxis de "info.dvr". N1 y N2 son enteros positivos opcionales. Cada palabra de relleno puede adoptar un valor opcional.

El DVRVolume() (VolumenDVR()) almacena la información que expresa el contenido del volumen (disco). La Fig. 16 muestra la sintaxis del DVRVolume. Se explica a continuación la sintaxis del DVRVolume(), mostrada en la Fig. 16. El version_number (número_versión) indica cuatro letras que indican los números de versión del DVRVolume(). El version_number se codificar en "0045" en asociación con la ISO646.

La longitud se indica mediante enteros sin signo de 32 bits que indican el número de bytes desde directamente después del campo de longitud al extremo final de DVRVolume().

El ResumeVolume() (VolumenReanudación()) memoriza el nombre de archivo de la Real PlayList o la Virtual PlayList reproducida en el Volume. Sin embargo, la posición de reproducción cuando el usuario ha interrumpido la reproducción de la Real PlayList o la Virtual PlayList se almacena en la marca de reanudación definida en la PlayListMark() (MarcaListaReproducción()) (veánse Figs. 42 y 43).

La Fig. 17 muestra la sintaxis del ResumeVolume(). Se explica la sintaxis del ResumeVolume () mostrado en la Fig.

17. La valid_flag (bandera_válida) indica que el campo resume_PlayList_name (nombre_ListaReproducción_reanudación) es válido o no válido cuando esta bandera de 1 bit se fija a 1 ó 0, respectivamente.

El campo de 10 bytes de resume_PlayList_name indica el nombre de archivo de la Real PlayList o la Virtual PlayList a reanudar.

El UIAppInfoVolume en la sintaxis del DVRVolume(), mostrado en la Fig. 16, almacena parámetros de la aplicación de interfaz de usuario referentes al Volume. La Fig. 18 muestra la sintaxis de UIAppInfoVolume, cuya semántica se explica a continuación. El campo de 8 bits de character_set (conjunto_caracteres) indica el método de codificación para letras de carácteres codificadas en el campo Volume_name (Nombre_volumen). El método de codificación se corresponde con los valores mostrados en la Fig. 19.

El campo de 8 bits de la name_length (longitud_nombre) indica la longitud en bytes del nombre de Volume indicado en el campo Volume_name. El campo Volume_name indica la denominación del Volume. El número de bytes del número de la name_length contados desde la izquierda del campo es el número de caracteres válidos e indica la denominación del volumen. Los valores que siguen a cotinuación de estas letras de caracteres válidas pueden ser cualesquiera valores.

La Volume_protect_flag (Bandera_protección_volumen) es una bandera que indica si el contenido en el Volume se puede mostrar o no al usuario sin limitaciones. Si esta bandera se fija a 1, se permite que el contenido del Volume se presente (reproduzca) al usuario solamente en el caso de que el usuario haya introducido correctamente con éxito el número PIN (contraseña). Si esta bandera se fija a 0, se permite que el contenido del Volume se presente al usuario incluso en el caso de que el número PIN no sea introducido por el usuario.

Si, cuando el usuario ha insertado un disco en un reproductor, esta bandera se ha fijado a 0, o la bandera se fija a 1 pero el usuario ha introducido correctamente con éxito el número PIN, el aparato de grabación y/o reproducción 1 muestra una lista de la PlayList en el disco. Las limitaciones sobre la reproducción de las PlayLists respectivas son irrelevantes para la Volume_protect_flag y se indican mediante la playback_control_flag (bandera_control_reproducción) definida en el UIAppInfoVolume.

El PIN está compuesto por cuatro cifras numéricas de 0 a 9, cada una de las cuales se codifica de acuerdo con la ISO/IEC 646. El campo ref_thumbnail_index (índice_imagenMiniatura_ref) indica la información de una imagen en miniatura añadida al Volume. Si el campo ref_thumbnail_index es de un valor diferente a 0xFFFF, se añade una imagen en miniatura al Volume. La imagen en miniatura se almacena en un archivo menu.thumb. Se remite a la imagen usando el valor del ref_thumbnail_index en el archivo menu.thumb file. Si el campo ref_thumbnail_index es 0xFFFF, ello indica que se ha añadido al Volume una imagen en miniatura.

Se explica la sintaxis de TableOfPlayList() en el info.dvr que se muestra en la Fig. 15. La TableOfPlayList() almacena el nombre de archivo de la PlayList (Real PlayList y Virtual PlayList). Todos los archivos de PlayList grabados en el Volume están contenidos en la TableOfPlayList(), indicando dicha TableOfPlayList() la secuencia de reproducción por defecto de la PlayList en el Volume.

La Fig. 20 muestra la sintaxis de la TableOfPlayList(), la cual se explica a continuación. El version_number de la TableOfPlayList() indica cuatro letras de caracteres que indican los números de versión de las TableOfPlayLists. El version_number se debe codificar en "0045" de acuerdo con la ISO 646.

La longitud es un entero sin signo de 32 bits que indica el número de bytes de la TableOfPlayList() desde directamente después del campo de longitud al extremo final de la TableOfPlayList(). El campo de 16 bits del number_of_PlayLists (número_de_ListasReproducción) indica el número de ciclos correspondiente al bucle “para” incluyendo el PlayList_file_name (nombre_archivo_ListaReproducción). Esta cifra numérica debe ser igual al número de PlayLists grabadas en el Volume. La cifra numérica de 10 bytes del PlayList_file_name indica el nombre de archivo de las PlayLists.

La Fig. 21 muestra otra configuración de la sintaxis de la TableOfPlayList(). La sintaxis mostrada en la Fig. 21 está compuesta por la sintaxis mostrada en la Fig. 20 en la cual está contenida la UIAppInfoPlayList. Mediante una estructura tal que incluye la UIAppInfoPlayList, resulta posible crear una imagen de menú simplemente al leer las TableOfPlayLists. La siguiente explicación adopta como premisa el uso de la sintaxis mostrada en la Fig. 20.

Se explica el MakersPrivateData en el info.dvr mostrado en la Fig. 15. El MakersPrivateData se proporciona para permitir al fabricante del aparato de grabación y/o reproducción 1 que inserte datos privados del fabricante en el MakersPrivateData() para aplicaciones especiales de diferentes compañías. Los datos privados de cada fabricante tienen un maker_ID (ID_fabricante) normalizado para identificar el fabricante que lo ha definido. El MakersPrivateData() puede contener uno o más maker_ID.

Si un fabricante preestablecido pretende insertar datos privados, y los datos privados de un fabricante diferente ya están contenidos en el MakersPrivateData(), los nuevos datos privados se añaden al MakersPrivateData() sin borrar los datos privados antiguos preexistentes. De esta manera, en la presente forma de realización, los datos privados de diversos fabricantes pueden estar contenidos en un MakersPrivateData().

La Fig. 22 muestra la sintaxis del MakersPrivateData. Se explica la sintaxis del MakersPrivateData mostrado en la Fig. 22. El version_number de la TableOfPlayList() indica cuatro letras de caracteres que indican los números de versión de las TableOfPlayLists. El version_number se debe codificar en "0045" de acuerdo con la ISO 646. La longitud es un entero de 32 bits sin signo que indica el número de bytes de la TableOfPlayList() desde directamente después del campo de longitud al extremo final del MakersPrivateData().

La mpd_blocks_start_address (dirección_inicio_bloques_mpd) indica la dirección del extremo inicial del primer mpd_block() en términos del número relativo de bytes desde el byte inicial del MakersPrivateData(). El number_of_maker_entries (número_de_entradas_fabricante) es el entero de 16 bits sin código que proporciona el número de entradas de los datos privados del fabricante incluidos en el MakersPrivateData(). No debe haber presentes dos o más datos privados de fabricante que tengan los mismos valores del maker_ID en el MakersPrivateData().

El mpd_blocks_size (tamaño_bloques_mpd) es un entero sin signo de 16 bits que proporciona un tamaño del mpd_block en términos de 1.024 bytes como una unidad. Por ejemplo, si el mpd_block_size = 1, ello indica que el tamaño de un mpd_block es 1.024 bytes. El number_of_mpd_blocks (número_de_bloques_mpd) es un entero sin signo de 16 bits que proporciona el número de mpd_blocks contenidos en el MakersPrivateData(). El maker_ID es el entero sin signo de 16 bits que indica el código del número de modelo del sistema de DVR que ha creado los datos privados del fabricante. El valor codificado en el maker_ID es especificado por el licenciante.

El maker_model_code (código_modelo_fabricante) es un entero sin signo de 16 bits que indica el código del número de modelo del sistema de DVR que ha creado los datos privados del fabricante. El valor codificado en el maker_model_code lo fija el fabricante que ha recibido la licencia del formato. El start_mpd_block_number (número_bloque_mpd_inicio) es un entero sin signo de 16 bits que indica el número del número de mpd_block en el cual comienzan los datos privados del fabricante. El extremo inicial de los datos privados del fabricante debe estar alineado con el extremo inicial del mpd_block. El start_mpd_block_number se corresponde con una variable j en el bucle “para” del mpd_block.

La mpd_length (longitud_mpd) es un entero de 32 bits sin signo que indica el tamaño de los datos privados del fabricante. El mpd_block es un área en la cual se almacenan datos privados del fabricante. Todos los mpd_blocks en el MakersPrivateData() deben ser del mismo tamaño.

Se explican el archivo de Real PlayList y el archivo de Virtual PlayList, en otras palabras xxxxx.rpls e yyyyy.vpls. La Fig. 23 muestra la sintaxis de xxxxx.rpls (Real PlayList) e yyyyy.vpls (Virtual PlayList), los cuales tienen la misma estructura de sintaxis. Cada uno de xxxxx.rpls e yyyyy.vpls está compuesto por tres objetos, es decir, PlayList(), PlayListMark() y MakersPrivateData().

La PlayListMark_Start_address (Dirección_inicio_MarcaListaReproducción) indica la dirección inicial de la PlayListMark(), en términos del número relativo de bytes desde el extremo inicial del archivo de PlayList como una unidad. El número relativo de bytes se cuenta desde cero.

La MakersPrivateData_Start_address indica la dirección inicial del MakersPrivateData(), en términos del número relativo de bytes desde el extremo inicial del archivo de la PlayList como una unidad. El número relativo de bytes se cuenta desde cero.

La padding_word (palabra de relleno) se inserta de acuerdo con la sintaxis del archivo de la PlayList, siendo N1 y N2 enteros positivos opcionales. Cada palabra de relleno puede adoptar un valor opcional.

La PlayList se explicará de forma adicional seguidamente aunque ha sido explicada de manera breve. A un dominio de reproducción en todos los Clips excepto el Fragmento-Puente deben remitir todas las PlayList en el disco. Además, dos o más Real PlayLists no deben solaparse con los dominios de reproducción mostrados por sus PlayItems en el mismo Clip.

Se hace referencia a las Figs. 24A, 24B y 24C. Para todos los Clips, existen Real PlayLists correspondientes, tal como se muestra en la Fig. 24A. Esta regla se observa incluso después de que la operación de edición haya llegado a su fin, tal como se muestra en la Fig. 24B. Por lo tanto, todos los Clips se deben visualizar por remisión a una de las Real PlayLists.

En referencia a la Fig. 24C, el dominio de reproducción de la Virtual PlayList debe estar contenido en el dominio de reproducción y en el dominio de reproducción de Fragmento-Puente. No debe haber presentes en el disco, ningún Fragmento-Puente al que no remita ninguna Virtual PlayList.

La Real PlayList, que contiene la lista del Playltem, no debe contener SubPlayltem. La Virtual PlayList contiene la lista de Playltem y, si el CPI_type contenido en la PlayList() es el tipo EP_map y el PlayList_type es 0 (PlayList que contiene vídeo y audio), la Virtual PlayList puede contener un SubPLayltem. En la PlayList() en la presente forma de realización, el SubPlayltem se usa únicamente para la post-grabación de audio. El número de los SubPlayItems poseídos por una Virtual PlayList debe ser 0 ó 1.

En lo sucesivo se explica en la presente la PlayList. La Fig. 25 muestra la sintaxis de la PlayList la cual se explica a continuación. El version_number indica cuatro letras de caracteres que indican los números de versión de la PlayList(). El version_number se codificar en "0045" en asociación con la ISO 646. La longitud es un entero sin signo de 32 bits que indica el número total de bytes de la PlayList()desde directamente después del campo de longitud al extremo final de la PlayList(). El PlayList_type, un ejemplo del cual se muestra en la Fig. 26, es un campo de 8 bits que indica el tipo de la PlayList.

CPI_type es una bandera de un bit que indica el valor del CPI_type del Clip al que remite el Playltem() y el SubPlayltem(). Los CPI_types definidos en los CPIs de todos los Clips a los que remite una PlayList, deben ser de los mismos valores. El number_of_PlayItems (número_de_ElementosReproducción) es un campo de 16 bits que indica el número de Playltems presentes en la PlayList.

El PlayItem_id (id_ElementoReproducción) que se corresponde con el Playltem() preestablecido se define por la secuencia en la cual aparece el Playltem() en el bucle “para” que contiene el Playltem(). El Playltem_id comienza con 0. El number_of_SubPlayItems (número_de_SubElementosReproducción) es un campo de 16 bits que indica el número de SubPlayltem en la PlayList. Este valor es 0 ó 1. Una ruta del flujo continuo de audio adicional (ruta del flujo continuo de audio) es una clase de sub-ruta.

Se explica la UIAppInfoPlayList de la sintaxis de la PlayList mostrada en la Fig. 25. La UIAppInfoPlayList almacena parámetros de la aplicación de interfaz de usuario que se refieren a la PlayList. La Fig. 27 muestra la sintaxis de la UIAppInfoPlayList, la cual se explica a continuación. El character_set (conjunto_caracteres) es un campo de 8 bits que indica el método para codificar letras de caracteres codificadas en el campo PlayList_name (nombre_ListaReproducción). El método de codificación se corresponde con los valores que se ajustan a la tabla mostrada en la Fig. 19.

La name_length es un campo de 8 bits que indica la longitud en bytes del nombre de la PlayList indicado en el campo PlayList_name. El campo PlayList_name muestra la denominación de la PlayList. El número de bytes del número de la name_length, contados desde la izquierda del campo, es el número de caracteres válidos e indica la denominación de la PlayList. Los valores que van a continuación de estas letras de caracteres válidas pueden ser cualesquiera valores.

El record_time_and_date (hora_y_fecha_grabación) es un campo de 56 bits que almacena la fecha y la hora en las cuales se grabó la PlayList. Este campo es 14 cifras numéricas para año/mes/día/hora/minuto/segundo codificados en decimales codificados binarios (BCD). Por ejenplo, 2001/12/23:01:02:03 se codifica en "0x20011223010203".

La duración es un campo de 24 bits que indica el tiempo total de reproducción de la PlayList en términos de hora/minuto/segundo como una unidad. Este campo es seis cifras numéricas codificadas en decimales codificados binarios (BCD). Por ejemplo, 01:45:30 se codifica en "0x014530".

El valid_period (periodo_válido) es un campo de 32 bits que indica los periodos de tiempo válidos de la PlayList. Este campo es 8 cifras numéricas codificadas en decimales codificados binarios (BCD) de 4 bits. El valid_period se usa en el aparato de grabación y/o reproducción 1, por ejemplo cuando la PlayList, para la cual el periodo válido ha transcurrido, se vaya a borrar automáticamente. Por ejemplo, 2001/05/07 se codifica en "0x20010507".

El maker_ID es un entero de 16 bits sin signo que indica el fabricante del reproductor de DVR (el aparato de grabación y/o reproducción 1) que ha sido el último en actualizar su PlayList. El valor codificado en maker_ID se asigna al licenciatario del formato de DVR. El maker_code (código_fabricante) es un entero de 16 bits sin signo que indica el número de modelo de reproductor de DVR que ha sido el último en actualizar la PlayList. El valor codificado en el maker_code es determinado por el fabricante que ha recibido la licencia del formato de DVR.

Si la bandera de la playback_control_flag se fija a 1, su PlayList se reproduce solamente cuando el usuario introduce exitosamente el número de PIN. Si esta bandera se fija a 0, el usuario puede visualizar la PlayList sin la necesidad de introducir el número de PIN.

Si la write_protect_flag (bandera_protección_escritura) se fija a 1, el contenido de la PlayList no se borra ni se cambia excepto la write_protect_flag. Si esta bandera se fija a 0, es usuario es libre de borrar o cambiar la PlayList. Si esta bandera se fija a 1, el aparato de grabación y/o reproducción 1 muestra un mensaje que solicita la reconfirmación por parte del usuario antes de que el usuario proceda a borrar, editar o sobrescribir la PlayList.

La Real PlayList, en la cual la write_protect_flag se fija a 0, puede existir, la Virtual PlayList, que remite al clip de la PlayList puede existir, y la write_protect_flag de la Virtual PlayList se puede fijar a 1. Si el usuario desea borrar la Real PlayList, el aparato de grabación y/o reproducción 1 emite una alarma al usuario en relación con la presencia de la Virtual PlayList mencionada anteriormente, o "minimiza" la Real PlayList antes de borrar la Real PlayList.

Si is_played_flag (bandera_se_ha_reproducido) se fija a 1, tal como se muestra en la Fig. 28B, ello indica que la PlayList se reprodujo al menos una vez desde que se grabó, mientras que si se fija a 0, ello indica que la PlayList no se reprodujo ni siquiera una vez desde que se grabó.

Archive (Archivo) es un campo de dos bits que indica si la PlayList es un original o una copia, tal como se muestra en la Fig. 28C. El campo de ref_thumbnail_index indica la información de una imagen en miniatura representativa de la PlayList. Si el campo ref_thumbnail_index es de un valor diferente a 0xFFFFF, en la PlayList se añade una imagen en miniatura representativa de la PlayList, almacenándose la PlayList en el archivo menu.thmb. Se remite a la imagen usando el valor de ref_thumbnail_index en el archivo menu.thmb. Si el campo ref_thumbnail_index es 0xFFFF, en la PlayList no se añade ninguna imagen en miniatura representativa de la PlayList.

En lo sucesivo se explica en la presente el Playltem. Un Playltem() contiene básicamente los siguientes datos: Clip_Information_file_name (nombre_archivo_Información_Fragmento) para especificar el nombre de archivo del Clip, IN-time y OUT-time, emparejados entre sí para especificar el dominio de reproducción de Clip, STC_sequence_id (id_secuencia_STC) al que remiten IN-time y OUT-time en caso de que el CPI_type definido en PlayList() sea el tipo EP_map, y Connection_Condition que indica la condición de conexión del Playltem previo y el Playltem actual.

Si la PlayList está compuesta por dos o más Playltems, estos Playltems se disponen en una fila, sin solapamiento o separación temporal, en el eje de tiempo global de la PlayList. Si el CPI_type definido en la PlayList es el tipo EP_map y la PlayList actual no tiene la BridgeSequence(), el par IN-time y OUT-time debe indicar el mismo tiempo en el dominio continuo de STC que el especificado por el STC_sequence_id. Dicho caso se muestra en la Fig. 29.

La Fig. 30 muestra un caso tal en el que el CPI_type definido por PlayList() y, si el Playltem actual tiene la BridgeSequence(), se aplican las reglas según se explica a continuación. El IN_time del Playltem previo al Playltem actual, mostrado como IN_time1, indica el tiempo en el Fragmento-Puente especificado en la BridgeSequencelnfo() del Playltem actual. Este OUT_time debe obedecer a las limitaciones de codificación que se explicarán posteriormente.

El IN_time del Playltem actual, mostrado como IN_time2, indica el tiempo en el Fragmento-Puente especificado en la BridgeSequencelnfo() del Playltem actual. Este IN_time también debe obedecer a las limitaciones de codificación tal como se explica posteriormente. El OUT_time de Playltem correspondiente al Playltem actual, mostrado como OUT_time2, indica el tiempo en el dominio continuo de STC especificado por STC_sequence_id del Playltem actual.

Si el CPI_type de PlayList() es el tipo TU_map, el IN_time y el OUT_time de Playltem, emparejados entre sí, indican el tiempo en el mismo Flujo continuo AV de fragmento, tal como se muestra en la Fig. 31.

La sintaxis del Playltem es tal como se muestra en la Fig. 32. En cuanto a la sintaxis del Playltem, mostrada en la Fig. 32, el campo del Clip_Information_file_name indica el nombre de archivo de Información de Fragmento. El Clip_stream_type definido por la ClipInfo() de este archivo de Información de Fragmento debe indicar el Flujo continuo AV de fragmento.

El STC_sequence_id es un campo de 8 bits e indica el STC_sequence_id del dominio de STC continuo al que remite el Playltem. Si el CPI_type especificado en la PlayList() es el tipo TU_map, este campo de 8 bits no tiene significado y se fija a 0. El IN_time es un campo de 32 bits y se usa para almacenar el tiempo de inicio de la reproducción de Playltem. La semántica del IN_time difiere con el CPI_type definido en la PlayList(), tal como se muestra en la Fig.

33.

El OUT_time S es un campo de 32 bits y se usa para aImacenar el tiempo final de la reproducción del Playltem. La semántica del OUT_time difiere del CPI_type definido en la PlayList(), tal como se muestra en la Fig. 34.

La Connection_condition es un campo de 2 bits que indica la condición de conexión entre el Playltem previo y el Playltem actual, tal como se muestra en la Fig. 35. Las Figs. 36A a 36D ilustran varios estados de la Connection_condition mostrada en la Fig. 35.

Se explica BridgeSequencelnfo en referencia a la Fig. 37. Esta BridgeSequencelnfo es la información auxiliar del Playltem actual e incluye la siguiente información. Es decir, BridgeSequencelnfo incluye Bridge_Clip_Information_file_name (nombre_archivo_Información_Fragmento_Puente) para especificar el archivo AV del Bridge_Clip y un Bridge_Clip_Information_file_name que especifica el archivo de Información de Fragmento correspondiente (Fig. 45).

Es también una dirección de un paquete fuente en el Flujo continuo AV de fragmento al que remite el Playltem previo. Junto a este paquete fuente está conectado el primer paquete fuente del flujo continuo AV de Fragmento-Puente. A esta dirección se le denomina RSPN_exit_from_previous_Clip (RSPN_salida_de_Fragmento_previo). Es también una dirección del paquete fuente en el Flujo continuo AV de fragmento al que remite el Playltem actual. Delante de este paquete fuente se conecta el último paquete fuente del archivo de flujo continuo AV del Bridge_Clip. A esta dirección se le denomina RSPN_enter_to_current_Clip (RSPN_entrada_a_Fragmento_actual).

En la Fig. 37, la RSPN_arrival_time_discontinuity (RSPN_discontinuidad_tiempo_llegada) indica una dirección de un paquete fuente en el flujo continuo AV del Bridge_Clip donde existe un punto discontinuo en la base de tiempos de llegada. Esta dirección se define en el ClipInfo() (Fig. 46).

La Fig. 38 muestra la sintaxis de la BridgeSequencelnfo (InfoSecuenciaPuente). Volviendo a la sintaxis de BridgeSequencelnfo mostrada en la Fig. 38, el campo del Bridge_Clip_Information_file_name indica el nombre de archivo del archivo de Información de Fragmento que se corresponde con el Bridge_Clip_Information_file. El Clip_stream_type definido en la ClipInfo() de este archivo de Información de Fragmento debe indicar el 'flujo continuo AV del Bridge_Clip'.

El campo de 32 bits de RSPN_exit_from_previous_Clip es una dirección relativa de un paquete fuente en el Flujo continuo AV de fragmento al que remite el Playltem previo. Junto a este paquete fuente se conecta el primer paquete fuente del archivo de flujo continuo AV del Bridge_Clip. La RSPN_exit_from_previous_Clip tiene un tamaño basado en el número del paquete fuente como una unidad, y se cuenta con el valor del offset_SPN definido en la ClipInfo() a partir del primer paquete fuente del archivo de Flujo continuo AV de fragmento al que remite el Playltem previo.

El campo de 32 bits de RSPN_enter_to_current_Clip es la dirección relativa del paquete fuente en el Flujo continuo AV de fragmento al que remite el Playltem actual. Delante de este paquete fuente se conecta el último paquete fuente del archivo de flujo continuo AV del Bridge_Clip. La RSPN_enter_to_current_Clip tiene un tamaño que se basa en el número del paquete fuente como una unidad. La RSPN_enter_to_current_Clip se cuenta con el valor del offset_SPN, definido en la ClipInfo() desde el primer paquete fuente del archivo de Flujo continuo AV de fragmento al que remite el Playltem actual, como valor inicial.

El SubPlayltem se explica en referencia a la Fig. 39. El uso del SubPlayltem() se permite solamente si el CPI_type de la PlayList() es el tipo EP_map. En la presente forma de realización, el SubPlayltem se usa solamente para la post-grabación de audio. El SubPlayltem() incluye los siguientes datos. En primer lugar, incluye el Clip_Information_file_name para especificar el Clip al que remite la sub-ruta en la PlayList.

También incluye el SubPath_IN_time (tiempo_ENTRADA_SubPath) y el SubPath_OUT_time (tiempo_SALIDA_SubPath) para especificar el dominio de reproducción de la sub-ruta en el Clip. Adicionalmente incluye el sync_PlayItem_id y el start_PTS_of_PlayItem (PTS_inicio_de_ElementoReproducción) para especificar el tiempo de inicio de la reproducción de la sub-ruta en el eje de tiempo de la ruta principal. El Flujo continuo AV de fragmento, al que remite la sub-ruta, no debe contener puntos discontinuos de STC (puntos discontinuos de la base de tiempos del sistema). Los relojes de muestras de audio del Clip usado en la sub-ruta se enganchan con los relojes de las muestras de audio de la ruta principal.

La Fig. 40 muestra la sintaxis del SubPlayltem. Volviendo a la sintaxis del SubPlayltem, mostrado en la Fig. 40, el campo del Clip_Information_file_name indica el nombre de archivo del archivo de Información de Fragmento y es

usado por una sub-ruta en la PlayList. El Clip_stream_type (tipo_flujoContinuo_Fragmento) definido en esta ClipInfo() debe indicar el Flujo continuo AV de fragmento.

Un campo de 8 bits del sync_PlayItem_id indica el tipo de sub-ruta. En este caso, solamente se establece '0x00', tal como se muestra en la Fig. 41, mientras que otros valores se reservan para un uso futuro.

El campo de 8 bits de sync_PlayItem_id indica el PlayItem_id del Playltem que contiene el tiempo de inicio de reproducción de la sub-ruta en el eje de tiempo de la ruta principal. El valor de Playltem_id correspondiente al Playltem preestablecido se define en la PlayList() (Fig. 25).

Un campo de 32 bits de sync_start_PTS_of_PlayItem (PTS_inicio_sinc_de_ElementoReproducción) indica el tiempo de inicio de reproducción de la sub-ruta en el eje de tiempo de la ruta principal, e indica los 32 bits superiores de la PTS (marca de tiempo de presentación) en el Playltem al que remite el sync_PlayItem_id. El campo de 32 bits superiores del SubPath_IN_time almacena el tiempo de inicio de la reproducción de la sub-ruta. La SubPath_IN_time indica 32 bits superiores de la PTS de 33 bits que se corresponde con la primera unidad de presentación en la sub-ruta.

El campo de 32 bits superiores de SubPath_OUT_time almacena el tiempo final de la reproducción de la sub-ruta. SubPath_OUT_time indica 32 bits superiores del valor de la Presentation_end_TS (TS_fin_presentación), calculado mediante la siguiente ecuación:

Presentation_end_TS = PTS_OUT (PTS_SALIDA) + AU_duration (duración_AU)

donde PTS_out es la PTS de 33 bits de longitud correspondientes a la última unidad de presentación de la SubPath y AU_duration es el periodo de visualización basado en 90 kHz de la última unidad de presentación de la SubPath.

A continuación, se explica PlayListMark() en la sintaxis de xxxxx.rpls e yyyyy.vpls mostrada en la Fig. 23. La información de marca pertinente de la PlayList se almacena en esta PlayListMark. La Fig. 42 muestra la sintaxis de PlayListMark. Volviendo a la sintaxis de la PlayListMark mostrada en la Fig. 42, el version_number es cuatro letras de caracteres que indican el número de versión de esta PlayListMark(). El version_number se debe codificar en "0045" de acuerdo con la ISO 646.

Longitud es un entero sin signo de 32 bits que indica el número de bytes de PlayListMark() desde directamente después del campo de longitud al extremo final de la PlayListMark(). El number_of_PlayListMarks es un entero sin signo de 16 bits que indica el número de marcas almacenadas en la PlayListMark. El number_of_PlayListMarks puede ser cero. El mark_type es un campo de 8 bits que indica el tipo de la marca y se codifica en la tabla mostrada en la Fig. 43.

Un campo de 32 bits de mark_time_stamp almacena una indicación de tiempo que indica el punto especificado por la marca. La semántica de la mark_time_stamp difiere con el CPI_type definido en la PlayList(), tal como se muestra en la Fig. 44. El Playltem_id es un campo de 8 bits que especifica el Playltem donde se coloca la marca. Los valores de PlayItem_id que se corresponde con un Playltem preestablecido se definen en la PlayList () (véase la Fig. 25).

Un campo de 8 bits de character_set muestra el método de codificación de letras de caracteres codificadas en el campo de mark_name. El método de codificación se corresponde con valores mostrados en la Fig. 19. El campo de 8 bits de name_length indica la longitud en bytes del nombre de la marca mostrado en el campo mark_name. El campo mark_name indica el nombre de la marca indicado en el campo mark_name. El número de bytes que se corresponde con el número de name_lengths desde la izquierda de este campo es las letras de caracteres efectivas e indica el nombre de la marca. En el campo mark_name, el valor que va a continuación de estas letras de caracteres efectivas puede ser arbitrario.

El campo del ref_thumbnail_index indica la información de la imagen en miniatura añadida a la marca. Si el campo del ref_thumbnail_index no es 0xFFFF, se añade una imágen en miniatura a su marca, almacenándose la imágen en miniatura en el archivo mark.thmb. Se remite a esta imagen en el archivo mark.thmb, usando el valor de ref_thumbnail_index, como se explica posteriormente. Si el campo ref_thumbnail_index es 0xFFFF, ello indica que no se añade ninguna imagen en miniatura a la marca.

Se explica a continuación el archivo de Información de Fragmento. El zzzzz.clpi (archivo de Información de Fragmento) está compuesto por seis objetos, tal como se muestra en la Fig. 45. Estos son Cliplnfo(), STC_Info(), Program(), CPI(), ClipMark() y MakersPrivateData(). Para el flujo continuo AV (Flujo continuo AV de fragmento o flujo continuo AV de Fragmento-Puente) y el archivo de Información de Fragmento correspondiente, se usa la misma cadena de números "zzzzz".

Volviendo a la sintaxis de zzzzz.clpi (archivo de Información de Fragmento) mostrado en la Fig. 45, se explica la misma. La Cliplnfo_Start_address indica la dirección del extremo inicial de ClipInfo() con el número relativo de bytes

desde el byte del extremo inicial del archivo zzzzz.clpi como una unidad. El número relativo de bytes se cuenta desde cero.

La STC_Info_Start_address (Dirección_inicio_Info_STC) indica la dirección del extremo inicial de STC_Info, con el número relativo de bytes desde el byte del extremo inicial del archivo zzzzz.clpi como unidad. La Programlnfo_Start_address (Dirección_inicio_InfoProgram) indica la dirección del extremo inicial de Programlnfo() con el número relativo de bytes desde el byte del extremo inicial del archivo zzzzz.clpi como unidad. El número relativo de bytes se cuenta desde 0. La CPI_Start_address (Dirección_inicio_CPI) indica la dirección del extremo inicial de CPI() con el número relativo de bytes desde el byte del extremo inicial del archivo zzzzz.clpi como unidad. El número relativo de bytes se cuenta desde cero.

La ClipMark_Start_address (Dirección_inicio_MarcaFragmento) indica la dirección del extremo inicial de ClipMark() con el número relativo de bytes desde el byte del extremo inicial del archivo zzzzz.clpi como unidad. El número relativo de bytes se cuenta desde cero. La MakersPrivateData_Start_address indica la dirección del extremo inicial de MakersPrivateData() con el número relativo de bytes desde el byte del extremo inicial del archivo zzzzz.clpi como una unidad. El número relativo de bytes se cuenta desde cero. La padding_word se inserta de acuerdo con la sintaxis del archivo zzzzz.clpi. N1, N2, N3, N4 y N5 deben ser cero o enteros positivos opcionales. Las palabras de relleno respectivas también adoptan valores opcionales.

Se explica a continuación la Cliplnfo. La Fig. 46 muestra la sintaxis de Cliplnfo. La Fig. 46 muestra la sintaxis de Cliplnfo. En la ClipInfo() se almacena la información de atributos de archivos de flujo continuo AV correspondientes (archivo de Flujo continuo AV de fragmento o archivo de Flujo continuo AV de Fragmento-Puente).

Volviendo a la sintaxis del Cliplnfo mostrado en la Fig. 46, el version_number es las cuatro letras de caracteres que indican el número de versión de este ClipInfo(). El version_number se debe codificar en "0045" de acuerdo con la ISO 646. Longitud es un entero de 32 bits sin signo que indica el número de bytes de Cliplnfo() desde directamente detrás del campo de longitud al extremo final del ClipInfo(). Un campo de 8 bits de Clip_stream_type indica el tipo del flujo continuo AV que se corresponde con el archivo de Información de Fragmento, tal como se muestra en la Fig.

47. Los tipos de flujo continuo de los flujos continuos AV respectivos se explicarán posteriormente.

El campo de 32 bits de offset_SPN proporciona un valor de desplazamiento del número de paquete fuente correspondiente al primer número de paquete fuente del primer paquete fuente del flujo continuo AV (Flujo continuo AV de fragmento o el flujo continuo AV de Fragmento-Puente). Cuando el archivo de flujo continuo AV se graba en primer lugar en el disco, este offset_SPN debe ser cero.

En referencia a la Fig. 48, cuando la porción de comienzo del archivo de flujo continuo AV se borra mediante edición, offset_SPN puede adoptar un valor diferente a 0. En la presente forma de realización, el número relativo de paquete fuente (dirección relativa) que remite al offset_SPN se describe frecuentemente en forma de RSPNxxx, donde xxx se modifica de manera tal que RSPN_xxx es RSPN_EP_start. El número relativo de paquete fuente se dimensiona con el número de paquete fuente como unidad y se cuenta desde el número del primer paquete fuente del archivo de flujo continuo AV con el valor del offset_SPN como valor inicial.

El número de paquetes fuente desde el primer paquete fuente del archivo de flujo continuo AV al paquete fuente al que remite el número de paquete fuente relativo (SPN_xxx) se calcula por la siguiente ecuación:

SPN_xxx = RSPN_xxx - offset_SPN.

La Fig. 48 muestra un ejemplo en el cual offset_SPN es 4.

TS_recording_rate es un entero de 24 bits sin signo, el cual proporciona una velocidad de bits de entrada/salida requerida para el flujo continuo AV a la unidad controladora de DVR (unidad de escritura 22) o desde la unidad controladora de DVR (unidad de lectura 28). El record_time_and_date es un campo de 56 bits para almacenar la fecha y hora de grabación del flujo continuo AV correspondiente al Clip y es una representación codificada de año/mes/dia/hora/minuto en decimales codificados binarios (BCD) de 4 bits para 14 cifras numéricas. Por ejemplo 2001/2/23:01:02:03 se codifica en "0x20011223010203".

La duración es un campo de 24 bits que indica el tiempo total de reproducción del Clip mediante hora/minuto/segundo, sobre la base de relojes del tiempo de llegada. Este campo es seis cifras numéricas codificadas en decimales codificados binarios (BCD) de 4 bits. Por ejemplo, 01:45:30 se codifica en "0x014530"

Una bandera time_controlled_flag (bandera_tiempo_controlado) indica el modo de grabación de un archivo de flujo continuo AV. Si esta time_controlled_flag es 1, ello indica que el modo de grabación es un modo tal en el cual el tamaño del archivo es proporcional al tiempo transcurrido desde la grabación, de manera tal que la condición mostrada por la siguiente ecuación:

Ts_average_rate*192/188*(t - start_time)- a <= size_clip(t)

<= TS_average_rate *192/188*(t - start_tme) + a

donde TS_average_rate (velocidad_promedio_TS) es una velocidad promedio en bits del flujo continuo de transporte del archivo de flujo continuo AV expresada mediante bytes/segundo.

En la ecuación anterior, t indica el tiempo en segundo, mientras que start_time (tiempo_inicio) es el instante de tiempo en el que se grabó el primer paquete fuente del archivo de flujo continuo AV. El size_clip(t) es 10*192 bytes y a es una constante que depende de TS_average_rate.

Si time_controlled_flag se fija a 0, ello indica que el modo de grabación no está controlando de manera tal que el transcurso de tiempo de la grabación es proporcional al tamaño de archivo del flujo continuo AV. Por ejemplo, el flujo continuo de transporte de entrada se graba de una manera transparente.

Si time_controlled_flag se fija a 1, el campo de 24 bits de TS_average_rate indica el valor de TS_average_rate usado en la ecuación anterior. Si time_controlled_flag se fija a 0, este campo no tiene significado y se debe fijar a 0. Por ejemplo, el flujo continuo de transporte de velocidad de bits variable se codifica mediante la siguiente secuencia: En primer lugar, la velocidad de transporte se fija al valor de TS_recording_rate (velocidad_grabación_TS). El flujo continuo de vídeo se codifica con una velocidad de bits variable. El paquete de transporte se codifica intermitentemente sin utilizar paquetes nulos.

El campo de 32 bits de RSPN_arrival_time_discontinuity es una dirección relativa de un sitio donde en el archivo de flujo continuo AV de Fragmento-Puente se producen discontinuidades de la base de tiempos de llegada. El RSPN_arrival_time_discontinuity se dimensiona con el número de paquetes fuente como unidad y se cuenta con el valor de offset_SPN definido en el ClipInfo() desde el primer paquete fuente del archivo de flujo continuo AV de Fragmento-Puente. Una dirección absoluta en el archivo de flujo continuo AV de Fragmento-Puente se calcula sobre la base de la ecuación mencionada anteriormente:

SPN_xxx = RSPN_xxx - offset_SPN.

El campo de 144 bits de reserved_for_system_use (reservado_para_uso_sistema) se reserva para un sistema. Si la bandera is_format_identifier_valid (identificador_formato_es_válido) es 1, ello indica que el campo de format_identifier (identificador_formato) es efectivo. Si la bandera is_format_identifier_valid es 1, ello indica que el campo de format_identifier es válido. Si la bandera is_original_network_ID_valid (ID_red_original_es_válido) es 1, ello indica que el campo de is_transport_stream_ID_valid (ID_flujoContinuo_transporte_es_válido) es válido. Si la bandera is_transport_stream_ID_valid es 1, ello indica que el campo transport_stream_ID es válido. Si la bandera is_service_ID_valid (ID_servicio_es_válido) es 1, ello indica que el campo de service_ID (ID_servicio) es válido.

Si la bandera is_country_code_valid (código_país_es_válido) es 1, ello indica que el campo country_code es válido. El campo de 32 bits de format_identifier, indica el valor de format_identifier poseído por un descriptor de registro (definido en la ISO/IEC13818-1) en el flujo continuo de transporte. El campo de 16 bits de original_network_ID (ID_red_original) indica el valor del original_network_ID definido en el flujo continuo de transporte.

El campo de 16 bits en service_ID indica el valor de service_ID definido en el flujo continuo de transporte. El campo de 24 bits de country_code muestra un código del país definido por ISO3166. Cada código de caracteres se codifica mediante ISO8859-1. Por ejemplo, Japón se representa como "JPN" y se codifica en "0x4A 0x50 0x4E". El stream_format_name (nombre_formato_flujoContinuo) es 15 códigos de caracteres de la ISO-646 que muestran el nombre de una organización del formato que proporciona definiciones de flujo continuo para flujos continuos de transporte. Un byte no válido en este campo tiene un valor de "0xFF".

Format_identifier, original_network_ID, transport_stream_ID, service_ID, country_code y stream_format_name indican proveedores de servicios de flujos continuos de transporte. Esto permite reconocer limitaciones de codificación sobre flujos continuos de audio y vídeo y definiciones de flujo continuo correspondientes a flujos continuos de datos privados diferentes a flujos continuos de audio vídeo o la SI (información del servicio). Esta información se puede usar para comprobar si el decodificador tiene la capacidad de decodificar el flujo continuo. Si dicha decodificación es posible, la información se puede usar para inicializar el sistema del decodificador antes de iniciar la decodificación.

Se explica a continuación STC_Info. Al dominio de tiempo en el flujo continuo de transporte MPEG-2 que no contiene puntos discontinuos de STC (puntos discontinuos de la base de tiempos del sistema) se le denomina STC_sequence (secuencia_STC). En el Clip, la STC_sequence se especifica por el valor de STC_sequence_id. Las Figs. 50A y 50B ilustran un dominio de STC continuo. Los mismos valores de STC nunca aparecen en la misma STC_sequence, aunque la máxima extensión de tiempo del Clip está limitada, como se explica posteriormente. Por lo tanto, los mismos valores de PTS tampoco nunca aparecen en la misma STC_sequence. Si el flujo continuo AV contiene N puntos discontinuos de STC, donde N > 0, la base de tiempos del sistema de Clip se divide en (N+1) STC_sequences.

STC_Info almacena la dirección del sitio en el que se producen discontinuidades de STC (discontinuidades de la base de tiempos del sistema). Tal como se explica en referencia a la Fig. 51, el RSPN_STC_start (inicio_STC_RSPN) indica la dirección y comienza en un instante de tiempo de llegada del paquete fuente al que

5 remite el RSPN_STC_start (k+1)esimo y finaliza en un instante de tiempo de llegada del último paquete fuente.

La Fig. 52 muestra la sintaxis de la STC_Info (Info_STC). Volviendo a la sintaxis de STC_Info mostrada en la Fig. 52, el version_number es cuatro letras de caracteres que indican el número de versión de STC_Info(). El version_number se debe codificar en "0045" de acuerdo con la ISO 646.

10 Longitud es un entero sin signo de 32 bits que indica el número de bytes de STC_Info() desde directamente después de este campo de longitud hasta el final de STC_Info. Si CPI_type del CPI() indica el tipo TU_map, en este campo de longitud se puede fijar un 0. Si CPI_type de CPI() indica el tipo EP_map, el num_of_STC_sequence (núm_de_secuencia_STC) debe ser de un valor no menor que 1.

15 Un entero de 8 bits sin signo de num_of_STC_sequence indica el número de secuencias en elClip. Este valor indica el número de los bucles “para” que van a continuación del campo. El STC_sequence_id que se corresponde con la STC_sequence preestablecida se define por el orden en el cual aparece el RSPN_STC_start que se corresponde con la STC_sequence en el bucle “para” que contiene el RSPN_STC_start. El STC_sequence_id comienza en 0.

20 El campo de 32 bits de RSPN_STC_start indica una dirección en la cual la STC_sequence comienza en el archivo de flujo continuo AV. RSPN_STC_start indica una dirección en la que se producen discontinuidades de la base de tiempos del sistema en el archivo de flujo continuo AV. El RSPN_STC_start puede también ser una dirección relativa del paquete fuente que tiene el primer PCR de la nueva base de tiempos del sistema en el flujo continuo AV. El

25 RSPN_STC_start es de un tamaño basado en el número de paquetes fuente y se cuenta desde el primer paquete fuente del archivo de flujo continuo AV con el valor de offset_SPN definido en ClipInfo() como valor inicial. En este archivo de flujo continuo AV, la dirección absoluta se calcula mediante la ecuación mencionada anteriormente, es decir

30 SPN_xxx = RSPN_xxx - offset_SPN.

Se explica a continuación, en referencia a la Fig. 53, Programlnfo en la sintaxis del zzzz.Clip mostrada en la Fig. 45. Al dominio de tiempo que tiene las siguientes características en el Clip se le denomina program_sequence. Estas características son que el valor de PCR_PID no se cambia, el número de flujos continuos elementales de audio

35 tampoco se cambia, los valores de PID en los flujos continuos de vídeo respectivos no cambia, la información de codificación que se define por VideoCodinglnfo de la misma no cambia, el número de flujos continuos elementales de audio tampoco cambia, los valores de PID de los flujos continuos de audio respectivos no cambian, y que la información de codificación, que cual se define por la AudioCodinglnfo de los mismos, no cambia.

40 Program_sequence (Secuencia_programa) tiene solamente una base de tiempos del sistema en el mismo instante de tiempo. Program_sequence tiene un solo PMT en el mismo instante de tiempo. Programlnfo() almacena la dirección del sitio en el que comienza program_sequence. RSPN_program_sequence-start (iniciosecuencia_programa_RSPN) indica la dirección.

45 La Fig. 54 ilustra la sintaxis de Programlnfo. Volviendo al Programlnfo mostrado en la Fig. 54, version_number es cuatro letras de caracteres que indican el número de versión de Programlnfo(). El version_number se debe codificar en "0045" de acuerdo con la ISO 646.

Longitud es un entero de 32 bits sin signo que indican el número de bytes de Programlnfo() desde directamente

50 detrás de este campo de longitud al final de Programlnfo(). Si CPI_type de CPI() indica el tipo TU_map, este campo de longitud se puede fijar a 0. Si el CPI_type de CPI() indica el tipo EP_map, el number_of_programs (número_de_programas) debe ser de un valor no menor que 1.

Un entero de 8 bits sin signo de number_of_program_sequences (número_de_secuencias_programa), indica el

55 número de program_sequences en el Clip. Este valor indica el número de bucles “para” a continuación de este campo. Si program_sequence en el Clip no cambia, en el número de program_sequences se debe fijar 1. Un campo de 32 bits de RSPN_program_sequence_start es una dirección relativa en la que comienza la secuencia de programa en el flujo continuo AV.

60 RSPN_program_sequence_start se dimensiona con el número de paquetes fuentes como unidad y se cuenta con el valor de offset_SPN definido en la Cliplnfo() desde el primer paquete fuente del archivo de flujo continuo AV. Una dirección absoluta en el archivo de flujo continuo AV se calcula mediante:

SPN_xxx = RSPN_xxx - offset_SPN. 65

Los valores de RSPN_program_sequence_start en la sintaxis del bucle “para” deben aparecer en el orden ascendente.

Un campo de 16 bits de PCR_PID indica el PID del paquete de transporte que contiene un campo de PCR efectivo para la program_sequence. Un campo de 8 bits de number_of_audios (número_de_audios) indica el número de bucles “para” que contienen audio_stream_PID (PID_flujoContinuo_audio) y AudioCodinglnfo(). Un campo de 16 bits de video_stream_PID indica el PID del paquete de transporte que contiene un flujo continuo de vídeo efectivo para su program_sequence. VideoCodinglnfo(), a continuación de este campo, debe explicar el contenido del flujo continuo de vídeo al que remite su video_stream_PID.

Un campo de 16 bits de audio_stream_PID indica el PID de un paquete de transporte que contiene el flujo continuo de audio efectivo para su program_sequence. La AudioCodinglnfo(), a continuación de este campo, debe explicar el contenido del flujo continuo de vídeo al que remite su audio_stream_PID.

El orden en el cual aparecen los valores de video_stream_PID en el bucle “para” de la sintaxis debe ser igual a la secuencia de codificación del PID del flujo continuo de vídeo en el PMT efectivo para la program_sequence. Adicionalmente, el orden en el cual aparecen los valores de audio_stream_PID en el bucle “para” de la sintaxis debe ser igual a la secuencia de codificación del PID del flujo continuo de audio en el PMT efectivo para la program_sequence.

La Fig. 55 muestra la sintaxis de VideoCodinglnfo en la sintaxis de la ProgramInfo mostrada en la Fig. 54. Volviendo a la sintaxis de la VideoCodinglnfo mostrada en la Fig. 55, un campo de 8 bits de video_format (formato_vídeo) indica el formato de vídeo correspondiente a video_stream_PID (PID_flujoContinuo_vídeo) en el Programlnfo(), tal como se muestra en la Fig. 56.

En referencia a la Fig. 57, un campo de 8 bits de frame_rate indica la velocidad de cuadros de vídeo correspondiente al video_stream_PID en el Programlnfo(). Un campo de 8 bits de display_aspect_ratio indica una relación de aspecto de la visualización de vídeo correspondiente a video_stream_PID en Programlnfo().

La Fig. 59 muestra la sintaxis de AudioCodinglnfo en la sintaxis de ProgramInfo mostrada en la Fig. 54. Volviendo a la sintaxis de la AudioCodinglnfo mostrada en la Fig. 59, un campo de 8 bits de audio_format (formato_audio) indica el método de codificación de audio que se corresponde con audio_stream_PID en Programlnfo(), tal como se muestra en la Fig. 60.

Un campo de 8 bits de audio_component_type indica un tipo de componente de audio correspondiente a audio_stream_PID en Programlnfo() tal como se muestra en la Fig. 61, mientras que un campo de 8 bits de sampling_frequency indica una frecuencia de muestreo de audio correspondiente a audio_stream_PID en Programlnfo() tal como se muestra en la Fig. 62.

Se explica la CPI (Información de Puntos Característicos) en la sintaxis de zzzzz.clip mostrada en la Fig. 45. La CPI se usa para correlacionar la información de tiempo en el flujo continuo AV con la dirección en su archivo. La CPI es de dos tipos, a saber, EP_map y TU_map. En la Fig. 63, si el CPI_type en CPI() es EP_map, su CPI() contiene EP_map. En la Fig. 64, si el CPI_type en CPI() es TU_map, su CPI() contiene TU_map. Un flujo continuo AV tiene un EP_map o un TU_map. Si el flujo continuo AV es un flujo continuo de transporte SESF, el Clip correspondiente debe poseer un EP_map.

La Fig. 65 muestra la sintaxis de CPI. Volviendo a la sintaxis de CPI mostrada en la Fig. 65, el version_number es cuatro letras de caracteres que indican el número de versión de esta CPI(). El version_number se debe codificar en "0045" de acuerdo con la ISO 646. La longitud es un entero sin signo de 32 bits que indica el número de bytes desde directamente después de este campo de longitud al extremo final la CPI(). El CPI_type es una bandera de 1 bit e indica el tipo de la CPI del Clip, tal como se muestra en la Fig. 66.

Se explica el EP_map en la sintaxis de CPI mostrada en la Fig. 65. Existen dos tipos del EP_map, es decir, EP_map para un flujo continuo de vídeo y un EP_map para un flujo continuo de audio. El EP_map_type en el EP_map se diferencia entre estos tipos de EP_map. Si el Clip contiene uno o más flujos continuos de vídeo, se debe usar el EP_map para el flujo continuo de vídeo. Si el Clip no contiene un flujo continuo de vídeo pero contiene uno o más flujos continuos de audio, se debe usar el EP_map para el flujo continuo de audio.

Se explica en referencia a la Fig. 67 el EP_map para un flujo continuo de vídeo. El EP_map para el flujo continuo de vídeo tiene stream_PID, PTS_EP_start (inicio_EP_PTS) y RSPN_EP_start (inicio_EP_RSPN) de datos. El stream_PID (PID_flujoContinuo) muestra el PID del paquete de transporte que transmite un flujo continuo de vídeo. El PTS_EP_start indica la PTS de una unidad de acceso que comienza desde el encabezamiento de la secuencia del flujo continuo de vídeo. El RSPN_RP_start indica la dirección de un paquete fuente que incluye el primer byte de la unidad de acceso a la que remite el PTS_EP_start en el flujo continuo AV.

Una sub-tabla, denominada EP_map_for_one_stream_PID() se crea a partir de un flujo continuo de vídeo transmitido por el paquete de transporte que tiene el mismo PID a otro. Si en el Clip existen diversos flujos continuos de vídeo, el EP_map puede contener diversos EP_map_for_one_stream_PID().

El EP_map para el flujo continuo de audio tiene stream_PID, PTS_EP_start y RSPN_EP_start de datos. El stream_PID muestra un PID de un paquete de transporte que transmite un flujo continuo de audio. El PTS_EP_start muestra la PTS de una unidad de acceso en el flujo continuo de audio. El RSPN_EP-start indica una dirección de un paquete fuente que contiene un primer byte de la unidad de acceso a la que remite la PTS_EP_start del flujo continuo AV.

La sub tabla denominada EP_map_for_one_stream_PID() se crea a partir de un flujo continuo de audio transmitido por el paquete de transporte que tiene el mismo PID a otro. Si existen diversos flujos continuos de audio en el clip, EP_map puede contener diversos EP_map_for_one_stream_PID().

Volviendo a la relación entre EP_map y STC_Info, un EP_map_for_one_stream_PID() se crea en una tabla con independencia de los puntos discontinuos en la STC. La comparación del valor del RSPN_EP_start con el valor de RSPN_STC_start definido en STC_Info() revela la delimitación de datos de EP_map que pertenecen a STC_sequences respectivas (véase la Fig. 68). El EP_map debe tener un EP_map_for_one_stream_PID para un intervalo continuo de flujos continuos transmitido por el mismo PID. En el caso mostrado en la Fig. 69, programa#1 y programa#3 tienen el mismo PID de vídeo, aunque el intervalo de datos no es continuo, de manera tal que se debe proporcionar EP_map_for_one_stream_PID para cada programa.

La Fig. 70 muestra la sintaxis de EP_map. A título explicativo de la sintaxis de EP_map mostrada en la Fig. 70, el EP_type es un campo de 4 bits y muestra el tipo del punto de entrada del EP_map, tal como se muestra en la Fig.

71. El EP_type muestra la semántica del campo de datos que va a continuación de este campo. Si Clip incluye uno o más flujos continuos de vídeo, el EP_type debe fijarse a 0 ('vídeo'). Alternativamente, si el Clip no contiene ningún flujo continuo de vídeo, pero contiene uno o más flujos continuos de audio, entonces el EP_type se debe fijar a 1 ('audio').

El campo de 16 bits de number_of_stream_PIDs (número_de_PIDs_flujoContinuo) indica el número de veces de ciclos correspondientes al bucle “para” que tiene number_of_stream_PIDs en el EP_map() como variable. El campo de 16 bits de stream _PID(k) indica el PID del paquete de transporte que transmite el flujo continuo elemental número k (flujo continuo de audio o vídeo) al que remite EP_map_for_one_stream_PID (num_EP_entries(k)). Si EP_type es 0 ('vídeo'), su flujo continuo elemental debe ser un flujo continuo de vídeo. Si EP_type es igual a 1 ('audio'), su flujo continuo elemental debe ser el flujo continuo de audio.

El campo de 16 bits de num_EP_entries(k) indica el num_EP_entries(k) al que remite EP_map_entries(k). El EP_map_for_one_stream_PID_Start_address(k): Este campo de 32 bits indica la posición de la dirección relativa en la cual el EP_map_for_one_stream_PID(num_EP_entries(k)) comienza en el EP_map(). Este valor se indica por el tamaño a partir del primer byte del EP_map().

La padding_word se debe insertar de acuerdo con la sintaxis del EP_map(). X e Y deben ser enteros positivos opcionales. Las palabras de relleno respectivas pueden adoptar cualesquiera valores opcionales.

La Fig. 72 muestra la sintaxis de EP_map_for_one_stream_PID. A título explicativo de la sintaxis del EP_map_for_one_stream_PID mostrado en la Fig. 72, la semántica del campo de 32 bits de PTS_EP_start difiere con el EP_type definido por el EP_map(). Si EP_type es igual a 0 ('vídeo'), este campo tiene 32 bits superiores de la PTS de precisión de 33 bits de la unidad de acceso que comienza con un encabezamiento de secuencia del flujo continuo de vídeo. Si el EP_type es igual a 1 ('audio'), este campo tiene 32 bits superiores de la PTS de precisión de 33 bits de la unidad de acceso del flujo continuo de audio.

La semántica del campo de 32 bits de RSPN_EP_start difiere con el EP_type definido en EP_map(). Si EP_type es igual a 0 ('vídeo'), este campo indica la dirección relativa del paquete fuente que incluye el primer byte del encabezamiento de la secuencia de la unidad de acceso a la que remite el PTS_EP_start en el flujo continuo AV. Alternativamente, si EP_type es igual a 1 ('audio'), este campo indica la dirección relativa del paquete fuente que contiene el primer byte en el flujo continuo de audio de la unidad de acceso a la que remite el PTS_EP_start en el flujo continuo AV.

RSPN_EP_start es de un tamaño que se basa en el número de paquetes fuente como unidad, y se cuenta desde el primer paquete fuente del archivo de flujo continuo AV, con el valor del offset_SPN, definido en ClipInfo(), como valor inicial. La dirección absoluta en el archivo de flujo continuo AV se calcula por

SPN_xxx = RSPN_xxx - offset_SPN.

Se observa que el valor de RSPN_EP_start en la sintaxis debe aparecer en el orden ascendente.

Se explica a continuación el TU_map en referencia a la Fig. 73. El TU_map forma un eje de tiempo sobre la base del reloj del tiempo de llegada de paquetes fuente (reloj de la base de tiempos de llegada). A este eje de tiempo se le denomina TU_map_time_axis (eje_tiempo_corresp_TU). El punto de origen de TU_map_time_axis se indica por medio de offset_time (tiempo_desplazamiento) en el TU_map(). El TU_map_time_axis se divide en una unidad preestablecida a partir de offset_time, denominándose a esta unidad time_unit (unidad_tiempo).

En cada time_unit en el flujo continuo AV, en TU_map se almacenan direcciones en el archivo de flujo continuo AV del paquete fuente en la primera forma completa. A estas direcciones se les denomina RSPN_time_unit_start (inicio_unidad_tiempo_RSPN). Al tiempo en el que comienza la time_unit k(k > 0)ésima en el TU_map_time_axis se le denomina TU_start_time(k) (tiempo_inicio_TU(k)). Este valor se calcula sobre la base de la siguiente ecuación:

TU_start_time(k) = offset_time + k*time_unit_size.

Se observa que el TU_start_time(k) tiene una precisión de 45 kHz.

La Fig. 74 muestra la sintaxis de TU_map. A título explicativo de la sintaxis de TU_map mostrada en la Fig. 74, el campo de 32 bits de offset_time proporciona un tiempo de desplazamiento con relación a TU_map_time_axis. Este valor indica el tiempo de desplazamiento con relación a la primera time_unit en el Clip. El offset_time es de un tamaño basado en el reloj de 45 kHz obtenido a partir de los relojes del tiempo de llegada de precisión de 27 MHz como unidad. Si el flujo continuo AV se fuera a grabar como un nuevo Clip, el offset_time debe fijarse a 0.

El campo de 32 bits de time_unit_size proporciona el tamaño de la time_unit, y se basa en relojes de 45 kHz, obtenidos a partir de los relojes del tiempo de llegada de precisión de 27 MHz, como unidad. Preferiblemente, la time_unit_size no es más grande que un segundo (time_unit_size < 45.000). El campo de 32 bits de number_of_time_unit_entries (número_de_entradas_unidad_tiempo) indica el número de entradas almacenadas en TU_map().

El campo de 32 bits de RSN_time_unit_start indica la dirección relativa de un sitio en el flujo continuo AV en el cual comienza cada time_unit. RSN_time_unit_start es de un tamaño basado en el número de paquetes fuente como unidad y se cuenta con el valor de offset_SPN definido en ClipInfo() a partir del primer paquete fuente del archivo de flujo continuo AV como valor inicial. La dirección absoluta en el archivo de flujo continuo AV se calcula por

SPN_xxx = RSPN_xxx - offset_SPN.

Se observa que el valor de RSN_time_unit_start en el bucle “para” de la sintaxis debe aparecer en orden ascendente. Si no existe ningún paquete fuente en la time_unit número (k+1), la RSPN_time_unit_start número (k+1) debe ser igual a la RSPN_time_unit_start número k.

A título explicativo de la ClipMark en la sintaxis de zzzzz.clip mostrada en la Fig. 45, la ClipMark es la información de marca pertinente del fragmento y se almacena en la ClipMark. Esta marca no la fija el usuario, sino que la fija un grabador (aparato de grabación y/o reproducción 1).

La Fig. 75 muestra la sintaxis de la ClipMark. A título explicativo de la sintaxis de la ClipMark mostrada en la Fig. 75, el version_number es cuatro letras de caracteres que indican el número de versión de esta ClipMark. El version_number se debe codificar de acuerdo con la ISO 646 a "0045".

La longitud es un entero de 32 bits sin signo que indica el número de bytes de la ClipMark() desde directamente después del campo de longitud al extremo final de ClipMark(). El number_of_Clip_marks (número_de_marcas_Fragmento) es un entero sin signo de 16 bits que indica el número de marcas almacenadas en ClipMark() y puede ser igual a 0. Mark_type es un campo de 8 bits que indica el tipo de marca y se codifica de acuerdo con la tabla mostrada en la Fig. 76.

Mark_time_stamp es un campo de 32 bits y almacena la indicación de tiempo que indica un puntero que tiene una marca especificada. La semántica de mark_time_stamp difiere con el CPI_type en la PlayList(), tal como se muestra en la Fig. 77.

Si el CPI_type en el CPI() indica el tipo de EP_map, este campo de 8 bits indica el STC_sequence_id del domino continuo de STC donde se sitúa mark_time_stamp. Si CPI_type en CPI() indica el tipo TU_map, este campo de 8 bits no tiene significado pero se fija a 0. El campo de 8 bits de Character_set indica el método de indicación de letras de caracteres codificadas en el campo mark_name. El método de codificación se corresponde con el valor mostrado en la Fig. 19.

El campo de 8 bits de name_length indica la longitud en bytes del nombre de la marca mostrado en el campo mark_name. Este campo mark_name indica el nombre de la marca. El número de bytes que se corresponde con el número de la name_length desde la izquierda de este campo es el número de caracteres efectivos e indica el

nombre de la marca. En el campo mark_name, los valores que van a continuación de estas letras de caracteres efectivas pueden ser arbitrarios.

El campo de ref_thumbnail_index indica la información de la imagen en miniatura adjuntada a la marca. Si el campo ref_thumbnail_index es de un valor diferente a 0xFFFF, a su marca se añade una imagen en miniatura, almacenándose la imagen en miniatura en el archivo mark.thumb. Se remite a esta imagen usando el valor de ref_thumbnail_index en el archivo mark.thumb. Si el campo ref_thumbnail_index es de un valor igual a 0xFFFF, no se adjunta una imagen en miniatura a su marca.

MakersPrivateData ya se ha explicado en referencia a la Fig. 22 y por ello no se explica en este caso específicamente.

A continuación se explica thumbnail_information. Una imagen en miniatura se almacena en un archivo menu.thmb o en un archivo mark.thmb. Estos archivos tienen la misma estructura de sintaxis y poseen un solo Thumbnail(). El archivo menu.thmb almacena una imagen que representa PlayLists respectivas. La totalidad de las imágenes en miniatura de menú se almacenan en el archivo menu.thmb único.

El archivo mark.thmb almacena una imagen en miniatura de marca, es decir, una imagen que representa un punto de marca. La totalidad de las imágenes en miniatura de marca que se corresponden con la totalidad de PlayLists y Clips se almacenan en el único archivo mark.thmb. Puesto que las imágenes en miniatura se añaden o eliminan frecuentemente, la operación de adición y eliminación parcial debe ser ejecutable de manera fácil y rápida. Por esta razón, Thumbnail() tiene una estructura de bloques. Los datos de la imagen se dividen en diversas porciones, cada una de las cuales se almacena en un tn_block. Los datos de una imagen se almacenan en tn_blocks consecutivos. En la cadena de tn_blocks, puede existir un tn_block que no esté en uso. La longitud en bytes de una sola imagen en miniatura es variable.

La Fig. 78 muestra la sintaxis de menu.thmb y mark.thmb y la Fig. 79 la sintaxis de Thumbnail en la sintaxis de menu.thmb y mark.thmb mostrada en la Fig. 78. A título explicativo de la sintaxis de Thumbnail, mostrada en la Fig. 79, el version_number es cuatro letras de caracteres que indican el número de versión de esta Thumbnail(). El version_number se debe codificar en "0045" de acuerdo con la ISO 646.

La longitud es un entero sin signo de 32 bits que indica el número de bytes de MakerPrivateData() desde directamente detrás del campo de longitud hasta el extremo final de Thumbnail().Tu_block_start_address es un entero de 32 bits sin signo que indica la dirección en bytes del extremo inicial del primer tn_block, en términos del número relativo de bytes a partir del byte del extremo inicial de Thumbnail() como unidad. El número de bytes relativo se cuenta desde 0. Number_of_thumbnails (número_de_imágenesMiniatura) es un entero sin signo de 16 bits el cual proporciona el número de entradas de una imagen en miniatura contenida en un Thumbnail().

Tu_block_size es un entero sin signo de 16 bits que proporciona el tamaño de un tn_block, en términos de 1.024 bytes como unidad. Si, por ejemplo, tn_block_size = 1, ello indica que el tamaño de un tn_block es 1.024 bytes. Number_of_tn_blocks (número_de_bloques_tn) es un entero sin signo de 116 bits que indica el número de entradas de tn_block en este Thumbnail(). Thumbnail_index (índice_imagenMiniatura) es un entero de 16 bits sin signo que indica el número de índice de la imagen en miniatura representada por la información de imagen en miniatura para un bucle “para” que comienza desde el campo thumbnail_index. El valor 0xFFFF no se debe usar como Thumbnail_index. Se remite a este Thumbnail_index por medio de ref_thumbnail_index en UIAppInfoVolume(), UIAppInfoPlayList(), PlayListMark() y ClipMark().

Thumbnail_picture_format (formato_imagen_miniatura) es un entero sin signo de 8 bits que representa el formato de imagen correspondiente a una imagen en miniatura y adopta un valor mostrado en la Fig. 80. En la tabla, DCF y PNG se permiten solamente en menu.thumb. La imagen en miniatura de marca adopta el valor de "0x00" (MPEG-2 vídeo 1-imagen).

Picture_data_size es un entero sin signo de 32 bits que indica la longitud en bytes de una imagen en miniatura, en términos de bytes como unidad. Start_tn_block_number es un entero sin signo de 16 bits que indica el número de tn_block correspondiente al tn_block donde comienzan los datos de la imagen en miniatura. El extremo inicial de los datos de la imagen en miniatura debe coincidir con el extremo inicial del tn_block. El número de tn_block comienza desde 0 y es relevante para el valor de una variable k en el bucle “para” del tn_block.

X_picture_length es un entero sin signo de 16 bits que indica el número de píxeles en la dirección horizontal de un cuadro de una imagen en miniatura. Y_picture_length es un entero sin signo de 16 bits, que indica el número de píxeles en la dirección vertical de un cuadro de una imagen en miniatura. Tn_block es un área en la cual almacenar una imagen en miniatura. Todos los tn_blocks en el Thumbnail() son del mismo tamaño (longitud fija) y tienen un tamaño definido por tn_block_size.

Las Figs. 81A y 81B muestran esquemáticamente cómo se almacenan datos de imágenes en miniatura en tn_block. Si tal como se muestra en las Figs. 81A y 81B, la imagen en miniatura comienza en el extremo inicial de tn_block, y

es de un tamaño que supera a 1 tn_block, la misma se almacena usando el siguiente tn_block. Realizando esto, los datos con una longitud variable se pueden gestionar como datos de longitud fija, de manera que se puede hacer frente a la edición de eliminación con un procesado más simple.

Se explica a continuación un archivo de flujo continuo AV. El archivo de flujo continuo AV se almacena en el directorio "M2TS" (Fig. 14). Existen dos tipos del archivo de flujo continuo AV, a saber, un archivo de Flujo continuo AV de fragmento y un archivo de flujo continuo AV de Fragmento-Puente. Ambos flujos continuos AV deben tener la estructura de archivo de flujo continuo de transporte MPEG-2 DVR tal como se define posteriormente en la presente.

En primer lugar, se explica el flujo continuo de transporte DVR MPEG-2. La estructura del flujo continuo de transporte DVR MPEG- 2 se muestra en la Fig. 82. El archivo de flujo continuo AV tiene la estructura de un flujo continuo de transporte de DVR MPEG 2. El flujo continuo de transporte de DVR MPEG 2 está compuesto por un número entero de Unidades alineadas. El tamaño de la unidad alineada es 6.144 bytes (2.048*3 bytes). La Unidad alineada comienza desde el primer byte del paquete fuente. El paquete fuente tiene 192 bytes de longitud. Un paquete fuente está compuesto por TP_extra_header y un paquete de transporte. TP_extra_header tiene 4 bytes de longitud, siendo el paquete de transporte de 188 bytes de longitud.

Una Unidad alineada está compuesta por 32 paquetes fuente. La última Unidad alineada en el flujo continuo de transporte de DVR MPEG 2 también está compuesta por 32 paquetes fuente. Por lo tanto, el flujo continuo de transporte de DVR MPEG 2 finaliza en un límite de la Unidad alineada. Si el número de los paquetes de transporte del flujo continuo de transporte de entrada grabado en un disco no es un múltiplo de 32, un paquete fuente que tiene un paquete nulo (paquete de transporte de PID = 0x1FFFF) se debe usar como última Unidad alineada. El sistema de archivos no debe usar información en exceso en el flujo continuo de transporte de DVR MPEG 2.

La Fig. 83 muestra un modelo de grabador del flujo continuo de transporte de DVR MPEG 2. El grabador mostrado en la Fig. 83, es un modelo conceptual para prescribir el proceso de grabación. El flujo continuo de transporte de DVR MPEG 2 obedece a este modelo.

Se explica a continuación la temporización de entrada del flujo continuo de transporte MPEG 2. El flujo continuo de transporte MPEG 2 de entrada es un flujo continuo de transporte completo o flujo continuo de transporte parcial. El flujo continuo de transporte MPEG 2 de entrada debe obedecer a la ISO/IEC13818-1 ó a la ISO/IEC 13818-9. El byte número i del flujo continuo de transporte MPEG 2 se introduce simultáneamente en el tiempo t(i) en T-STD (decodificador objetivo del sistema de flujos continuos de transporte proporcionado por la ISO/IEC13818-1) y en el formador de paquetes fuente. Rpk es un valor máximo instantáneo de la velocidad de entrada del paquete de transporte.

Un PLL de 27 MHz 52 genera una frecuencia del reloj de 27 MHz. La frecuencia del reloj de 27 MHz se engancha a un valor de la referencia de reloj de programa (PCR) del flujo continuo de transporte MPEG 2. Un contador de reloj de tiempo de llegada 53 cuenta los impulsos de la frecuencia de 27 MHz. Arrival_time_clock(i) es un valor de recuento del contador de reloj de tiempo de llegada en el tiempo t(i).

Un formador de paquetes fuente 54 adjunta TP_extra_header a la totalidad de los paquetes de transporte para crear un paquete fuente. La arrival_time_stamp indica el tiempo en el que el primer byte del paquete de transporte alcanza tanto el T-STD como el formador de paquetes fuente. Arrival_time_stamp(k) es un valor muestreado del Arrival_time_clock(k) tal como se representa por la siguiente ecuación:

arrival_time_stamp(k) = arrival_time_clock(k)% 230

en la que k indica el primer byte del paquete de transporte.

Si la separación de tiempo entre dos paquetes de transporte vecinos es 230/2 7.000.000 s (aproximadamente 40 s)

: o mayor, la diferencia de la arrival_time_stamp de los dos paquetes de transporte debería fijarse a 230/2 7.000.000

s.: El grabador se proporciona para un caso de este tipo.

Una memoria intermedia de suavizado 55 suaviza la velocidad de bits del flujo continuo de transporte de entrada. La memoria intermedia de suavizado no debe desbordarse. Rmax es la velocidad de bits de salida del paquete fuente desde la memoria intermedia de suavizado cuando la memoria intermedia de suavizado no está llena. Si la memoria intermedia de suavizado está llena, la velocidad de bits de salida de la memoria intermedia de suavizado es 0.

A continuación, se explican los parámetros del modelo de grabador del flujo continuo de transporte de DVR MPEG 2. El valor de Rmax se proporciona por medio de TS_recording_rate tal como se define en ClipInfo() asociada al archivo de flujo continuo AV. Este valor se puede calcular a partir de la siguiente ecuación:

Rmax = TS_recording_rate*192/188

en la que el valor de TS_recording_rate es de un tamaño en bytes/segundo.

Si el flujo continuo de transporte de entrada es un flujo continuo de transporte SESF, Rpk debe ser igual a TS_recording_rate tal como se define en la Cliplnfo() asociada al archivo de flujo continuo AV. Si el flujo continuo de transporte de entrada no es un flujo continuo de transporte SESF, puede hacerse referencia a valores definidos por ejemplo en un descriptor del flujo continuo de transporte MPEG 2, tal como maximum_bitrate_descriptor (descriptor_velocidadBits_máxima) o partial_stream_descriptor (descriptor_flujoContinuo_parcial) para este valor.

Si el flujo continuo de transporte de entrada es un flujo continuo de transporte SESF, el tamaño de la memoria intermedia de suavizado es 0. Si el flujo continuo de transporte de entrada no es un flujo continuo de transporte SESF, puede hacerse referencia a valores definidos en el descriptor del flujo continuo de transporte MPEG 2, tales

como: por ejemplo los valores definidos en el smoothing_buffer_descriptor

(descriptor_memoriaIntermedia_suavizado),: short_smoothing_buffer_descriptor

(descriptor_memoriaIntermedia_suavizado_corto): o en el partial_transport_stream_descriptor

(descriptor_flujoContinuo_transporte_parcial).

Para el grabador y el reproductor (aparato de reproducción), es necesario proporcionar una memoria intermedia de tamaño suficiente. El tamaño por defecto de la memoria intermedia es 1.536 bytes.

A continuación, se explica un modelo de reproductor del flujo continuo de transporte de DVR MPEG 2. La Fig. 84 muestra un modelo de reproductor del flujo continuo de transporte de DVR MPEG 2. Este es un modelo conceptual para prescribir el proceso de reproducción. El flujo continuo de transporte de DVR MPEG 2 obedece a este modelo.

Un X-tal de 27 MHz 61 genera la frecuencia de 27 MHz. Un intervalo de error de la frecuencia de 27MHz debe ser ±30 ppm (2 7.000.000 ± 810 Hz). El contador de reloj de tiempo de llegada 62, es un contador binario para contar los impulsos de la frecuencia de 27 MHz. Arrival_time_clock(i) es un valor de recuento del contador de reloj de tiempo de llegada en el tiempo t(i).

En la memoria intermedia de suavizado 64, Rmax es la velocidad de bits de entrada del paquete fuente a la memoria intermedia de suavizado cuando la memoria intermedia de suavizado no está llena. Si la memoria intermedia de suavizado está llena, la velocidad de bits de entrada a la memoria intermedia de suavizado es 0.

A título explicativo de la temporización de salida del flujo continuo de transporte MPEG2, si la arrival_time_stamp del paquete fuente actual es igual a 30 bits en el lado LSB de arrival_time_clock(i), el paquete de transporte del paquete fuente se elimina de la memoria intermedia de suavizado. Rpk es un valor máximo instantáneo de la velocidad de paquetes de transporte. No se permite el desbordamiento de la memoria intermedia de suavizado.

Los parámetros del modelo de reproductor del flujo continuo de transporte de DVR MPEG 2 son los mismos que los del modelo de grabador del flujo continuo de transporte de DVR MPEG 2 antes descrito.

La Fig. 85 muestra la sintaxis del paquete fuente. El Transport_packet() es un flujo continuo de transporte MPEG 2 proporcionado en la ISO/IEC13818-1. La sintaxis de TP_Extra-header en la sintaxis del paquete fuente mostrada en la Fig. 85, se muestra en la Fig. 86. A título explicativo de la sintaxis del TP_Extra-header, mostrada en la Fig. 86, copy_permission_indicator (indicador_permiso_copia) es un entero que representa la limitación de copia de la carga útil del paquete de transporte. La limitación de copia puede ser copia libre, no más copias, copiar una vez o copia prohibida. La Fig. 87 muestra la relación entre el valor de copy_permission_indicator y el modo que designa.

Copy_permission_indicator se adjunta a la totalidad de paquetes de transporte. Si el flujo continuo de transporte de entrada se graba usando la interfaz digital IEEE1394, el valor de copy_permission_indicator se puede asociar al valor de EMI (indicador del modo de cifrado). Si el flujo continuo de transporte de entrada se graba sin utilizar la interfaz digital IEEE1394, el valor de copy_permission_indicator se puede asociar al valor del CCI incorporado en el paquete de transporte. Si una entrada de señal analógica está auto-codificada, el valor de copy_permission_indicator se puede asociar al valor de CGMS-A de la señal analógica.

Arrival_time_stamp es un entero que tiene un valor según se especifica por medio de arrival_time_stamp en la siguiente ecuación:

arrival_time_stamp(k) = arrival_time_clock(k)%230.

A manera de definición del Flujo continuo AV de fragmento, el Flujo continuo AV de fragmento debe tener una estructura del flujo continuo de transporte de DVR MPEG 2 definida según se ha descrito anteriormente. Arrival_time_clock(i) debe incrementarse continuamente en el Flujo continuo AV de fragmento. Si existe un punto discontinuo de la base de tiempos del sistema (base del SCT) en el Flujo continuo AV de fragmento, arrival_time_clock(i) en el Flujo continuo AV de fragmento debe incrementarse continuamente.

El valor máximo de la diferencia del arrival_time_clock(i) entre el comienzo y el final del Flujo continuo AV de fragmento debe ser 26 horas. Esta limitación garantiza que, si no existe ningún punto discontinuo en la base de

tiempos del sistema (base de STC) en el flujo continuo de transporte MPEG 2, la PTS (marca de tiempo de presentación) del mismo valor, nunca aparece en el Flujo continuo AV de fragmento. La normativa del sistema MPEG2 prevé que la PTS tenga un periodo reinicio cíclico de 233/90.000 s (aproximadamente 26,5 horas).

A manera de definición del flujo continuo AV de Fragmento-Puente, el flujo continuo AV de Fragmento-Puente debe tener una estructura del flujo continuo de transporte de DVR MPEG 2 definida según se ha descrito anteriormente. El flujo continuo AV de Fragmento-Puente debe incluir un punto discontinuo de una base de tiempos de llegada. El flujo continuo de transporte deelante y detrás del punto discontinuo de la base de tiempos de llegada debe obedecer a las limitaciones de codificación y el DVR-STD tal como se explica posteriormente.

La presente forma de realización soporta la conexión sin interrupciones de vídeo-audio entre Playltems que están siendo editados. La conexión sin interrupciones entre Playltems garantiza un "suministro continuo de datos" al reproductor/decodificador y un "procesado de decodificación sin interrupciones". El "suministro continuo de datos" es la capacidad de garantizar un suministro de datos al decodificador a una velocidad de bits necesaria para evitar el subdesbordamiento de la memoria intermedia. Para permitir la lectura de datos desde el disco mientras se garantizan propiedades de tiempo real de los mismos, los datos deberán ser almacenados en términos de un bloque continuo de un tamaño suficientemente grande como unidad.

El "procesado de decodificación sin interrupciones" significa la capacidad de un reproductor para presentar datos de audio y vídeo grabados en el disco sin producir pausas o separaciones en la salida de la reproducción del decodificador.

Se explica el flujo continuo AV, al que remiten los Playltems conectados sin interrupciones. El hecho de que se garantice o no la visualización sin interrupciones de un Playltem previo y el Playltem actual, se puede comprobar a partir del campo connection_condition definido en el PlayItem actual. Existen dos métodos para la conexión sin interrupciones de PlayItems, es decir, un método que utiliza Bridge-Clip y un método que no utiliza Bridge-Clip.

La Fig. 88 muestra la relación entre el Playltem previo y el Playltem actual en caso de utilizar Bridge-Clip. En la Fig. 88, los datos del flujo continuo, leídos por el reproductor, se muestran sombreados. En la Fig. 88, TS1 está compuesto por datos de flujo continuo sombreados del Clip 1 (Flujo continuo AV de fragmento) y datos de flujo continuo sombreados previos a RSPN_arrival_time_discontinuity.

Los datos de flujo continuo sombreados de Clip 1 de TS1 son datos de flujo continuo desde una dirección de un flujo continuo requerido para decodificar la unidad de presentación correspondiente a IN_time del Playltem previo (mostrado como IN_time1 en la Fig. 88) hasta el paquete fuente al que remite RSPN_exit_from_previous_Clip (RSPN_salida_de_Fragmento_previo). Los datos de flujo continuo sombreados antes de RSPN_arrival_time_discontinuity de Fragmento-Puente contenido en TS1 son datos de flujo continuo a partir del primer paquete fuente de Fragmento-Puente hasta el paquete fuente directamente previo al paquete fuente al que remite RSPN_arrival_time_discontinuity.

En la Fig. 88, TS2 está compuesto por datos de flujo continuo sombreados de Clip 2 (flujo continuo AV de Clip) y datos de flujo continuo sombreados posteriores a RSPN_arrival_time_discontinuity de Fragmento-Puente. Los datos de flujo continuo sombreados a partir del RSPN_arrival_time_discontinuity de Fragmento-Puente contenido en datos de flujo continuo de TS2 a partir del paquete fuente al que remite RSPN_arrival_time_discontinuity hasta el último paquete fuente de Fragmento-Puente. Los datos de flujo continuo sombreados de Clip 2 de TS2 son datos de flujo continuo desde el paquete fuente al que remite RSPN_enter_to_current_Clip hasta la dirección del flujo continuo requerido para decodificar la unidad de presentación correspondiente a OUT_time del Playltem actual (mostrado por OUT_time2 en la Fig. 88).

La Fig. 89 muestra la relación entre el Playltem previo y el Playltem actual en el caso de no utilizar Fragmento-Puente. En este caso, los datos de flujo continuo leídos por el reproductor se muestran sombreados. En la Fig. 89, TS1 está compuesto por datos de flujo continuo sombreados del Clip1 (Flujo continuo AV de fragmento). Los datos de flujo continuo sombreados de Clip1 de TS1 son datos que comienzan en una dirección de un flujo continuo necesario para decodificar una unidad de presentación correspondiente a IN_time del Playltem previo, mostrado en IN_time1 en la Fig. 89 hasta el último paquete fuente de Clip1.

En la Fig. 89, TS2 son datos de flujo continuo sombreados de Clip2 (Flujo continuo AV de frgamento).

Los datos de flujo continuo sombreados de Clip2 de TS2 son datos de flujo continuo que comienzan en un primer paquete fuente de Clip2 hasta una dirección del flujo continuo necesaria para decodificar la unidad de presentación correspondiente a OUT_time del Playltem actual (mostrado en OUT_time2 en la Fig. 89).

En las Figs. 88 y 89, TS1 y T2 son flujos continuos del paquete fuente. A continuación, se analizan las provisiones de flujos continuos de TS1 y TS2 y las condiciones de conexión entre los mismos. En primer lugar, se analizan las limitaciones de codificación para la conexión sin interrupciones. A manera de limitaciones sobre la estructura de codificación de un flujo continuo de transporte, el número de programas contenidos en TS1 y TS2 debe ser 1. El

número de flujos continuos de vídeo contenidos en TS1 y TS2 debe ser 1. El número de flujos continuos de audio contenidos en TS y TS2 debe ser 2 ó menos. Los números de los flujos continuos de audio contenidos en TS1 y TS2 deben ser iguales entre sí. También es posible que TS1 y/o TS2 contengan flujos continuos elementales o flujos continuos privados que no sean aquellos representados anteriormente.

Se explican a continuación las limitaciones sobre el flujo continuo de bits de vídeo. La Fig. 90 muestra una conexión sin interrupciones típica indicada por una secuencia de visualización de imágenes. Para que un flujo continuo de vídeo se muestre sin interrupciones en las proximidades de un punto de unión, las imágenes no necesarias visualizadas detrás de OUT_time1 (OUT_time de Clip1) y delante de IN_time2 (IN_time de Clip2) se deben eliminar mediante un proceso de re-codificación del flujo continuo parcial del Clip en las proximidades del punto de unión.

La Fig. 91 muestra una forma de realización para lograr una conexión sin interrupciones usando BridgeSequence. El flujo continuo de vídeo de Fragmento-Puente previo a RSPN_arrival_time_discontinuity está compuesto por un flujo continuo de vídeo codificado hasta una imagen que se corresponde con OUT_time1 de Clip1 de la Fig. 90. Este flujo continuo de vídeo se conecta al flujo continuo de vídeo del Clip1 previo y se re-codifica para formar un flujo continuo elemental que se ajusta a la normativa MPEG2.

El flujo continuo de vídeo de Fragmento-Puente posterior a RSPN_arrival_time_discontinuity está compuesto por un flujo continuo de vídeo codificado, posterior a una imagen que se corresponde con IN_time2 de Clip2 de la Fig. 90. La decodificación de este flujo continuo de vídeo se puede iniciar correctamente para conectar el flujo continuo de vídeo al siguiente flujo continuo de vídeo de Clip2. La re-codificación se realiza de manera tal que se formará un solo flujo continuo elemental ininterrumpido que se ajusta a la normativa MPEG2. Para crear Fragmento-Puente, es necesario re-codificar varias imágenes en general, mientras que otras imágenes se pueden copiar del Clip original.

La Fig. 92 muestra una forma de realización para lograr la conexión sin interrupciones sin utilizar BridgeSequence en la forma de realización mostrada en la Fig. 90. El flujo continuo de vídeo de Clip1 está compuesto por un flujo continuo de vídeo codificado hasta la imagen que se corresponde con OUT_time1 de la Fig. 90 y se re-codifica para proporcionar un flujo continuo elemental que se ajusta a la normativa MPEG2. De una manera similar, el flujo continuo de vídeo de Clip2 está compuesto por flujos continuos de bits codificados posteriores a la imagen asociada a IN_time2 de Clip2 de la Fig. 90. Estos flujos continuos de bits de codificación ya están re-codificados para proporcionar un solo flujo continuo elemental ininterrumpido que se ajusta a la normativa MPEG2.

A título explicativo de las limitaciones de codificación del flujo continuo de vídeo, las velocidades de cuadro de los flujos continuos de vídeo de TS1 y TS2 deben ser iguales entre sí. El flujo continuo de vídeo de TS1 debe finalizar en sequence_end_code (código_fin_secuencia). El flujo continuo de vídeo de TS2 debe comenzar en el encabezamiento de la secuencia, Encabezamiento de GOP y con una imagen I. El flujo continuo de vídeo de TS2 debe comenzar en un GOP cerrado.

Las unidades de presentación de vídeo definidas en un flujo continuo de bits (cuadro o campo) deben ser continuas con un punto de unión entre ellas. No se permite que exista separación de los campos o cuadros en puntos de unión. En el caso de utilizar una codificación que use un diezmado de 3-2, puede ser necesario reescribir las banderas "top_field_first" y “repeat_first_field ". Alternativamente, se puede realizar una re-codificación local para evitar que se produzcan separaciones de campo.

A título explicativo de las limitaciones de codificación sobre el flujo continuo de bits de audio, la frecuencia de muestreo de audio de TS1 y la de TS2 deben ser iguales entre sí. El método de codificación de audio de TS1 y el de TS2 (por ejemplo, la capa 2 de MPEG1, AC-3, SESF LPCM y AAC) deben ser iguales entre sí.

A título explicativo de las limitaciones de codificación sobre el flujo continuo de transporte MPEG 2, la última trana de audio del flujo continuo de audio de TS1 debe contener muestras de audio que tienen una temporización de presentación igual al tiempo final de visualización de la última imagen de visualización de TS1. La primera trama de audio del flujo continuo de audio de TS2 debe contener una muestra de audio que tiene una temporización de presentación igual a la temporización de inicio de visualización de la primera imagen de visualización de TS2.

En un punto de unión, no se puede permitir que exista ninguna separación en una secuencia de las unidades de presentación de audio. Tal como se muestra en la Fig. 93, puede existir un solapamiento definido por la longitud de la unidad de presentación de audio menor que dos dominios de tramas de audio. El primer paquete que transmite un flujo continuo elemental de TS2 debe ser un paquete de vídeo. El flujo continuo de transporte en el punto de unión debe obedecer a la DVR-STC que se explicará posteriormente.

A título explicativo de las limitaciones sobre el Clip y el Fragmento-Puente, no se permite que existan discontinuidades en la base de tiempos de llegada en TS1 ó en TS2.

Las siguientes limitaciones se aplican solamente en el caso de utilizar el Fragmento-Puente. El flujo continuo AV de Fragmento-Puente tiene un solo punto discontinuo en la base de tiempos de llegada únicamente en un punto de unión del último paquete fuente de TS1 y el primer paquete fuente de TS2. La SPN_arrival_time_discontinuity

definida en Cliplnfo() representa una dirección del punto discontinuo, el cual debe representar la dirección que remite al primer paquete fuente de TS2.

El paquete fuente al que remite RSPN_exit_from_previous_Clip definido en BridgeSequence() puede ser cualquier paquete fuente en Clip1. No es necesario que este paquete fuente sea un límite de la Unidad alineada. El paquete fuente al que remite RSPN_enter_to_current_Clip definido en BridgeSequencelnfo() puede ser cualquier paquete fuente en Clip 2. No es necesario que este paquete fuente sea un límite de la Unidad alineada.

A título explicativo de las limitaciones sobre Playltem, el OUT_time del Playltem previo (OUT_time 1 mostrado en la Fig. 89) debe representar el tiempo final de visualización de la última unidad de presentación de vídeo de TS1. El IN_time del PlayTime actual (IN_time2 mostrado en las Figs. 88 y 89) debe representar el tiempo inicial de visualización de la primera unidad de presentación de TS2.

A título explicativo de las limitaciones sobre la asignación de datos en el caso de utilizar Fragmento-Puente en referencia a la Fig. 94, la conexión sin interrupciones se debe realizar para garantizar un suministro continuo de datos por parte del sistema de archivos. Esto se debe realizar disponiendo el flujo continuo AV de Bridge-Clip, conectando a Clip1 (archivo de Flujo continuo AV de fragmento) y Clip2 (archivo de Flujo continuo AV de fragmento), tal como para satisfacer las prescripciones de asignación de datos.

RSPN_exit_from_previous_Clip se debe seleccionar de manera tal que la porción del flujo continuo de Clip1 (archivo de Flujo continuo AV de fragmento) previa a RSPN_exit_from_previous_Clip se disponga en un área continua no menor que medio fragmento. La longitud de datos del flujo continuo AV de Fragmento-Puente se debe seleccionar de manera tal que los datos se dispongan en el área continua no menor que medio fragmento. Se debe seleccionar RSPN_enter_to_current_Clip de manera tal que la porción del flujo continuo de Clip2 (archivo de Flujo continuo AV de fragmento) posterior a RSPN_enter_to_current_Clip se disponga en un área continua no menor que medio fragmento.

A título explicativo de las limitaciones de asignación de datos en el caso de una conexión sin interrupciones que no utilice Fragmento-Puente, en referencia a la Fig. 95, la conexión sin interrupciones se debe realizar para garantizar el suministro continuo de datos por el sistema de archivos. Esto se debe realizar disponiendo la última porción del Clip1 (archivo de Flujo continuo AV de fragmento) y la primera porción del Clip2 (archivo de Flujo continuo AV de fragmento) de manera que se cumplan las provisiones sobre asignación de datos.

La última porción de flujo continuo de Clip1 (archivo de Flujo continuo AV de fragmento) se debe disponer en un área continua no menor que medio fragmento. La primera porción de flujo continuo de Clip2 (archivo de Flujo continuo AV de fragmento) se debe disponer en un área continua no menor que medio fragmento.

A continuación, se explica el DVR-STD. Este DVR-STD es un modelo conceptual para modelar el proceso de decodificación en la generación y comprobación del flujo continuo de transporte de DVR MPEG2. El DVR-STD también es un modelo conceptual para modelar el proceso de decodificación en la generación y comprobación del flujo continuo AV al que remiten dos Playltems conectados sin interrupciones entre sí según se ha descrito anteriormente.

La Fig. 96 muestra un modelo de DVR-STD. El modelo mostrado en la Fig. 96 incluye, como elemento constituyente, un modelo de reproductor de flujos continuos de transporte de DVR MPEG2. La notación de n, Tbn, Mbn, Ebn, Tbsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Dsys, On y P9(k) es la misma que la definida en la T-STD de la ISO/IEC 138181, en donde n es un número de índice de un flujo continuo elemental y TBn es una memoria intermedia de transporte del flujo continuo elemental n.

MBn es una memoria intermedia de multiplexado del flujo continuo elemental n y solamente existe para el flujo continuo de vídeo. EBn es una memoria intermedia de flujos continuos elementales correspondiente al flujo continuo elemental n y se presenta solamente para el flujo continuo de vídeo. TBsys es una memoria intermedia principal en un decodificador objetivo del sistema para la información de sistema para un programa que está siendo decodificado. Rxn es una velocidad de transmisión con la cual se extraen datos de Tbn. Rbxn es una velocidad de transmisión con la cual la carga útil de paquetes PES se extrae de MBn y se presenta solamente para un flujo continuo de vídeo.

Rxsys es una velocidad de transmisión con la cual se extraen datos desde TBsys. Dn es un decodificador del flujo continuo elemental n. Dsys es un decodificador pertinente de la información del sistema de un programa que está siendo decodificado. On es una memoria intermedia de reordenamiento del flujo continuo de vídeo n. Pn(k) es una unidad de presentación número k del flujo continuo elemental.

Se explica el proceso de decodificación para DVR- STD. Durante el tiempo que un solo flujo continuo de transporte de DVR MPEG2 está siendo reproducido, la temporización de introducción del paquete de transporte en TB1, TBn o TBsys se determina por medio de la arrival_time_stamp del paquete fuente. Las prescripciones para la operación de almacenamiento temporal de TB1, MB1, EB1, TBn Bn, TBsys y Bsys son las mismas que las de la T- STD que se

preven en la ISO/IEC 13818-1, mientras que las operaciones de decisión y visualización son también las mismas que la T-STD que se prevé en la ISO/IEC 13818-1.

Se explica a continuación el proceso de decodificación durante el tiempo en el cual se están reproduciendo PlayLists conectadas sin interrupciones. En este caso, se explica la reproducción de dos flujos continuos AV a los que remiten los Playltems conectados sin interrupciones. En la siguiente explicación, se explica la reproducción de TS1 y TS2 mostrada por ejemplo en la Fig. 88. TS1 y TS2 son un flujo continuo previo y un flujo continuo actual, respectivamente.

La Fig. 97 muestra un diagrama de temporización para la entrada, decodificación y visualización de paquetes de transporte cuando se transfieren desde un flujo continuo AV dado (TS1) al siguiente flujo continuo AV conectado sin interrupciones al mismo (TS2). Durante la transferencia desde un flujo continuo AV preestablecido (TS1) al siguiente flujo continuo AV conectado sin interrupciones al mismo (TS2), el eje de tiempo de la base de tiempos de llegada de TS2 no es el mismo que el eje de tiempo de la base de tiempos de llegada de TS1 (indicado por ATC1 en la Fig. 97).

Por otra parte, el eje de tiempo de la base de tiempos del sistema de TS2 (indicado por ATC1 en la Fig. 97) no es el mismo que el eje de tiempo de la base de tiempos del sistema de TS1 (indicado por STC1 en la Fig. 97). Se requiere que la visualización del vídeo sea continua sin interrupciones, aunque puede existir un solapamiento en el tiempo de visualización de las unidades de presentación.

Se explica la temporización de entrada para DVR-STD. Durante el periodo de tiempo hasta el tiempo T1, es decir, hasta la entrada del último paquete de vídeo en la TB1 de DVR-STD, la temporización de entrada a las memorias intermedias de TB1, TBn o TBsys de DVR-STD se determina mediante la arrival_time_stamp de la base de tiempos de llegada de TS1.

Los paquetes restantes de TS1 se deben introducir en memorias intermedias de TBn o en TBsys de DVR-STD a una velocidad de bits de TS_recording_rate (TS1). La TS_recording_rate (TS1) es el valor de TS_recording_rate definido en ClipInfo() correspondiente a Clip1. El tiempo en el cual el último byte de TS1 se introduce en la memoria intermedia es el tiempo T2. Así, durante el tiempo entre el tiempo T1 y el tiempo T2, se omite la arrival_time_stamp del paquete fuente.

Si N1 es el número de bytes del paquete de transporte de TS1 que va a continuación del último paquete de vídeo de TS1, el tiempo DT1 desde el tiempo T1 hasta el tiempo T2 es el tiempo necesario para que se introduzcan completamente N1 bytes a una velocidad de bits de TS_recording_rate (TS1), y se calcula de acuerdo con la siguiente ecuación:

DT1 = T2 - T1 = N1/TS_recording_rate.

Durante el tiempo desde el tiempo T1 hasta el tiempo T2 (TS1), ambos valores de RXn y RXsys se cambian al valor de TS-recording_rate (TS1). Excepto por esta regla, la operación de almacenamiento temporal es la misma que la de T-STD.

En el tiempo T2, el contador del reloj de tiempo de llegada se reinicializa al valor de arrival_time_stamp del primer paquete fuente de TS2. La temporización de entrada en la memoria intermedia de TB1, TBn, o TBsys de DVR-STD se determina por medio de la arrival_time_stamp del paquete fuente de TB2. Tanto RXn como RXsys se cambian a valores definidos en T-STD.

A título explicativo del almacenamiento temporal de audio y el almacenamiento temporal de datos de sistema adicionales, el decodificador de audio y el decodificador del sistema necesitan tener una cantidad de almacenamiento temporal adicional (cantidad de datos equivalente a un segundo) además de la cantidad de memoria intermedia definida en T-STD con el fin de permitir datos de entrada de un dominio desde el tiempo T1 al tiempo T2.

A título explicativo de la temporización de la presentación de vídeo, la visualización en la unidad de presentación de vídeo debe ser continua, es decir, desprovista de separaciones, a través del punto de unión. Se observa que STC1 es el eje de tiempo de la base de tiempos del sistema de TS1 (indicado como STC1 en la Fig, 9), mientras que STC2 es el eje de tiempo de la base de tiempos del sistema de TS2 (mostrado en STC2 en la Fig. 97; correctamente, STC2 comienza en el tiempo en el cual la primera PCR de TS2 se ha introducido en el T-STD).

El desplazamiento entre STC1 y STC2 se determina de la manera siguiente: la PTS1end es la PTS en SCT1 correspondiente a la última unidad de presentación de vídeo de TS2. PTS2start es la PTS en el SCT2 correspondiente a la primera unidad de presentación de vídeo de TS2 y Tpp es el periodo de tiempo de visualización de la última unidad de presentación de vídeo de TS1, el desplazamiento STC_delta entre dos bases de tiempos del sistema se calcula de acuerdo con la siguiente ecuación:

STC_delta = PTS1end + Tpp - PTS2start.

A título explicativo de la temporización de la presentación de audio, puede haber un solapamiento en la temporización de presentación de la unidad de presentación de audio, siendo el solapamiento menor que entre 0 y 2 tramas de audio (véase "solapamiento de audio" mostrado en la Fig. 97). La indicación de cuál de las muestras de audio deberá ser seleccionada y la re-sincronización de la presentación de la unidad de presentación de audio en la base de tiempos corregida, detrás del punto de unión, se fijan en el reproductor.

A título explicativo del reloj del tiempo del sistema de DVR-STD, la última unidad de presentación de audio de TS1 se presenta en el tiempo TS5. El reloj de tiempo del sistema puede solaparse entre el tiempo T2 y el tiempo T5. Durante este dominio de tiempo, el DVR-STD conmuta los relojes de tiempo del sistema entre el valor de la base de tiempos antigua (STC1) y el valor de la base de tiempos nueva (STC2). El valor de STC2 se puede calcular de acuerdo con la siguiente ecuación:

STC2 = STC1 - STC_delta.

Se explica la continuidad del almacenamiento temporal. STC11video_end es el valor de STC en la base de tiempos del sistema STC2 cuando el primer byte del primer paquete de vídeo alcanza TB1 de DVR-STD. STC22video_start es el valor de STC en la base de tiempos del sistema STC2 cuando el primer byte del primer paquete de vídeo alcanza TB1 de DVR-STD. STC21video_end es el valor de STC11video_end calculado como el valor en STC2 de la base de tiempos del sistema STC2. STC2video_end se calcula de acuerdo con la siguiente ecuación:

STC2video_end = STC11video_end - STC_delta.

Para obedecer a la DVR-STD, se deben cumplir las dos siguientes condiciones: En primer lugar, la temporización de llegada del primer paquete de vídeo de TS2 en TB1 debe satisfacer la siguiente desigualdad:

STC22video_start > STC21video_end + LT1.

Si es necesario re-codificar y/o multiplexar el flujo continuo parcial de Clip1 y/o Clip2, de manera tal que se satisfaga la anterior desigualdad, esta re-codificación o multiplexado se lleva a cabo según resulte apropiado.

En segundo lugar, la introducción del paquete de vídeo desde TS1 seguida por la introducción del paquete de vídeo desde TS2 en el eje de tiempo de la base de tiempos del sistema, con correspondencias establecidas a partir de STC1 y STC2 en el mismo eje de tiempo, no deben desbordar o provocar un subdesbordamiento de la memoria intermedia de vídeo.

Si la sintaxis, la estructura de datos y las reglas anteriores se usan como base, el contenido de datos grabados en el soporte de grabación o la información de reproducción se puede gestionar apropiadamente para permitir al usuario confirmar el contenido de datos grabados en el soporte de grabación en el momento de la reproducción o reproducir datos deseados de manera extremadamente fácil.

En la forma de realización descrita anteriormente, el flujo continuo de transporte MPEG 2 se toma como un ejemplo del flujo continuo multiplexado. Esto, sin embargo, es meramente ejemplificativo, de manera tal que el flujo continuo de programas MPEG 2 DSS o el flujo continuo de transporte usado en el servicio de DirecTV (marca comercial) de EE.UU. se puede usar también como flujo continuo multiplexado.

La Fig. 98 muestra una modificación de un archivo de PlayList. La diferencia notable entre la sintaxis de la Fig. 98 y la de la Fig. 99 es el lugar donde se almacena UIAppInfoPlayList(). En la forma de realización de la fig 98, en la cual UIAppInfoPlayList() está fuera de la PlayList(), la expansión de la información futura de UIAppInfoPlayList() se puede bastante fácilmente.

El version_number es cuatro cifras que indican el número de versión del archivo de información de encabezamiento de la imagen en miniatura.

PlayList_start_address (dirección_inicio_ListaReproducción) indica la dirección inicial de la PlayList() en términos del número de bytes relativos desde el extremo inicial del archivo de PlayList como unidad. El número de bytes relativos se cuenta desde 0.

PlayListMark_start_address (dirección_inicio_MarcaListaReproducción) indica la dirección inicial de PlayListMark() en términos del número de bytes relativos desde el byte inicial del archivo de PlayList como unidad. El número de bytes relativos se cuenta desde 0.

MakersPrivateData_start_address (dirección_inicio_DatosPrivadosFabricantes) indica la dirección inicial de MakersPrivateData en términos del número de bytes relativos desde el byte inicial del archivo de PlayList como unidad. El número de bytes relativos se cuenta desde 0.

La Fig. 99 muestra la sintaxis de UIAppInfoPlayList en el archivo de PlayList de la Fig. 98. PlayList_service_type (tipo_servicio_ListaReproducción) indica el tipo del archivo de PlayList, un ejemplo del cual se muestra en la Fig. 26. El PlayList_service_type puede tener el mismo significado que el del tipo de servicio mostrado por la emisión de radiodifusión de TV digital. Por ejemplo, en la radiodifusión BS de Japón, existen tres tipos de servicios, a saber, el servicio de TV, el servicio de audio y el servicio de radiodifusión de datos. El valor que representa el tipo de servicio del programa contenido en el Flujo continuo AV de fragmento usado por la PlayList se fija en el PlayList_service_type.

PlayList_character_set (conjunto_caracteres_ListaReproducción) indica el método de codificación para letras de caracteres codificadas en el campo channel_name (nombre_canal), PlayList_name y PlayList_detail (detalle_ListaReproducción), al mismo tiempo que indica el método de codificación para letras de caracteres codificadas en el campo mark_name en PlayListMark.

Channel_number (número_canal) indica el número de canal de radiodifusión o número del servicio según lo seleccione el usuario cuando se graba la PlayList. Si diversas PlayLists se combinan en una PlayList, channel_number indica un valor representativo de la PlayList. Si este campo se fija a 0XFFFF, el campo no tiene ningún significado.

Channel_name_length (longitud_nombre_canal) indica la longitud en bytes del nombre de canal indicado en el campo channel_name. Este campo tiene un valor no mayor que 20.

Channel_name indica el nombre del servicio o el canal de radiodifusión según lo seleccione el usuario cuando se graba la PlayList. El número de bytes de un número indicado por la channel_name_length desde la izquierda de este campo representa letras de caracteres efectivas e indica el nombre mencionado anteriormente. Los bytes restantes que van a continuación de estas letras de caracteres efectivas se pueden fijar a cualquier valor arbitrario. Si diversas PlayList se combinan en una PlayList, este campo indica el nombre representativo de la PlayList.

PlayList_name_length (longitud_nombre_ListaReproducción) indica la longitud en bytes del nombre de la PlayList indicado en el campo PlayList_name.

Play_list_name (nombre_lista_reproducción) muestra el nombre de la PlayList. El número de bytes del número indicado por la PlayList_name_length desde la izquierda de este campo representa las letras de caracteres efectivas e indica el nombre mencionado anteriormente. Los bytes restantes en este campo que van a continuación de estas letras de caracteres efectivas se pueden fijar a cualquier valor opcional.

PlayList_detail_length (longitud_detalle_ListaReproducción) indica la longitud en bytes de la información detallada de la PlayList indicada en el campo PlayList_detail. Este campo tiene un valor no más grande que 1.200.

PlayList_detail (detalle_ListaReproducción) indica el texto para ilustrar la información detallada de la PlayList. El número de bytes de un número indicado por PlayList_detail_length desde la izquierda de este campo es las letras de caracteres efectivas. Los bytes restantes en este campo que van a continuación de estas letras de caracteres efectivas se pueden fijar a cualquier valor opcional.

El significado de este campo de sintaxis es en otros aspectos el mismo que el del campo del mismo nombre mostrado en la Fig. 27.

La Fig. 100 muestra la sintaxis de PlayList() en el archivo de PlayList de la Fig. 98. Esta sintaxis es básicamente la misma que la forma de realización de la Fig. 25, excepto que la presente sintaxis falta en la UIAppInfoPlayList().

La Fig. 101 muestra una modificación de la sintaxis de SubPlayItem. La presente sintaxis difiere apreciablemente de la forma de realización de la Fig. 40 en que en este caso se ha añadido STC_sequence_id.

STC_sequence_id (id_secuencia_STC) indica el STC_sequence_id de STC a la que remiten SubPath_IN_time y SubPath_OUT_time usados para identificar el dominio de reproducción en el archivo de flujo continuo AV correspondiente a Clip_Information_file_name. SubPath_IN_time y SubPath_OUT_time indican el tiempo en el mismo dominio continuo de STC especificado por el STC_sequence_id.

Añadiendo STC_sequence_id al SubPlayltem, se permite que el archivo de flujo continuo AV al que remite SubPlayltem tenga un punto discontinuo de STC.

El campo de la sintaxis tiene en otros aspectos el mismo significado que el del campo del mismo nombre mostrado en la Fig. 40.

La Fig. 102 muestra el diagrama de flujo para ilustrar el método para formar Real PlayList. Se hace referencia al diagrama de bloques del aparato de grabación y/o reproducción mostrado en la Fig. 1.

En la etapa S11, el controlador 43 graba un Flujo continuo AV de fragmento. En la etapa S12, el controlador 23 comprueba si se puede preparar o no EP_map del flujo continuo AV. Si el

resultado de la comprobación en la etapa S12 es SÍ, el controlador 23 prosigue a la etapa S13. En otro cualquier otro caso, el controlador 23 prosigue a la etapa S14 para formar TU_map. En la etapa S15, el controlador 23 fija entonces el CLI_type de PlayList. En la etapa S16, el controlador 23 forma la PlayList() compuesta por Playltem que cubre el posible intervalo de

reproducción del Clip en su totalidad. Si CPI_type es del tipo EP_map, la información de tiempo se fija sobre la base de la PTS. Si existe un punto discontinuo de STC en el Clip, y la PlayList() está compuesta por dos o más Playltems, se determina también la connection_condition entre Playltems. Si CPI_type es del tipo TU_map, la información de tiempo se fija sobre la base del tiempo de llegada.

En la etapa S17, el controlador 23 forma UIAppInfoPlayList(). En la etapa S18, el controlador 23 forma PlayListMark. En la etapa S19, el controlador 23 forma MakerPrivateData. En la etapa S20, el controlador 23 forma el archivo de RealPlayList. Así, un archivo de Real PlayList se forma siempre que se acaba de grabar un Flujo continuo AV de fragmento. La Fig. 103 es un diagrama de flujo para ilustrar el método para formar la Virtual PlayList. En la etapa S31, una PlayList real, grabada en el disco, se especifica a través de la interfaz de usuario. A partir del

intervalo de reproducción de la Real PlayList, se especifica a través de la interfaz de usuario el intervalo de reproducción especificado por los puntos de IN y OUT. Si CPI_type es el tipo EP_map, el dominio de reproducción se fija sobre la base de la PTS. Si CPI_type es el tipo TU_map, el dominio de reproducción se fija sobre la base del tiempo de llegada.

En la etapa S32, el controlador 23 comprueba si ha finalizado o no la operación completa para especificar el intervalo de reproducción por el usuario. Si el usuario selecciona el dominio a reproducir a continuación del dominio de reproducción especificado, el controlador 23 vuelve a la etapa S31. Si la operación completa para especificar el intervalo de reproducción por el usuario ha llegado a su fin, el controlador 23 prosigue hacia la etapa S33.

En la etapa S33, la condición de conexión (Connection_condition) entre dos dominios de reproducción reproducidos

consecutivamente se determina por parte del usuario a través de la interfaz o mediante el controlador 23. Si, en la etapa S34 el CPI_type es el tipo EP_map, el usuario especifica la información de sub-ruta (información de audio de post-grabación). Esta etapa se omite si la sub-ruta no es formada por el usuario.

En la etapa S35, el controlador 23 forma la PlayList() sobre la base de la información del intervalo de reproducción especificada por el usuario y según la connection_condition. En la etapa S36, el controlador 23 forma UIAppInfoPlayList(). En la etapa S37, el controlador 23 forma PlayListMark. En la etapa S38, el controlador 23 forma MakersPrivateData.

En la etapa S39, el controlador 23 forma el archivo de VirtualPlayList. De esta manera, se forma un archivo de PlayList virtual para cada grupo de los dominios de reproducción que se seleccionan a partir del intervalo de reproducción de la Real PlayList grabada en el disco y que el usuario desea ver.

La Fig. 104 es un diagrama de flujo para explicar el método de reproducción de la PlayList. En la etapa S51, el controlador 23 adquiere la información sobre el Info.dvr, el archivo de Información de Fragmento, el archivo de PlayList y el archivo de imágenes en miniatura y forma una imagen de GUI que muestra una lista de

PlayLists grabadas en el disco para visualizar la imagen de la GUI así formada, en la GUI a través de la interfaz de usuario. En la etapa S52, el controlador 23 presenta la información que explica la PlayList en la imagen de la GUI, basándose

en la UIAppInfoPlayList en las PlayLists respectivas.

En la etapa S53, el usuario ordena la reproducción de una PlayList a partir de la imagen de la GUI a través de la interfaz de usuario.

Si el CPI_type es el tipo EP_map, el controlador 23 en la etapa S54 adquiere, a partir del STC_sequence_id y la PTS de IN_time, el número del paquete fuente que tiene un punto de entrada temporalmente previo y más próximo a IN_time. Si el CPI_type es el tipo TU_map, el controlador 23 adquiere, a partir del IN_time del Playltem actual, el número del paquete fuente donde comienza la unidad de tiempo temporalmente previa y más próxima a IN_time.

En la etapa S55, el controlador 23 lee datos del flujo continuo AV desde el número del paquete fuente adquirido en la etapa anterior para encaminar los datos así leídos al decodificador AV 27.

Si en la etapa S56, existe el Playltem temporalmente previo al Playltem actual, el controlador 23 lleva a cabo el procesado de conexión de visualización entre el Playltem previo y el Playltem actual, de acuerdo con la connection_condition.

Si en la etapa S57, el CPI_type es el tipo EP_map, el decodificador AV 27 ordena que la visualización se inicie a partir de la imagen de la PTS de IN_time. Si el CPI_type es el tipo TU_map, el decodificador AV 27 ordena que la visualización se inicie a partir de la imagen del flujo continuo posterior a IN_time.

En la etapa S58, el controlador 23 ordena al decodificador AV 27 que continúe decodificando el flujo continuo AV.

Si CPI_type es el tipo EP_map, el controlador 23 en la etapa S59 comprueba si la imagen visualizada actualmente es o no la imagen de la PTS de OUT_time. Además, si el CPI_type es el tipo TU_map, el controlador 23 comprueba si el flujo continuo actualmente decodificado está más allá o no del OUT_time.

Si el resultado de la comprobación en la etapa S59 es NO, el controlador 23 prosigue a la etapa S60. En la etapa S60, el controlador 23 visualiza la imagen actual para a continuación volver a la etapa S58. Si el resultado de lacomprobación en la etapa S59 es SÍ, el controlador 23 prosigue a la etapa S61.

En la etapa S61, el controlador 23 comprueba si el Playltem actual es o no el último Playltem en la PlayList. Si el resultado de la comprobación es NO, el controlador 23 vuelve a la etapa S54 y, en otro caso, se finaliza la reproducción de la PlayList.

La Fig. 105 es un diagrama de flujo para ilustrar el método de reproducción de la SubPath de la PlayList. El método de reproducción de sub-rutas de la Fig. 105 se usa solamente si el CPI_type de la PlayList es EP_map. El procesado del diagrama de flujo se lleva a cabo simultáneamente con el procesado posterior a la etapa S54 en la reproducción de la PlayList de la Fig. 104. Mientrastanto, se presupone que el decodificador AV 27 tiene la capacidad de decodificar dos flujos continuos de audio simultáneamente.

En la etapa S71, el controlador 23 adquiere la información de SubPlayltem.

En la etapa S72, el controlador 23 adquiere el número de paquete fuentes que tiene un punto de entrada temporalmente previo y más próximo a SubPath_IN_time.

En la etapa S73, el controlador 23 lee datos del flujo continuo AV de la sub-ruta desde el número de paquete fuente que tiene el anterior punto de entrada para encaminar los datos así leídos al decodificador AV 27.

En la etapa S74, el controlador 23 ordena al decodificador AV 27 que comience a presentar el audio de la subruta cuando la reproducción de la ruta principal alcanza la imagen especificada por el sync_PlayItem_id y el sync_start_PTS_of_PlayItem.

En la etapa S75, el decodificador AV 27 continúa decodificando el flujo continuo AV de la subruta.

En la etapa S76, el controlador 23 comprueba si la PTS de la sub-ruta visualizada actualmente es o no el SubPath_OUT_time. Si el resultado de la comprobación es NO, el controlador 23 prosigue a la etapa S77, donde el controlador 23 continúa visualizando la subruta. El controlador 23 vuelve a continuación a la etapa S75.

Si en la etapa S76, la PTS de la subruta actualmente visualizada es SubPath_OUT_time, se finaliza la visualización de la sub-ruta.

La ruta principal y la sub-ruta de un archivo de PlayList, cuya reproducción ha sido ordenada por un usuario, se reproducen, tal como se muestra en las Figs. 104 y 105.

La Fig. 106 muestra un diagrama de flujo para ilustrar el método para formar la PlayListMark. Se hace referencia al diagrama de bloques del aparato de grabación y/o reproducción de la Fig. 1.

En la etapa S91, el controlador 23 adquiere la información sobre el Info.dvr, el archivo de Información de Fragmento, el archivo de PlayList y el archivo de imágenes en miniatura y forma una imagen de GUI que muestra una lista de PlayLists grabadas en el disco, para visualizar la imagen de la GUI así formada en la GUI, a través de la interfaz de usuario.

En la etapa S92 el usuario ordena al controlador 23 que reproduzca una PlayList, a través de la interfaz de usuario.

En la etapa S93, el controlador 23 provoca la reproducción de la PlayList especificada cuando su inicio sea ordenado (véase la Fig. 104).

En la etapa S94, el usuario ordena al controlador 23 que fije una marca en una escena favorita, a través de la interfaz de usuario.

Si, en la etapa S95, el CPI_type es EP_map, el controlador 23 adquiere la PTS de la marca y el PlayItem_id del PlayItem al que pertenece. Además, el controlador 23 adquiere el tiempo de llegada del punto de marca, si el CPI_type es TU_map.

En la etapa S95, en controlador 23 almacena la información de la marca en la PlayListMark().

En la etapa S97, el controlador 23 graba el archivo de PlayList en el soporte de grabación 100.

La Fig. 107 es un diagrama de flujo para ilustrar el método de localización de reproducción, que utiliza la PlayListMark. Se hace referencia al diagrama de bloques del aparato de grabación y/o reproducción 1 de la Fig. 1.

En la etapa S111, el controlador 23 adquiere la información sobre el Info.dvr, el archivo de Información de Fragmento, el archivo de PlayList y el archivo de imágenes en miniatura, y forma una imagen de GUI que muestra una lista de PlayLists grabadas en el disco (soporte de grabación 100) para visualizar la imagen de la GUI así formada en la GUI, a través de la interfaz de usuario.

En la etapa S112, el usuario ordena al controlador 23 que reproduzca una PlayList, a través de la interfaz de usuario.

En la etapa S113, el controlador 23 provoca la visualización de la lista de imágenes en miniatura, generada a partir de la imagen a la que remite PlayListMark, en la GUI a través de la interfaz de usuario.

En la etapa S114, el usuario especifica el punto de marca del punto de inicio de reproducción, a través de la interfaz de usuario.

Si el CPI_type es el tipo EP_map, el controlador 23 adquiere la PTS de la marca y el Playltem_id al QUE pertenece. Si el CPI_type es el tipo TU_map, el controlador 23 adquiere la ATS (Indicación de Tiempo de Llegada) de la marca.

Si el CPI_type es el tipo EP_map, el controlador 23 en la etapa S116 adquiere la STC-sequence_id del flujo continuo AV al que remite el Playltem especificado por el Playltem_id.

En la etapa S117, si el CPI_type es el tipo EP_map, el controlador 23 provoca que el flujo continuo AV se introduzca en el decodificador, sobre la base de la PTS de la marca y del STC-sequence_id. Específicamente, el controlador 23 lleva a cabo el procesado similar al de la etapa S55, usando la PTS de la marca y según el STC_sequence_id. Si CPI_type es TU_type, el controlador 23 provoca que el flujo continuo AV se introduzca en el decodificador, sobre la base del ATS de la marca. Específicamente, el controlador lleva a cabo el procesado similar al de la etapa S54 y la etapa S55 de la Fig. 104, usando el ATS.

Si en la etapa S118, el CPI_type es el tipo EP_map, el controlador 23 provoca que se inicie la visualización a partir de la imagen de la PTS del punto de marca. Si el CPI_type es el tipo TU_map, el controlador 23 provoca que se inicie la visualización desde una imagen detrás del ATS del punto de marca.

De esta manera, el usuario selecciona, por ejemplo, un punto de inicio de una escena favorita desde la PlayList. El punto de inicio seleccionado de esta manera se supervisa por medio del grabador (el controlador 23 del aparato de grabación y/o reproducción 1) en la PlayListMark. Además, el usuario selecciona el punto de inicio de la reproducción desde la lista de los puntos de marca almacenada en la playListMark, de manera que el reproductor comienza la reproducción en el punto de inicio, tal como se muestra en la Fig. 107.

Si la sintaxis, la estructura de datos, y las reglas anterior se usan como base, el contenido de datos grabados en el soporte de grabación o la información de reproducción se pueden gestionar apropiadamente, para permitir al usuario confirmar el contenido de datos grabados en el soporte de grabación en el momento de la reproducción, o reproducir datos deseados de una manera extremadamente fácil.

Si se puede analizar la posición de una imagen I, el flujo continuo AV de diferentes formatos se puede grabar, reproducir y gestionar usando un programa de aplicación común (software), sujeto a la utilización de TU_map.

Si el flujo continuo AV se graba en el soporte de grabación a medida que se analiza (grabación con reconocimiento) su contenido (posición de la imagen I), se usa el EP_map, mientras que si el flujo continuo AV se graba directamente en el soporte de grabación sin analizar su contenido (posición de la imagenI) (grabación sin reconocimiento), se usa el TU_map. Así, los datos AV se pueden grabar, reproducir y gestionar, usando un programa de aplicación común.

Así, si los datos AV aleatorizados se desaleatorizan con análisis para grabarlos en el soporte de grabación, se usa el EP_map, mientras que si los datos AV aleatorizados se graban directamente en el soporte de grabación sin desaleatorización (sin análisis), se usa el TU_map. Haciéndolo así, los datos AV se pueden grabar, reproducir y gestionar usando el programa de aplicación común.

Por otra parte, el tipo EP_map y el tipo TU_map se pueden describir en la PlayList(), como CPI_type, el TU_map se puede usar si se puede analizar la posición de la imagen I, mientras que si la posición de la imagen I no se puede analizar, se puede usar el TU_map. Haciéndolo así, los datos de flujo continuo AV grabados con análisis de la posición de la imagen I y los datos de flujo continuo AV grabados sin análisis de la posición de la imagen I se pueden gestionar de un modo unificado mediante un programa común, simplemente fijando una bandera correspondiente.

Por otra parte, el archivo de PlayList y el archivo de Información de Fragmento se graban por separado, de manera que, si el contenido de una PlayList o Clip dados se cambia, por ejemplo editándolo, no es necesario cambiar un archivo irrelevante para el archivo cambiado. El resultado es que el contenido del archivo se puede cambiar fácilmente para reducir el tiempo necesario en dicho cambio o grabación.

Adicionalmente, si solamente se lee el Info.dvr en primer lugar para presentar el contenido de la grabación del disco a la interfaz de usuario, con el fin de leer desde el disco solamente el archivo de PlayList cuya reproducción ha sido ordenada por el usuario y el archivo de Información de Fragmento relevante, se puede reducir el tiempo de espera en cola del usuario.

Si la totalidad de archivos de PlayList o archivos de Información de Fragmento se recopila en un archivo para la grabación, el tamaño del archivo resulta elevado. Así, el tiempo involucrado en el cambio del contenido del archivo para su grabación es apreciablemente mayor que el correspondiente en caso de que los archivos respectivos se graben por separado. La presente invención tiene como objetivo superar esta deficiencia.

La secuencia de operaciones descrita anteriormente se puede ejecutar no solamente mediante hardware sino también mediante softare. Si la secuencia de operaciones se va a ejecutar mediante software, el mismo se instala desde un soporte de grabación en un ordenador en el hardware dedicado cuyo programa forma el software o un ordenador personal de propósito general de la Fig. 38 con capacidad de ejecutar varias funciones sobre la base de una variedad de programas instalados en el mismo.

El soporte de grabación esta constituido no solamente por un soporte en paquetes distribuido para proporcionar el programa al usuario, además de un ordenador, tal como un disco magnético 221 que contiene el programa en el mismo, incluyendo un disco flexible, un disco óptico 222, incluyendo un CD-ROM (Disco Compacto-Memoria de Solo Lectura) o un DVD (Disco Versátil Digital), un disco magneto-optico 223, incluyendo un Mini-Disco, o una memoria de semiconductores 224, sino también por un disco duro, incluyendo una ROM 202 que contenga un programa y una memoria 208, proporcionados al usuario en la medida en la que estén incorporados en un ordenador, tal como se muestra en la Fig. 108.

En la presente memoria descriptiva, las etapas del programa proporcionado por el soporte incluyen no solamente el procesado cronológico de acuerdo con la secuencia indicada, sino también el procesado llevado a cabo no cronológicamente sino en paralelo o por separado.

Adicionalmente, en la memoria descriptiva, sistema significa un aparato completo compuesto por diversos dispositivos componentes.

Aplicabilidad industrial

En el método y el aparato de procesado de información según la presente invención, el programa para un soporte de grabación, el programa y el soporte de grabación, según la presente invención, se graba, en función del método de grabación, una de una primera tabla que establece la relación de correspondencia entre la marca de tiempo de presentación y la dirección en los datos de flujo continuo AV en la unidad de acceso correspondiente y una segunda tabla que establece la relación de correspondencia entre la indicación de tiempo de llegada obtenida a partir del instante de tiempo de llegada del paquete de transporte y la dirección en los datos de flujo continuo AV en el paquete de transporte correspondiente.

En el método y aparato de procesado de información, el programa para un soporte de grabación, y el programa, según la presente invención, se reproduce, desde el soporte de grabación para controlar la salida, una de una primera tabla que establece la relación de correspondencia entre la marca de tiempo de presentación y la dirección

5 en los datos de flujo continuo AV en la unidad de acceso correspondiente y una segunda tabla que establece la relación de correspondencia entre la indicación de tiempo de llegada obtenida a partir del instante de tiempo de llegada del paquete de transporte y la dirección en los datos de flujo continuo AV en el paquete de transporte correspondiente, según se han grabado en un soporte de grabación en función del método de grabación.

10 En el método y el aparato de procesado de información, el programa para un soporte de grabación, el programa, y el segundo soporte de grabación, según la presente invención, se graba la información de especificación de reproducción compuesta por la primera información que especifica la ruta principal de reproducción y la segunda información que especifica la ruta de reproducción secundaria en sincronismo con la ruta de reproducción principal.

15 En el método y el aparato de procesado de información, el programa para un soporte de grabación, y el programa, según la presente invención, se reproduce, desde el soporte de grabación para controlar la salida de forma correspondiente, la información de especificación de reproducción compuesta por la primera información que especifica la ruta de reproducción principal y la segunda información que especifica la ruta de reproducción secundaria.

20 Así, en cualquier caso, el flujo continuo AV con capacidad de alta velocidad de reproducción y el flujo continuo AV sin capacidad de alta velocidad de reproducción se pueden gestionar en común, al mismo tiempo que también resulta posible la post-grabación.

Claims

REIVINDICACIONES

1. Aparato de procesado de información (2) para grabar flujos continuos AV en un soporte de grabación (100) como fragmentos, comprendiendo cada fragmento información de fragmento y datos de flujo continuo AV

5 correspondientes, estando la información de fragmento y los datos de flujo continuo AV correspondientes almacenados en archivos respectivos, incluyendo los flujos continuos AV datos de marca de tiempo de presentación, comprendiendo dicho aparato:

un controlador (23) que se puede hacer funcionar para generar (a) información de fragmento que incluye un

10 mapa de puntos de entrada que describe la relación entre una marca de tiempo de presentación de una imagen I que proporciona un punto de entrada a los datos de flujo continuo AV de dicho fragmento, y un número de paquete fuente relativo que representa la dirección de datos de una unidad de acceso para el punto de entrada correspondiente, siendo contado el número de paquete fuente relativo desde el primer paquete fuente del archivo de datos de flujo continuo AV, y (b) una lista de reproducción que incluye información de ruta principal que indica

15 una ruta principal compuesta por un primer elemento de reproducción AV e información de ruta secundaria que indica una ruta secundaria compuesta por un segundo elemento de reproducción de audio, correspondiendo cada elemento de reproducción a un fragmento, e incluyendo dicha información de ruta secundaria una marca de tiempo de presentación que indica un tiempo de inicio de presentación, basándose en el eje de tiempo de la ruta principal, para iniciar la reproducción de la ruta secundaria de dicho segundo elemento de reproducción, de

20 manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se pueda sincronizar con la reproducción de dicho primer elemento de reproducción sobre la ruta principal; y

una unidad de escritura (22) que se puede hacer funcionar para grabar fragmentos, incluyendo la información de fragmento y los datos de flujo continuo AV de fragmento, y la lista de reproducción, incluyendo la información de

25 ruta principal y la información de ruta secundaria, en el soporte de grabación.
2. Aparato según la reivindicación 1, en el que dicha información de ruta secundaria incluye información de tiempo de ENTRADA e información de tiempo de SALIDA que indican un tiempo de inicio de presentación y un tiempo final de la ruta secundaria.
3. Aparato según la reivindicación 2, en el que dichos tiempo de ENTRADA y tiempo de SALIDA están en el mismo dominio continuo del reloj de tiempo del sistema que la ruta principal.
4. Aparato según la reivindicación 3, en el que dicha lista de reproducción incluye información de identificación que 35 indica el dominio de reloj de tiempo de sistema que tiene dichos tiempo de ENTRADA y tiempo de SALIDA.
5. Aparato según la reivindicación 1, en el que dicho controlador genera la información de ruta secundaria para la post-grabación.

40 6. Aparato según la reivindicación 1, en el que dicho controlador genera la información de ruta secundaria cuando se introduce información de audio auxiliar para la post-grabación.
7. Método para grabar flujos continuos AV en un soporte de grabación (100) como fragmentos, comprendiendo cada fragmento información de fragmento y datos de flujo continuo AV correspondientes, estando la información de

45 fragmento y los datos de flujo continuo AV correspondientes almacenados en archivos respectivos, incluyendo los flujos continuos AV datos de marca de tiempo de presentación, comprendiendo dicho método:

generar (a) información de fragmento que incluye un mapa de puntos de entrada que describe la relación entre una marca de tiempo de presentación de una imagen I que proporciona un punto de entrada a los datos de flujo 50 continuo AV de dicho fragmento, y un número de paquete fuente relativo que representa la dirección de datos de una unidad de acceso para el punto de entrada correspondiente, siendo contado el número de paquete fuente relativo desde el primer paquete fuente del archivo de datos de flujo continuo AV, y (b) una lista de reproducción que incluye información de ruta principal que indica una ruta principal compuesta por un primer elemento de reproducción AV e información de ruta secundaria que indica una ruta secundaria compuesta por un segundo 55 elemento de reproducción de audio, correspondiendo cada elemento de reproducción a un fragmento, incluyendo dicha información de ruta secundaria una marca de tiempo de presentación que indica un tiempo de inicio de presentación, basándose en el eje de tiempo de la ruta principal, para iniciar la reproducción de la ruta secundaria de dicho segundo elemento de reproducción, de manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se pueda sincronizar con la reproducción de dicho primer elemento de

60 reproducción sobre la ruta principal; y

grabar fragmentos, incluyendo la información de fragmento y los datos de flujo continuo AV de fragmento, y la lista de reproducción, incluyendo la información de ruta principal y la información de ruta secundaria, en el soporte de grabación.
8. Método según la reivindicación 7, en el que dicha información de ruta secundaria incluye información de tiempo de ENTRADA e información de tiempo de SALIDA que indican un tiempo de inicio de presentación y un tiempo final de la ruta secundaria.

5 9. Método según la reivindicación 8, en el que dichos tiempo de ENTRADA y tiempo de SALIDA están en el mismo dominio continuo del reloj de tiempo del sistema que la ruta principal.
10.

Método según la reivindicación 9, en el que dicha lista de reproducción incluye información de identificación que indica el dominio de reloj de tiempo de sistema que tiene dichos tiempo de ENTRADA y tiempo de SALIDA.
11.

Método según la reivindicación 7, en el que la información de ruta secundaria se genera para la post-grabación.
12.

Método según la reivindicación 7, en el que la información de ruta secundaria se genera cuando se introduce

información de audio auxiliar para la post-grabación. 15
13. Aparato para reproducir información de audio e imágenes, que comprende:

un dispositivo de reproducción (3) para reproducir desde un soporte de almacenamiento (100) en el cual se graban flujos continuos AV como fragmentos, comprendiendo cada fragmento información de fragmento y datos de flujos continuo AV correspondientes, estando almacenados la información de fragmento y los datos de flujo continuo AV correspondientes en archivos respectivos, incluyendo los flujos continuos AV datos de marca de tiempo de presentación, incluyendo dicha información de fragmento un mapa de puntos de entrada que describe la relación entre una marca de tiempo de presentación de una imagen I que proporciona un punto de entrada a los datos de flujo continuo AV de dicho fragmento, y un número de paquete fuente relativo que representa la 25 dirección de datos de una unidad de acceso para el punto de entrada correspondiente, siendo contado el número de paquete fuente relativo desde el primer paquete fuente del archivo de datos del flujo continuo AV, y teniendo también grabada en el mismo el soporte de almacenamiento una lista de reproducción que incluye información de ruta principal que indica una ruta principal compuesta por un primer elemento de reproducción AV e información de ruta secundaria que indica una ruta secundaria compuesta por un segundo elemento de reproducción de audio, correspondiendo cada elemento de reproducción a un fragmento, e incluyendo dicha información de ruta secundaria una marca de tiempo de presentación que marca un tiempo de inicio de presentación, basándose en el eje de tiempo de la ruta principal, para iniciar la reproducción de la ruta secundaria de dicho segundo elemento de reproducción, de manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se pueda sincronizar con la reproducción de dicho primer elemento de

35 reproducción sobre la ruta principal;

una unidad de recuperación para recuperar la información de ruta principal, la información de ruta secundaria, y el mapa de puntos de entrada; y

una unidad de reproducción de información AV para reproducir el flujo continuo AV asociado a la información de rutas y el mapa recuperados, de tal manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria esté sincronizada con la reproducción de dicho primer elemento de reproducción sobre la ruta principal.

45 14. Aparato según la reivindicación 13, en el que dicha información de ruta secundaria incluye información de tiempo de ENTRADA e información de tiempo de SALIDA que indican un tiempo de inicio de presentación y un tiempo final de la ruta secundaria.
15.

Aparato según la reivindicación 14, en el que dichos tiempo de ENTRADA y tiempo de SALIDA están en el mismo dominio continuo del reloj de tiempo del sistema que la ruta principal.
16.

Aparato según la reivindicación 13, en el que dicha lista de reproducción incluye información de identificación que indica el dominio de reloj de tiempo de sistema que tiene dichos tiempo de ENTRADA y tiempo de SALIDA.

55 17. Aparato según la reivindicación 13, en el que la información de ruta secundaria se usa para la post-grabación.
18.

Aparato según la reivindicación 13, en el que la información de rutas se almacena cuando se usa información de audio auxiliar para la post-grabación.
19.

Método para reproducir información de audio e imágenes, comprendiendo el método:

reproducir información de audio y de imágenes desde un soporte de almacenamiento (100) en el cual se graban flujos continuos AV como fragmentos, comprendiendo cada fragmento información de fragmento y datos de flujos continuo AV correspondientes, siendo la información de fragmento y los datos de flujo continuo AV 65 correspondientes almacenados en archivos respectivos, incluyendo los flujos continuos AV datos de marca de tiempo de presentación, incluyendo dicha información de fragmento un mapa de puntos de entrada que describe

la relación entre una marca de tiempo de presentación de una imagen I que proporciona un punto de entrada a los datos de flujo continuo AV de dicho fragmento, y un número de paquete fuente relativo que representa la dirección de datos de una unidad de acceso para el punto de entrada correspondiente, siendo contado el número de paquete fuente relativo desde el primer paquete fuente del archivo de datos del flujo continuo AV, y teniendo también grabada en el mismo el soporte de almacenamiento una lista de reproducción que incluye información de ruta principal indicativa de una ruta principal compuesta por un primer elemento de reproducción AV e información de ruta secundaria que indica una ruta secundaria compuesta por un segundo elemento de reproducción de audio, correspondiendo cada elemento de reproducción a un fragmento, e incluyendo dicha información de ruta secundaria una marca de tiempo de presentación que indica un tiempo de inicio de presentación, basándose en el eje de tiempo de la ruta principal, para iniciar la reproducción de la ruta secundaria de dicho segundo elemento de reproducción, de manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se pueda sincronizar con la reproducción de dicho primer elemento de reproducción sobre la ruta principal;

recuperar la información de ruta principal, la información de ruta secundaria, y el mapa de puntos de entrada; y

reproducir el flujo continuo AV asociado a la información de rutas y el mapa de puntos de entrada recuperados, de tal manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se sincroniza con la reproducción de dicho primer elemento de reproducción sobre la ruta principal.
20.

Método según la reivindicación 19, en el que dicha información de ruta secundaria incluye información de tiempo de ENTRADA e información de tiempo de SALIDA que indican un tiempo de inicio de presentación y un tiempo final de la ruta secundaria.
21.

Método según la reivindicación 20, en el que dichos tiempo de ENTRADA y tiempo de SALIDA están en el mismo dominio continuo del reloj de tiempo del sistema que la ruta principal.
22.

Método según la reivindicación 19, en el que dicha lista de reproducción incluye información de identificación que indica el dominio de reloj de tiempo de sistema que tiene dichos tiempo de ENTRADA y tiempo de SALIDA.
23.

Método según la reivindicación 19, en el que la información de ruta secundaria se usa para la post-grabación.
24.

Método según la reivindicación 19, en el que la información de ruta se almacena cuando se usa información de audio auxiliar para la post-grabación.
25.

Soporte de grabación (221, 222, 223, 224) adaptado para ser usado con un ordenador y que tiene grabados en el mismo flujos continuos AV como fragmentos, comprendiendo cada fragmento información de fragmento y datos de flujos continuo AV correspondientes, estando la información de fragmento y los datos de flujo continuo AV correspondientes almacenados en archivos respectivos, incluyendo los flujos continuos AV datos de marca de tiempo de presentación, incluyendo dicha información de fragmento un mapa de puntos de entrada que describe la relación entre una marca de tiempo de presentación de una imagen I que proporciona un punto de entrada a los datos de flujo continuo AV de dicho fragmento, y un número de paquete fuente relativo que representa la dirección de datos de una unidad de acceso para el punto de entrada correspondiente, siendo contado el número de paquete fuente relativo desde el primer paquete fuente del archivo de datos del flujo continuo AV, y teniendo también grabada en el mismo el soporte de almacenamiento una lista de reproducción que incluye información de ruta principal que indica una ruta principal compuesta por un primer elemento de reproducción AV e información de ruta secundaria que indica una ruta secundaria compuesta por un segundo elemento de reproducción de audio, correspondiendo cada elemento de reproducción a un fragmento, e incluyendo dicha información de ruta secundaria una marca de tiempo de presentación que indica un tiempo de inicio de presentación, basándose en el eje de tiempo de la ruta principal, para iniciar la reproducción de la ruta secundaria de dicho segundo elemento de reproducción, de manera que la reproducción del segundo elemento de reproducción sobre la ruta secundaria se pueda sincronizar con la reproducción de dicho primer elemento de reproducción sobre la ruta principal.