KR20040105761A - 종속 데이터 플로우 전송을 위한 방법 - Google Patents

종속 데이터 플로우 전송을 위한 방법 Download PDF

Info

Publication number
KR20040105761A
KR20040105761A KR10-2004-7014101A KR20047014101A KR20040105761A KR 20040105761 A KR20040105761 A KR 20040105761A KR 20047014101 A KR20047014101 A KR 20047014101A KR 20040105761 A KR20040105761 A KR 20040105761A
Authority
KR
South Korea
Prior art keywords
stream
unit
data
terminal
received
Prior art date
Application number
KR10-2004-7014101A
Other languages
English (en)
Other versions
KR100984662B1 (ko
Inventor
코타매나끄알렉산드르
Original Assignee
프랑스 텔레콤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR0202992A external-priority patent/FR2827447B1/fr
Application filed by 프랑스 텔레콤 filed Critical 프랑스 텔레콤
Publication of KR20040105761A publication Critical patent/KR20040105761A/ko
Application granted granted Critical
Publication of KR100984662B1 publication Critical patent/KR100984662B1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64784—Data processing by the network
    • H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23412—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs for generating or manipulating the scene composition of objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26275—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for distributing content or additional data in a staggered manner, e.g. repeating movies on different channels in a time-staggered manner in a near video on demand system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44012—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving rendering scenes according to scene graphs, e.g. MPEG-4 scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47205—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for manipulating displayed content, e.g. interacting with MPEG-4 objects, editing locally
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/12—Systems in which the television signal is transmitted via one channel or a plurality of parallel channels, the bandwidth of each channel being less than the bandwidth of the television signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Optical Communication System (AREA)
  • Information Transfer Between Computers (AREA)
  • Communication Control (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)
  • Meter Arrangements (AREA)

Abstract

본 발명은 데이터 흐름의 전송 방법에 관한 것으로, 그 방법에 해당하는 데이터 흐름, 서버, 단말, 수신 방법 및 사용에 관한 것이다. 본 발명은 적어도 하나의 단말을 향한 적어도 하나의 데이터 흐름의 전송 방법에 관한 것으로, 상기 흐름(flow) 또는 복수의 흐름(flows)은 흐름 유닛의 형태로 구성되고, 상기 흐름 유닛의 적어도 일부는, 단말에서의 처리를 최적화하고 및/또는 상기 흐름(들)의 흐름 속도를 유용화하기 위해서, 상기 흐름 또는 다른 흐름의 적어도 하나의 흐름 유닛을 항하여 가리키는 적어도 하나의 포이터를 포함하는 것을 특징으로 한다.

Description

종속 데이터 플로우 전송을 위한 방법{METHOD FOR THE TRANSMISSION OF DEPENDENT DATA FLOWS}
신호, 예를 들어 멀티미디어 타입의 신호가 동기 방식으로 단일 채널을 통하여 전송되는 경우에, 하나의 스트림 유닛의 처리는 거의 문제가 발생되지 않는다. 즉 필요한 데이터는 미리 수신된다.
한편, 예를 들어, IP 타입 네트워크를 통하여 전송 또는 방송하는 것과 같이, 복수의 전송 채널 및/또는 복수의 서버 - 여기서, 각각의 채널 및 서버는 요구되는 신호의 한 부분을 전송함 - 에 의해서 구현되는 비동기 시스템에서는 문제가 발생하게 된다.
이 경우에는, 수신되지 않는 다른 신호들을 완성시킬 수 있는 스트림 유닛을수신할 수 있다. 예를 들어, 더 높은 차원의 계층 레벨의 데이터 풍부(enrichment) 정보에 관한 것이다. 여기에서, 데이터는 계층적인 인코딩을 사용하여 인코딩된다. (따라서, 스트림은 주어진 계층적 레벨에 해당하게 된다.) 따라서, 풍부 데이터의 처리는 불규칙적 결과를 초래하고, 일반적으로 복구된 신호가 심각하게 열화되거나, 또는 심지어 디코더가 완전하게 차단되게 된다.
멀티미디어 동기화에 있어서 공지된 종래 기술은 RTP 기반 전송 프로토콜 및 MPEG-4(동기화 계층)에 의해서 표현된다. 종래 기술의 방법에 있어서, 동기화 메카니즘은, 그것들이 지연없이 표현될 수 있도록 하기 위해서, 오디오 및 비디오 스트림을 일시적으로 동기화하도록 디자인된다. 이러한 데이터는 시간 스탬핑(time stamping) 시스템 (참조 클록, 디코딩 및 표현 스탬프(presentation stamp))을 사용하여 전송된다.
다양한 시간 및 공간 풍부 레벨이 사용되어 재현 프레임(presentable frame)을 제공하는, 계층적인 인코딩이 사용되는 경우에는 새로운 동기화가 필요하게 된다.
따라서 스트림은 (그것들의 표현 기간동안뿐만 아니라) 디코딩되기 전에 반드시 동기화되어야한다. 유닛을 디코딩하기 위해서 필요한 유닛들은 정확한 프레임을 생성하기 위해서 반드시 식별되어야하기 때문에 그러한 제한은 표현 동기화보다 더욱 복잡하다. 단일의 지연은 전체의 스트림 및 전체 스트림에 기반한 모든 스트림을 리드하여 사용불가하게 만든다. 이것은 본 발명자에 의해서 확인된, 명확하지는 않지만, 신규한 문제점이다.
유사한 문제점이, 단말이 수신하여야 하지만 수신하지 않은 데이터 (예를 들어, 디코딩 키)를 사용하여 수신된 스트림 유닛이 반드시 디코드, 또는 복호화되어야 하는 경우에 발생한다. 즉, 디코딩 절차의 결과는 적어도 비능률적이거나, 일반적으로는 유해하고(회복된 신호의 관점에서), 단말의 차단을 초래할 수 있다. 이러한 두 가지 경우에 있어서, 바람직하지 않거나 문제가 되는 처리가 수행된다.
방송(멀티 캐스팅 또는 브로드 캐스팅) 시스템에 발생하는 다른 심각한 문제점은, 동일한 데이터가 멀티 브로드캐스트되어 모든 순간(instant)에서 접속하는 모든 사용자가 선택한 모든 스트림들을 수신할 수 있어야 하는 것이다. 이러한 측면은 특허 출원되었지만, 미공개된 본 발명의 출원인과 동일한 주체에 의한 EP- 014600462 호에서 이미 개시되어 있다. 그 특허출원에 있어서는, 처리(processing)는, 다양한 전송 타입의 특징을 고려하여, 각각의 스트림 유닛의 프로세싱을 하는 전송 레벨에서 수행된다.
브로드캐스트 및 멀티캐스트 시나리(scenarii)에 있어서 멀티미디어 표현에 대한 종래의 기술은 “carousel MPEG-4 Nonetheless"의 명세에 개시되어 있고, 따라서, 어떤 기능은 금지되거나 높은 데이터 속도의 소비자가 된다. 고려되는 2 가지 전송 시나리에 있어서, 멀티미디어 표현에의 입력 포인트는 항상 지시되어야 한다. 그것은 화면의 설명: BIFS 장면, 텍스쳐(texture)에 관계된 데이터의 반복으로 변환된다.
이러한 멀티미디어 내용(content)이 풍부해지면, 상기의 단순한 반복은 허용할 수 없게 되며, 과도한 다운로딩 시간을 초래하게 된다. 또한, 상기의 MPEG-4에관한 명세는 특정의 멀티미디어 요소 (짧은 음성/영상 클립) 를 방송하는 것을 허용하지 않게 된다.
본 발명은 각각 기본 스트림 유닛으로 구성된, 하나 또는 복수의 데이터 스트림 형태의 데이터 전송에 관한 것으로, 보다 구체적으로는, 기본 스트림 유닛이 하나 또는 복수의 데이터 스트림에 종속되거나, 또는 관련이 있는 경우에, 그러한 기본데이터 스트림 처리의 최적화에 관한 것이다.
도 1은 본 발명에 따른 하나의 데이터 스트림의 다른 데이터 스트림에 대한 종속 관리의 원리를 도시한다.
도 2는 시차된(time staggered) 세션의 형태를 갖는, 스트림의 브로드캐스팅(방송) 및 2개의 단말에 의한 수신의 경우에 있어서, 본 발명의 구현을 나타낸다.
도 3은 스트림 유닛의 디코딩 또는 복호화에 연결된 동기화의 경우를 설명한다(IPMP).
도 4는 2 개의 보호 포인트(디코딩 및 렌더드)를 갖는 도 3의 경우의 대안을 제시한다.
본 발명의 목적은 본 발명의 종래기술의 여러 가지 문제점을 해결하기 위한 것이다.
보다 구체적으로는, 본 발명의 목적은 스트림 유닛이 하나 또는 복수의 다른 스트림 유닛에 종속되거나 관련되는 경우에 효과적으로 스트림 유닛을 관리하도록 하는 기술을 제공하는 것이다.
또한, 본 발명의 목적은, 연결(link)된 스트림의 관리에 대한 기술을 제공하는 것으로, 보다 구체적으로는 계층적 인코딩, 또는 기초 데이터 및 풍부 데이터에 연관된 인코딩에 의해서 인코드된 데이터에 있어서 연결 스트림의 관리를 하기 위한 것이다.
본 발명의 다른 목적은, 멀티브로드캐스트 시나리(scenarii)의 전송을 최적화하고, 더욱 구체적으로는 수신되는 질의 저하 없이 소스 크기를 감소시키는 기술을 제공하는 것이다.
본 발명의 목적은, 달리 표현하면, 양적 측면 또는 질적 측면에서 단말에서 수행되는 처리를 최적화하기 위한 것이다.
이러한 목적들은, 스트림(들)이 스트림 유닛으로 구성되는, 적어도 하나의 데이터 스트림을 적어도 하나의 단말로 전송되는 방법을 사용하는 본 발명에 의해서 달성된다. 본 발명에 의하면, 상기 스트림 유닛의 적어도 일부는, 요구된 이전의 유닛 또는 유닛들이 수신되지 않은 경우에는 상기 스트림 유닛의 처리가 상기 단말에서 수행되지 않도록 하기 위해서, 상기 단말에서 이전에 수신되고, 요구된 이전의 유닛을 호출하는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함한다.
따라서 해상도 성능을 개선하기 위해서, 단말에서 처리를 제한하는 스트림 유닛의 더욱 용이한 관리를 허용하는 논리적 동기화 시스템이 얻어진다.
따라서 본 발명에 의해서 정의되는 데이터 포맷은 스트림의 전송 및 수신을 위해서 뿐만 아니라, 그것들의 방송(broadcast), 레코딩 또는 저장을 위해서 구현될 수 있다.
따라서 본 발명은, 스트림 또는 스트림 유닛의 “후 방향(back)" 동기화의 새로운 문제의 인식, 또한 가장 효과적인 해결수단은 모든 요소가 유효하기 않는 경우에는 스트림 유닛을 처리하지 않는 것이 가장 효과적인 해결수단이라는 관찰에 기반을 두고 있다. 또한, 신호 복구에 있어서는, 복구된 신호의 열화를 초래하는, 또는 심지어는 단말의 차단을 초해하는 신호의 디코딩 대신에 스트림 유닛을 무시하는 것이 바람직하다.
본 발명의 방법은 분리되어 전송되는 적어도 2 개의 데이터 스트림의 전송을 포함하고, 초기 스트림의 하나의 스트림 유닛은 적어도 하나의 제 2 스트림의 적어도 하나의 요구되는 이전 유닛을 나타내고, 여기서, 초기 스트림의 스트림 유닛은 제1 스트림(들)에 포함된 데이터 중에서 풍부 데이터(enrichment data)를 포함한다.
이러한 경우에, 이러한 데이터 스트림은 바람직하게는 하나의 계층적 인코딩의 상이한 계층적 레벨에 해당하고, 여기서 주어진 계층적 레벨의 스트림 유닛의 처리는 관계되는 하층의 계층적 레벨의 스트림 유닛이 수신되는 경우에만 수행된다.
이러한 스트림 유닛은, 요구되는 이전의 유닛의 순서를 정의하는 적어도 하나의 이전의 유닛을 나타낸다.
본 발명의 바람직한 특성에 의하면, 이러한 포인터(pointer)의 적어도 하나는 고려되는 스트림 유닛의 디코딩 및/또는 복호를 가능하게 하는 데이터를 포함하는 적어도 하나의 요구되는 이전의 유닛의 발견을 허용한다.
바람직하게는, 상기의 바람직한 이전 유닛은 단말이 고려되는 스트림 유닛의 데이터가 디코드 및/또는 복호화되어, 디코딩된 후에 표시될 것인지를 결정하도록 한다.
본 발명의 다른 바람직한 실시예에 의하면, 이러한 포인터들의 적어도 하나는 상기 단말로부터 알려진 데이터를 나타내고, 그 단말이 대응하는 스트림 유닛을 처리할 수 있는지 또는 처리할 수 없는지를 판단한다.
바람직하게는, 본 발명의 다른 측면에 의하면, 이러한 스트림 유닛의 적어도 하나는, 가까운 장래에 수신될 수 있는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 지시하는 적어도 하나의 포인터를 포함한다.
바람직하게는, 가까운 미래에 수신될 수 있는 이러한 하나의 스트림 또는 복수의 스트림들은 상기 포인터(들)과 연결(link)을 만들 수 있는 마커를 갖는다.
따라서, 바람직하게는, 구분된 시간에 전송되는 적어도 2 개의 유사한 스트림 유닛의 포인터는 가까운 장래에 수신되는 동일한 스트림 유닛을 가리킨다.
바람직하게는, 본 발명의 방법은 다음을 포함하는 그룹에 해당하는 적어도 2 개의 역할 중에서 포인터의 역할을 나타내는 지시자(indicator)를 구현한다.
- 고려되는 스트림 유닛을 설명하기 위해서 디코드된 적어도 하나의 이전의 스트림 유닛의 지정.
- 고려되는 스트림 유닛, 및/또는 보호 시스템 상태에 관한 참조를 디코드 및/또는 복호하기 위해서 요구되는 데이터를 포함하는 적어도 하나의 이전의 스트림 유닛의 지정
- 적어도 하나의 연속되는 스트림 유닛의 지정
바람직하게는, 이러한 데이터 스트림의 적어도 일부는 이러한 역할을 정의하는 의존 기술자(descriptor)를 포함한다.
바람직하게는, 이러한 데이터 스트림의 적어도 일부는, 요구되는 이전의 유닛 및/또는 상기 스트림에서 상기 스트림의 식별 마커로서 식별을 허용하는 의존 마커를 포함한다.
바람직하게는, 본 발명의 방법은 동기화 레벨에서 구현되어, 수신된 스트림 유닛의 예비 절차가 필요 없게 된다.
본 발명은 상기에서 기술된 전송 절차에 따라서 전송된 하나 또는 복수의 데이터 스트림에 관한 것이다. 기술된 바와 같이, 상기의 데이터 포맷은 데이터의 전송, 방송, 수신, 및 레코딩 (예를 들어, 비디오 레코더 또는 광 디스크 레코더를 사용하여)에 사용될 수 있다.
또는 본 발명은 상기의 여러 가지 측면을 용이하게 결합시킬 수 있다. 예를 들어, 몇 개의 데이터 스트림이 방송되고, 다른 스트림은 CD-ROM에 또는 서버를 통하여 제공될 수 있고, 여기서 제 2 데이터 스트림은 제 1 데이터 스트림을 디코드 (또는 최적화)하기 위해서 알려져야 한다.
본 발명의 데이터 스트림은 서로 독립적으로 전송되는 스트림 유닛으로 구성되고, 상기 스트림 유닛의 적어도 일부는, 요구된 이전의 유닛이 수신되지 않은 경우에는 상기 스트림 유닛의 처리가 상기 단말에서 수행되지 않도록 하기 위해서, 상기 단말에서 이전에 수신되고, 필요한 유닛을 호출하는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함한다.
본 발명은, 서로 독립적으로 전송되는 스트림 유닛으로 구성되는 적어도 하나의 데이터 스트림의 형태로 적어도 하나의 단말에 전송되는 데이터를 위한 서버에 관한 것으로서, 여기서 상기 스트림 유닛의 적어도 일부는, 단말에서 이전에 수신되고, 이전의 필요한 유닛을 호출하는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함한다.
본 발명은 서로 독립적으로 전송되는 스트림 유닛으로 구성되는 적어도 하나의 데이터 스트림을 수신하는 단말에 관한 것으로서, 여기서 상기 스트림 유닛의 적어도 일부는, 단말에서 이전에 수신되고, 이전의 필요한 유닛을 호출하는 상기스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함한다.
본 발명은 서로 독립적으로 전송되는 스트림 유닛으로 구성되는 적어도 하나의 데이터 스트림을 수신하는 방법에 관한 것이다. 여기서 상기 스트림 유닛의 적어도 일부는, 단말에서 이전에 수신되고, 이전의 필요한 유닛을 호출하는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함한다. 상기 수신 방법은 다음의 단계를 포함한다.
- 스트림 유닛의 상기 포인터의 분석.
- 상기 요구되는 이전의 유닛이 수신된 경우에는 상기 스트림 유닛의 처리.
마지막으로, 본 발명은 전송 방법의 사용에 관한 것으로서, 보다 구체적으로는 다음을 포함하는 그룹에 속하는 어플리케이션 중에서 하나를 위한 전송 방법에 관한 것이다.
- 사용자에 의해서 선택된 프로그램에 액세스하기 전에 메시지의 계통적 방송
- 특정 질 레벨 및/또는 특정 프로그램의 선택에의 조건부 접근.
- 대화형 텔레비전
본 발명의 기타의 특징 및 장점은 본 발명의 도면 및 바람직한 실시예에 의해 보다 구체적으로 기술되어 명확하게 된다.
이하에 기술되는 바람직한 실시예는 멀티미디어 시스템, 특히, MPEG-4 타입의 시스템에 있어서 스트림의 전송에 관한 것이다.
종래의 기술의 정리
종래의 기술은 멀티캐스트 또는 방송 시나리(scenarii)의 멀티미디어 화면의 효과적인 전송 (비트 속도 및 기능성에 있어서), 또는 액세스 제어 키 타입 컨텐츠에 링크된 요소의 상호 의존성 스트림의 동기화를 고려하지 않는다.
방송 및 멀티캐스트 시나리(scenarii)에 있어서 멀티미디어 표현
하나의 해결책이 “carousel MPEG-4" 상세에 제안되어 있다. 그러나 어떤 기능은 불가능하고, 높은 비트율 소비(high bit rate consumption) 기능을 갖는다. 고려되는 2 개의 전달 시나리에 있어서, 멀티미디어 표현을 가리키는 입력 포인트는 항상 표시되어야 한다. 그 결과로 장면의 묘사에 관련된 데이터: BIF 장면, 텍스쳐 등이 반복된다.
멀티미디어 컨텐츠가 풍부해지면, 이러한 단순한 반복은 허용될 수 없으며 과도한 다운로딩 시간을 차지하게 된다. 또한, 이러한 상세는 어떤 멀티미디어 요소(짧은 음성/비디오 클립)를 방송하는 것을 허용하지 않는다.
미공개된 특허출원 EP-01400462 에 있어서는, 데이터는 전송 레벨에서 전송된다. 그것과 대비하여 본 발명에 있어서, 모든 데이터는 전송 레벨과 독립되어 있는 소위 동기화 계층 레벨에 위치한다.
상기의 본 발명의 특징에 의해서 여러 가지 타입의 전송을 제거하게 되고, 시간 및 논리적 동기화 데이터뿐만 아니라, 특별한 시점에서 계산을 가능하게는 단일 포인트에 있는 램덤 액세스 마커(random access marker), 상기 유닛을 유지 또는 폐기하는 결정을 통일하는 장점을 제공한다. 그것은, 스트림의 타입 (BIFs 에 대한 영상/음성의 문제)에 의한 판단을 특별하게 하는, 스트림에 대한 더 많은 정보를 알려지게 한다.
멀티미디어 동기화
멀티미디어 동기화에 대한 종전의 기술은 RTP에 기반을 둔 전송 프로토콜 및MPEG-4(동기화 계층)에 의해서 수행된다. 종전의 기술에 따르면, 사용된 동기화 메카니즘은 음성 스트림 및 영상 스트림을 시간 동기화하도록 구성되고, 지연없이 표현될 수 있다. 그러한 데이터들은 시간 스탬프 시스템(기준 클록, 디코딩 및 표현 스탬프)을 사용하는 것에 의해서 전송된다.
다양한 레벨의 시간 및 공간 풍부(time and spatial enrichment)가 사용되어 재현 프레임을 생성하는 계층적 인코딩의 등장에 의해서, 새로운 동기화의 필요가 제기된다. 스트림을 디코딩하기 전에 (또한, 스트림을 표현하는 시점에서도) 스트림을 동기화하는 것이 필요하다. 이러한 제한은, 정확한 프레임 생성을 위한 유닛을 디코딩하기 위해 필요한 유닛을 식별하기 위해서 필요하기 때문에, 표현 동기화보다 더 복잡하다. 단일 지연은 전체 스트림 뿐만 아니라, 후자에 기반을 둔 모든 스트림을 사용될 수 없도록 한다. 보여진 바와 같이, 디코드될 유닛 사이의 논리적 의존성의 문제이다.
감소된 시간 간격은 영상 MPEG-4에서 이미 설명되었지만, 시스템 계층에서는 접근 가능하지 않다.
데이터 보호
동기화의 3번째 케이스인 멀티미디어 스트림에 링크된 데이터 보호 스트림의 동기화의 케이스는 종래 기술에서는 고려되지 않았다.
이 케이스에 있어서는, 모든 멀티미디어 스트림 유닛은 디코드되기 전에 정확한 키를 사용하여 복호화되어야 하는 것이 확인되어야 한다. (그렇지 않으면 그결과는 치명적이다.) 스트림이 동기화된다는 보장이 없으면, 동기화의 수단이 그것을 보장할 수 없다.
디코더의 입력 및 그 출력의 시점은 동기화의 포인트이다. (디코드된 프레임은, 번갈아 인코드된다.)
본 발명의 원리
본 발명의 목적은 다음의 것을 가능하게 하는 것이다.
- 멀티미디어 화면을 멀티캐스팅하고 방송하는 것
- 멀티미디어 디코딩의 논리적 동기화
상기의 2 개의 목적은 다음의 신호전송 메카니즘을 사용하여 구해진다.
- 스트림을 구성하는 각각의 시간 유닛은 구성 가능한 방법으로 식별될 수 있도록 스트림을 구성하도록 하는 메카니즘
- 방송 시나리(scenarii)를 위한 전방 연결 메카니즘(front chaining mechanism)
따라서, 본 발명의 필수 기술 구성 요소는 다음과 같다.
- 복수의 스트림의 구성요소들 사이의, 또는 동일한 스트림(영상, 음성, 및 데이터 보호 시스템) 내의 논리적 동기화 요소
- 해결수단은, 스트림의 각각의 구성요소의 타입에 대해서, 스트림이 의존하는 요소를 가리키고, 또한 스트림이 의지하는 특정 요소를 지시한다. 몇 가지 구현이 가능하다.
본 발명의 구현을 위해서 다음의 것들이 사용된다.
- 의존성 기술자(Dependency Descriptor)
- 의존성 마커(Dependency Marker) (선택사항)
- 의존성 포인터(Dependency Pointer)
- 마커 (스트림 유닛을 식별함)(선택사항)
본 발명의 바람직한 실시예의 상세한 설명
MPEG4 상세(MPEG4 Specification)
붙임 1은 MPEG-4 상세의 형태의, MPEG 타입 데이터에 대한 발명의 구현의 예를 제시하고 있다.
수신기 동작
단말은, 각각의 기술자(ObjectDescriptor,)를 사용하여, 적어도 하나의 그래픽 화면 객체(graphical scene object) (BIFS stream : F_BIFS)를 참조하는 IOD (InitialObjectDescriptor)를 수신하고, 또한 선택적으로는, 적어도 하나의 그래픽 객체 기술자 객체 (OD stream: F_OD.)를 참조한다. 단말은 하기에서 표현된 정보에 기반하는 스트림을 개방한다.
각각의 객체 기술자(object descriptors)는 ESDescriptor로 구성된 기본 스트림(elementary stream: ES) 기술자를 포함한다. 각각의 ESDescriptor는 dependsOnESID 필드 및 SLConfigDescriptor를 포함한다.
dependsOnESID 필드는 ESID에 의해서 인식된 스트림 사이의 의존성의 그래프를 구성하게 한다.
SLConfigDescriptor 객체는 동기화 도구를 구성하도록 한다.
SLConfigDescriptor 객체에 있어서는, 다음의 방법으로 다양한 의존성을 검증하기 위해서 수신기를 구성할 가능성이 존재한다.
DependencyMaker // 패킷을 식별하기 위해서 스트림을 구성한다.
{
int(5) maker Length;
}
DependencyDescriptor // 의존성 링크를 기술하도록 한다.
{
int (2) mode; //0: verson mode by DTS
//1: verson mode by ID
//2: scalable mode
//3: IPMP mode
//mode==1이면, 의존성은 스트림의 마커에서 수행됨
//mode==3 이면, 의존성은 불투명한 방식(opaque manner)로 수행됨 (IPMP 시스템은 다음을 이해해야 함
// 의존성과, 디코딩/복호화의 확인 여부
//가능하면, 마커를 사용하여. 따라서, 이것은
// 보호 시스템이
// 복호화 유닛인지의 여부를 판단하도록 하는 코드이다.
//mode==0 또는, mode==2 이면, 의존성은 DTS에 의해서 계산되고,
//결과적으로, 대응되는 SLConfig에서 depLength=dtsLength.
int(5) depLength;
if(mode==1 ∥mode==0)
{
int(depLength)value;//검색하여야 할 제 1 유닛의 크기
}
}
따라서, 스트림은 다른 스트림(스스로 정상적인 미디어 또는 IPMP.)의 종속으로 선언될 수 있다. 이 경우에 있어서, 다음의 4 개의 구별된 모드를 사용하여어떻게 그 의존성을 지시하는지, SL 구성에 기술한다.
DTS 및 ID 버전 모드 (모드 0 및 1):
이 스트림은 각각의 AccessUnits(AU)에 대해서, 스트림에서 전방 의존성을 나타낸다. 즉, AU(n)은 어떤 AccessUnit가 다음에 디코드될 것인가를 나타낸다. 이러한 신호는 모드 0의 다음의 액세스 유닛의 DTS, 또는 모드 1의 다음의 액세스 유닛의 ID를 설명한다.
이 경우에, 회복될 제 1 요소의 값이 더해진다.
예를 들어, 이것은 방송/멀티캐스트 모드에서 BIFS 스트림이 될 수 있다.
가변 모드(Scalable Mode)(모드 2):
이 스트림은, 각각의 액세스 유닛에 대하여, 스트림 유닛이 종속하는 스트림에 대한 의존성을 나타낸다. 이 스트림은 고유하다고 가정한다.
이러한 원리는 도 1에 의해서 설명된다. 종속 스트림 (10)의 스트림 유닛(11)은 정상적으로는 해더(SLHeader)(111) 및 데이터 필드(SLPayload)(112)를 포함한다. 해더(111)는, 구체적으로는, 스트림 유닛(11)을 처리하기 위해서 알려져야 하는, 베이스 스트림(14)의 스트림 유닛(141)(142) 각각으로 종속 링크(12)(13)를 정의하는, 2 개의 포인터 Dep1 및 Dep2를 포함한다.
IPMP 모드 (모드 3):
이 스트림은, 각각의 AccessUnits에 대하여, 데이터 보호 시스템이 유닛을 디코드하는 식별자를 나타낸다. 이 마커는 유닛을 복호화할 수 있는지 여부를 응답한다.
SLConfigDescriptor는 하나 또는 복수의 DependencyDescriptor 및 하나 또는 복수의 DependencyMarker를 포함하고, 그것은 스트림에 있어서 여러 가지 의존성 케이스를 조정하도록 한다. ( a priori, 단일의 DependencyMarker가 충분하지만, 복수개 존재한다.)
따라서, 만약 SLConfig 가 DependencyMarker를 포함한다면, 그것은 각각의 패킷(모드 1 및 3)에 대해서 버전 ID를 지시한다.
AccessUnit에 대응되는 SL 패킷의 헤더에는, 다음을 포함한다.
- SLConfigDescriptor의 각각의 dependencyMarker에 대하여, 길이 마커 (markerLength.)
- 각각의 DependencyDescriptor에 대하여, depLength 길이의 dependencyPointer
일단 이러한 다양한 마킹이 수행되면, 시스템은
a) 모드 0 및 1 인 경우에는 “방송(broadcast)"으로 동작
b) 가변 의존성(scalability dependencies)의 관리
c) IPMP 의존성의 관리
및 a), b), 및 c)의 조합
IPMP 모드에 있어서, 동작 설명
객체의 ObjectDescriptor가 수신되면, 단말은 관련된 스트림 각각의 SLConfigDescriptor를 체크한다. 이것에 의해서 스트림 각각에 대해서 SL 패킷의 헤더를 디코딩, 특히, 마커를 디코딩한다.
IPMP 케이스에 있어서, 도 3에 설명된 바와 같이, DTSs 및/또는 dependencyPointers가 있다.
각각의 스트림 AU는, 그것이 디코드되기 전에, 적어도 스트림 식별자 데이터 : ESID, DTS, dependencyPointer (IPM)(31)를 제공하는 것에 의해서, IPMP 시스템(32)에 의해서 처리된다. 그 이후에, IPMP 시스템은 디코딩에 대한 정보(311)(Code Dec)를 설명하는 것에 의해서 AU를 처리(복호화)할 수 있는지 응답한다. 처리할 수 없으면, 유닛의 DTS는 만료되고, AU는 파기된다(34). 따라서 불일치한 AUs를 디코드하는 것을 시도하지 않는다.
한편, 도 4의 실시예에 있어서, 도 3 의 구성요소가 있고, 다른 한편으로는 디코딩(41)의 이후에, 이미지 복구에 링크된 프로세스가 있다. 필드(312)(CodeComp,)를 사용하여, 영상에 문신(tattoo) 또는 메시지를 추가하는 것과 같은 합성(composition)에 관한 데이터가 전송될 수 있다. 데이터 보호 시스템(32)이 이러한 합성을 어떻게 관리하여야 하는지 모르는 경우에는 (영상(42)을 어떻게 표시하는지를 모르는 경우), 예를 들어, 디코더가 요구되는 문신을 갖지 않기 때문에, 영상은 표시되지 않는다(43).
또한, 프레임이, 예를 들어, 로고와 함께 표시되어, 디코더가 정확한 키를 갖는 경우에는 로고가 사라지는 것도 예상할 수 있다.
멀티캐스트/브로드캐스트 모드에서의 동작 기술(Operating Description in Multicast/Broadcast Mode)
이러한 동작은 도 2에 도시되며, 다음과 같은 것을 제시한다:
- 전송된 스트림(21).
- 제1 수신기(세션 1)(22)에 의하여 수신된 스트림.
- 제1 수신기(세션 2)(23)에 의하여 수신된 스트림.
세션 1은 패킷 211에서 시작하고, 상기 스트림 유닛(213)을 고려하며, 링크 25에 따라서, 여기에 상기 스트림 유닛(211), 그리고 상기 스트림 유닛(215)를 지시한다.
세션 2는 조금 이후에 개방되고, 스트림 유닛(212)와 함께 시작하며, 이것은 스트림 유닛(214)를 지시한다.
본 발명에 따르면, 두 개(또는 두 개 이상)의 스트림 유닛들이 동일한 차기 스트림 유닛을 지시할 수 있다. 이것은 통합 메카니즘(27)이다: 스트림 유닛들(213, 214)은 모두 스트림 유닛(215)를 지시한다. 따라서, 비록 이들이 다른 시간에서 시작했을지라도, 상기 두 개의 세션들은, "복구" 단계 이후에, 상기 동일한 스트림 유닛(215)를 사용한다. 이것은 분명히 향상된 성능을 가능하게 한다.
이러한 동작은 상세하게 설명된다.
상기 ObjectDescriptor가 수신될 때, 상기 단말은 각각의 연관된 스트림들에 대한 SLConfigDescriptor를 검사한다. 이것은 각각의 스트림에 대한 SL 패킷 해더를 디코딩(특히, 상기 마커들의 디코딩)할 수 있게 한다.
따라서, 멀티캐스트/브로드캐스트의 경우에 있어서, 상기 DTS에 대하여 모드 0 또는 1에 있어서 적어도 하나의 dependencyPointer, 및 마커("ID에 의한" 모드 1)가 존재할 것이다. 따라서 상기 단말은 각각의 스트림에 대하여 어느 것이 가장 먼저 복구된 유닛인지 알게 된다. 따라서, 이것은 각각의 스트림에 대응하는 첫째 유닛을 복구하기 위하여 시도할 것이다.
만약 첫째 유닛을 수신하는 경우에는, 그 컨텐츠의 디스플레이를 개시할 수 있다. 각각의 유닛은 상기 dependencyPointer 내에서, 수신될 차기 유닛, 및 상기 DTS/마커를 설명하고, 독특한 방식으로 각각의 유닛을 식별한다.
만약 상기 단말이 첫째 유닛을 수신하지 않는 경우에는(시간 종료를 사용하거나 또는 원하는 마커에 대응하는 상기 스트림에 대하여 RAP=1 타입을 수신할 때에 알 수 있다), 연결을 끊고(상기 세션의 전면적인 종료) 재연결을 시도한다.
이러한 메카니즘은 상기 세션들의 통합을 고려한다는 것에 유의한다.
또한 상기 모드 "ID에 의한"는 차기 유닛의 DTS가 미리 알려지지 않을 시에 필요하다는 것에 유의한다.
이러한 메카니즘은 특히 MPEG-4내에서 BIFS, OD, 텍스쳐, 오디오 클립, 및 비디오 클립에서 사용된다. 이것은 더 이상 스트림화된 오디오/비디오에 대하여 사용되지 않을 것이다.
가변 모드에서의 동작 기술
상기 ObjectDescriptor이 수신될 때, 상기 단말은 각각의 연관된 스트림들에 대하여 SLConfigDescriptor를 검사한다. 이것은 각각의 스트림에 대하여 상기 SL 패킷 해더를 디코딩할 수 있게 한다. 가변 비디오에 대하여, 하나의 스트림은 베이스로서 사용될 것이며, 하나 또는 여러 다른 스트림들은 이러한 스트림에 의존할 것이다. 상기 베이스 스트림에 의존하는 각각의 스트림은 DependencyDescriptor를 선언할 것이다.
상기 향상 스트림의 각각의 AU에 있어서, 의존하는 베이스 스트림의 AU DTS의 dependencyPointer를 이용하여 참조할 것이다.
대부분의 경우에 있어서, 상기 베이스 비디오의 두 개 참조를 지적하기 위하여 상기 향상 스트림 내에 두 개의 dependencyPointer가 존재할 것이다.
브로드캐스트+IPMP 모드 내에서의 동작 기술
이 경우에는, 예를 들어, BIFS는 상기 SL 형상 내에 두 개의 dependencyDescriptor를 포함할 것이다. 하나는 브로드캐스트 모드를 위한 것이고, 하나는 IPMP를 위한 것이다. 이것은 만약 상기 브로드캐스트 모드가 ID에 의한 것이라면 하나의 마커를 포함할 것이다.
어플리케이션 예:
프로그램 시작 전에 광고의 브로드캐스팅
인터넷 스트리밍에서 여러 경우에 있어서, 컨텐트 제공자는 상기 컨텐트 자체를 전송하기 이전에 조직적으로 광고를 전송한다. 인터넷 시나리가 유니캐스트(client-server)이므로, 이것은 단계들로 수행된다: 상기 광고를 다운로딩하는 단계, 및 상기 광고의 끝은 비디오 스트리밍의 시작으로 안내한다.
멀티캐스트 또는 브로드캐스트 시나리에는, 클라이언트-서버 동작에 아무런 자원이 없고, 요청에 대한 아무런 개념이 없다. 이와 같이, 사용자는 일반적으로 오직 프리젠테이션의 현재 상태에 대한 접속만 갖게 된다.
전방 참조 메카니즘으로 인하여, 멀티캐스트 또는 브로드캐스트에서 이러한 시나리가 가능하게 된다.
실제, 상기 광고는 주기적인 방식으로 전송될 수 있으며, 상기 현재 프로그램은 상기 광고의 끝에서 통합될 수있다.
이것은, 예를 들어, 모든 사용자들이 시작단계에서 광고를 볼수 있도록 보장할 수 있다(이와 같은 시간 동안에, 상기 컨텐트는 효율적이고 점증적인 방식을 다운로드될 수 있다).
각각의 브로드캐스트 필름에 대하여, 동일한 타입의 어플리케이션들은 상기 필름의 카테고리에 대한 통지가 될 수 있다(부모 동반 요구 영화, 16세 미만 금지, 등등).
가변 조건부 접속
여기에서의 아이디어는 사용자의 권한에 따라 다르게 보여질 수 있는 동일한 비디오 및 오디오 스트림(독특한)을 전송하는 것이다. 상기 비디오 프레임 종속성에 대한 신호는, 보호 키에 따라서, 오직 상기 사용자가 상기 키를 갖고서 이용할 것들을 디코딩할 수 있게 한다. 모든 이미지들은 모든 키들을 갖는 것들에 대하여 디코딩될 수 있다 - 보다 적은 권한을 갖는 것들에 대해서는 일부 이미지들이 디코딩될 수 있다. 이것은 더욱 가변적인 방식(여기에서는 시간 가변성)으로 조건부 접속을 생성할 수 있게 한다.
가장 복잡하고 유용한 시나리는 여러 스트림들이 있고 시간 가변성 및 해상도가 조절될 수 있는 것이다.
이러한 프레임 종속성을 이용함으로써, 거의 모든 연속적인 방식으로 미디어에 대한 접속을 조절할 수 있게 된다.
따라서, 일부 사용자들이 5채널 이상의 소리(공간적 소리)를 수신할 수 있게 하는 키들을 갖고, 다른 사람들이 오직 스트레오 사운드만 수신할 수 있도록 하는 키들을 갖는 것이 예상될 수 있다. 이것은 또한 더욱 세부적인 이용료 청구를 가능하게 한다.
MPED-4 쌍방향 텔레비젼
"셋톱 박스(set-top box)" 어플레케이션이 정적인 경우를 고려하는 대신에, 어떠한 타입의 어플리케이션예들이라도 다양한 채널들을 얻을 수 있게 되는 MPEG-4 어플리케이션예들이 고려될 수 있다(인라인 메카니즘). 이러한 MPEG-4 어플리케이션은 능동 24h×24h가 될 것이고, 전체적으로 그래픽 인터페이스를 재구성할 수 있게 할 것이다.
화면 브로드캐스팅 기술은 상기 어플리케이션부분(MPEG-J)뿐만 아니라 그래픽 인터페이스(BIFS/텍스쳐/OD)를 효율적으로 다운로드할 수 있도록 할 것이다.
이는 더 빠른 배치를 가능하게 한다.
여기에서 개시된 본 발명은 본 발명의 사상 및 일반적인 특징으로부터 벗어나지 않고서 다른 특정 형태에서 구체화될 수 있고, 그 중 일부는 제시되었으며, 여기에서 설명한 실시예들은 예시적인 것이며 본 발명의 범위를 제한하는 것이 아니라는 것이 고려되어야 할 것이다. 본 발명의 범위는 첨부된 청구항들에 의하여 제시되고 있으며, 위의 상세한 설명보다도, 상기 청구항들의 의미와 그 균등 범위 내에 포함되는 모든 변형들을 포함하는 것이다.
첨부
본 발명에 따른 MPEG-4 타입 상세의 실시예
정의
스트림 유닛(AU: 액세스 유닛)
기본 스트림내에서 개별적으로 액세스 가능한 데이터 유닛. 스트림 유닛(또는 액세스 유닛)은 시간 데이터 요소가 부여될 수 있는 가장 작은 엔티티(entity)이다.
시청각 객체(Audiovisual Object)
청각적 및/또는 시각적 방식으로 명백하게 되는 자연적 또는 합성된(가상의) 객체의 표현. 상기 표현은 BIFS 시퀀스 기술(description) 내에서의 하나의 노드 또는 노드들의 그룹에 대응한다. 각각의 시청각 객체는 하나 또는 여러 객체 기술자들을 사용하는 영, 하나, 또는 여러 기본 스트림들과 연관된다.
시청각 시퀀스(AV Scene)
상기 화면을 묘사하고 그들의 공간적 또는 시간적 속성들을 정의하는 것으로서 데이터 요소들을 갖는 일련의 시청각 객체들이며, 상기 객체와 사용자 쌍방향 작용들의 결과로 초래된 동작을 포함한다.
화면에 대한 이진 포맷(Binary Format for Scene, 'BIFS')
파라메트릭한 화면 기술 포맷의 코딩된 표현.
단말(Terminal)
ISO/IEC 14496-1에 의하여 정의된 것과 같은 쌍방향 시청각 화면의 코딩된 표현을 송신 또는 수신하고 표현하는 시스템. 이것은 독립적인 시스템이거나 ISO/EIC 14496에 따르는 어플리케이션 시스템의 일부가 될 수 있다.
축약형 및 심볼
AU 액세스 유닛, 또는 스트림 유닛
AV 시청각
BIFS 화면에 대한 이진 포맷
CM 합성 메모리
CTS 합성 시간 스탬프
CU 복합 유닛
DAI DMIF 어플리케이션 인터페이스(ISO/IEC 14496-6 참조)
DB 디코딩 버퍼
DTS 디코딩 시간 스탬프
ES 기본 스트림
ESI 기본 스트림 인터페이스
ESID 기본 스트림 식별자
FAP 얼굴 애니메이션 식별자
FAPU FAP 유닛
NDT 노드 데이터 타입
OCI 객체 컨텐트 정보
OCR 객체 클록 참조
OD 객체 기술자
ODID 객체 기술자 식별자
OTB 객체 시간 베이스
PLL 위상 잠금 루프
QoS 서비스의 질
SDM 시스템 디코더 모델
SL 동기화 계층
SL-Packet 동기화 계층 패킷
SPS SL-패킷화된 스트림
STB 시스템 시간 베이스
TTs 음성에 대한 텍스트
URL 전역적 자원 경계 설정자
VOP 비디오 객체 평면
VRML 가상 현실 모델링 언어
SL 패킷 해더 형상
신택스
클래스 SLConfigDescriptor는 BaseDescriptor를 연장한다: 비트(8)
시맨틱
상기 SL 패킷 해더는 각각의 개별 기본 스트림의 요구에 따라 형상 설정될 수 있다. 선택 가능한 파라메터들은 클록 참조뿐만 아니라 존재, 해상도 및 시간 스탬프의 정확도를 포함한다. 이러한 유연성은, 예를 들어, 상기 SL 패킷 해더 컨텐츠가 조금 증가할 수 있게 한다.
각각의 기본 스트림에 대하여, 상기 형상은 객체 기술자와 연관된 ES_Descriptor의 일부에 해당하는 SLConfigDescriptor 안으로 전송된다.
상기 SL패킷 해더 내에서 형상 설정될 수 있는 파라메터들은 두 가지 타입으로 나누어질 수 있다: 각각의 SL 패킷에 적용되는 것들과(예를 들어, OCR, sequenceNumber)와 상기 액세스 유닛들 안에서 오직 디스플레이되는 것들(예를 들어: 시간 스탬프, assessUnitLength, instantBitrate, degradationPrority, 등)
상기 미리 지정된 칼럼은 아래에서 상세하게 설명되는 것과 같은, 한 세트의 미리 지정된 파라메터들의 디폴트 값들을 고정시킬 수 있게 한다. 이 테이블은 장래의 프로파일에 대하여 요구되는 것과 같은 미리 정의된 설정들을 포함하기 위하여 ISO/IEC 14496 수정안을 이용하여 갱신될 수 있다.
테이블1 - SLConfigDescriptor 미리 정의된 값들의 세트에 대한 모습
미리 정의된 값의 필드 기술
0x00 고객들(custom)
0x01 널(Null) SL 패킷 해더
0x02 MP4 필드에서 사용을 위한 보류
0x03 - 0xFF ISO 사용을 위한 보류
테이블2 - SLConfigDescriptor 미리 정의된 값들의 세부사항
useAccessUnitStartFlag - accessUnitStartFlag가 상기 기본 스트림의 각각의 SL 패킷 해더 내에 존재함을 나타낸다.
useAccessUnitEndFlag - 상기 accessUnitEndFlag가 상기 기본 스트림의 각각의 SL 패킷 해더 내에 존자함을 나타낸다.
만약 accessUnitStartFlag 또는 accessUnitEndFlag가 활성화되지 않는 경우에는, 각각의 SL 패킷이 완전 액세스 유닛에 대응한다는 것을 의미한다.
hasRandomAccessUnitsOnlyFlag - 각각의 SL 패킷이 임의 액세스 지점에 대응함을 나타낸다. 이러한 경우에, 상기 randomAccessPointFlag는 사용될 필요가 없다.
usePaddingFlag - 상기 paddingFlag가 상기 기본 스트림의 각각의 SL 패킷해더 내에 존재함을 나타낸다.
useTimeStartFlag - 상기 시간 스탬프가 상기 기본 스트림을 동기화하는데 사용됨을 나타낸다. 이들은 상기 SL 패킷 해더 내로 전송된다. 그렇지 않은 경우에는, 상기 SL 패킷 해더 내로 전송된 accessUnitRate, compositionUnitRate, startDecodingTimestamp, 및 startCompositionTimeStamp 파라메터들은 동기화를 위하여 사용되어야 한다.
시작 및 지속 시간 스탬프들의 사용(useTimeStampFlag=0)은 오류가 없는 환경을 포함하여 오직 일정한 조건 하에서만 가능하다.
useIdleFlag - 상기 기본 스트림 내에서 상기 idleFlag가 사용됨을 나타낸다.
durationFlag - 상기 기본 스트림에 대한 상기 액세스 유닛 합성 유닛의 불변 지속이 계속적으로 표시됨을 나타낸다.
timeStampResolution - by-second 펄스 내에서 객체의 시간 기반 해상도.
OCRResolution - by-second 싸이클 내에서 객체의 시간 기반 해상도.
timeStampLength - 상기 SL 패킷 해더 내의 시간 스탬프 필드의 길이. timeStampLength는 0에서부터 64비트까지의 값을 갖아야만 한다.
OCRlength - SL 패킷 해더 내에서의 objectClockReference 필드의 길이. 여러 개의 0들은 상기 기본 스트림 안에 아무런 objectClockReference가 존재하지 않음을 나타낸다. 만약 상기 OCRstreamFlag가 놓여진다면, OCRLength는 0이 되어야 한다. 그렇지 않은 경우에는, OCRlength는 0에서부터 64비트까지의 값을 갖아야만한다.
AU_Length - 상기 기본 스트림에 대한 SL 패킷 해더 내의 accessUnitLength 필드의 길이. AU_Length는 0과 32 비트 사이의 값을 갖아야 한다.
instantBitrateLength - 상기 기본 스트림에 대한 SL 패킷 해더 내의 instantBitrate의 길이.
degradationPriorityLength - 상기 기본 스트림에 대한 SL 패킷 해더 내의 degradationPriority 필드의 길이.
AU_SeqNumLength - 상기 기본 스트림에 대한 SL 패킷 해더 내의 AU_SequenceNumber 필드의 길이.
packetSeqNumLength - 상기 기본 스트림에 대한 SL 패킷 해더 내의 packetSequenceNumber 필드의 길이.
timeScale - 상기 액세스 유닛과 합성 유닛의 지속기간을 나타내기 위하여 사용됨. 일 초는 또한 timeScale 섹션들로 나누어진다.
accessUnitDuration - 하나의 합성 유닛의 지속기간은 compositionUnitDuration*1/timeScale 초이다.
compositionUnitDuration - 하나의 합성 유닛의 지속기간은 compositionUnitDuration*1/timeScale 초이다.
startDecodingTimeStamp - 상기 기본 스트림의 첫째 액세스 유닛이 디코딩되어야 하는 시간을 전달한다.
extension_field_control - 이 필드는 상기 SL을 연장할 수 있게 한다. 01b0값은 상기 기술자들이 상기 SLConfigDescriptor의 끝에 위치하여야 함을 나타낸다.
markerDescriptors - 이 테이블은 상기 스트림 내에서 다음 액세스 유닛을 식별하기 위한 마커에 대한 기술을 나타낸다.
dependencyDescriptors - 이 테이블은 이전 액세스 유닛 또는 다음 유닛이 어떻게 참조되어야만 하는지를 규정하는 종속성 기술자를 나타낸다.
MarkerDecriptor
신택스는 다음과 같다:
클래스 MarkerDescriptor는 BaseDescriptor를 연장한다: 비트(8)
tag=DependencyMarkerTag {
int(5) encodedMarkerLength;
MarkerLength=encodeMarkerLength + 1;
}
DependencyDescriptor
신택스
추상 클래스 DependencyDescriptor는 BaseDescriptor를 연장한다(
);
클래스 SimpleDependencyDescriptor는 BaseDescriptor을 연장한다:
비트(8)
클래스 CompleteDependencyDescriptor는 BaseDescriptor를 연장한다
: 비트(8)
시맨틱
모드
4 개의 정의된 모드들이 있다:
- 모드 0: DTS를 이용한 전방 참조
- 모드 1: 마커를 이용한 전방 참조
- 모드 2: 후방 범위성 참조
- 모드 3: IPMP 모드
모드 0과 1은 각각의 액세스 유닛이 다음 액세스 유닛을 참조하도록 한다.
모드 2는 이러한 액세스 유닛을 디코딩하기 위하여 필요한 이전 액세스 유닛을 참조하도록 한다.(주의: 여러 경우에 있어서, 2개 이상의 dependencydescriptor들이 2개 또는 그 이상의 액세스 유닛들을 참조하기 위하여 필요하다)
모드 3은 상기 기초 유닛에 대한 디코딩 또는 합성이 가능한지 여부를 결정하기 위하여, 각각의 액세스 유닛이 상기 IPMP 시스템에 의하여 사용될 수 있는 불투명한 식별자를 포함하도록 할 수 있다.
모드 1과 3은 상기 스트림안에서 MarkerDescriptor가 필요하다.
ESID
이러한 선택적 필드는 상기 DependencyDescriptor가 참조하는 스트림을 식별한다.
SimpleDependencyDescriptor에 대하여, ESID는 다음과 같은 방식으로 계산된다:
- 모드 0과 1: 현재 스트림
- 모드 2: dependsOnESID에 의존함
- 모드 3: 적용 불가능
dependencyLength - 상기 마커(만약 존재한다면) 또는 상기 decodingTimeStamp의 길이.
값 - 상기 첫째 마커 또는 디코딩될 다음 액세스 유닛에 대한 식별자의 값.
SL 패킷 해더 상세
신택스
시맨틱
accessUnitStartFlag - 1이 되는 때에, 상기 SL 패킷에 대한 로드의 첫째 바이트가 유닛 액세스의 시작임을 나타낸다. 만약 이러한 식택스 요소가 상기 SL 패킷 해더의 형상으로부터 생략되는 경우에는, 그 디폴트 값은 다음의 규칙에 따라서 이전 SL 패킷으로부터 알려진다:
accessUnitStartFlag = (the SL packet before accessUnitEndFlag=1)?1:0.
accessUnitEndFlag - 1이 되는 때에, 이것은 상기 SL 패킷에 대한 로드의 마지막 바이트가 상기 현재 액세스 유닛의 마지막 바이트임을 나타낸다. 만약 이러한 신택스 요소가 상기 SL 패킷 해더의 형상으로부터 생략되는 경우에는, 그 디폴트 값은 다음의 규칙에 따라서, 오직 상기 SL 패킷의 수신 이후에 알려진다:
accessUnitEndFlag = (the SL packet after accessUnitStartFlag==1)?1:0.
만약 AccessUnitStartFlag 또는 AccessUnitEndFlag가 상기 SL 패킷 해더 내에 배치되지 않는 경우에는, 이것은 각각의 SL 패킷이 단일 액세스 유닛에 대응하고, 여기서 각각의 accessUnitStartFlag=accessUnitEndFlag=1임을 의미한다.
상기 SL 패킷 해더가 accessUnitStartFlag를 사용하나, accessUnitEndFlag 또는 accessUnitLength를 사용하지 않도록 배치된 때에는, 상기 단말이 다음 유닛이 수신되기 이전에 하나의 액세스 유닛의 끝을 판단 가능할 것인지 보장할 수 없다.
OCRflag - 1이 될 때, objectClockReference가 뒤따를 것임을 나타낸다. OCRflag에 대한 디폴트 값은 0이다.
idleFlag - 상기 기본 스트림이 결정되지 않은 양의 시간에 대하여 불활성화 (즉, 원하는 데이터가 없는)될 것임을 나타낸다. 이러한 표시는 고의적인 부재와 잇따르는 SL 패킷에서의 오류에 기인한 부재를 구별할 수 있도록 디코더에 의하여 사용될 수 있다.
paddigFlag - 상기 SL 패킷 내에서 사용될 데이터 완성 모드를 나타낸다. paddingFlag에 대한 디폴트 값은 0이다.
paddingBits - 상기 SL 패킷 내에서 사용될 데이터 완성 모드를 나타낸다. paddingBits에 대한 디폴트 값은 0이다.
만약 paddingFlag가 놓여지고 paddingBits가 0이 되면, 이것은 상기 SL 패킷에 뒤따르는 로드가 오직 완성 바이트들로 구성됨을 나타낸다. 만약 paddingFla가놓여지고 paddingBits가 0인 경우에는 accessUnitStartFlag, randomAccessPointFlag 및 OCRflag는 놓여져서는 안된다.
만약 paddingFlag가 놓여지고 paddingBits가 0보다 큰 경우에는, 이것은 상기 SL 패킷의 로드에, 상기 로드의 바이트들을 배열하기 위한 0 비트들로 형성된, paddingBits가 뒤따른다는 것을 나타낸다.
packetSequenceNumber - 만약 존재하는 경우에, 이는 모듈 카운터로서 각각의 SL 패킷에 대하여 연속적으로 증가하여야 한다. 상기 디코더안에서의 불연속은 하나 또는 여러개의 잃어버린 SL 패킷들에 대응한다. 이와 같은 경우에, 동기화 계층에 대하여 표시되어야 한다. 만약 이러한 신택스 요소가 상기 SL 패킷 해더의 형상으로부터 생략되는 경우에는, 상기 초기 스트림에 대하여 상기 동기화 계층에 의한 상기 스트림 유닛의 연속성에 대한 제어를 할 수 없다.
SL Packet Duplication: 자신의 SL 패킷 해더안의 sequenceNumber 필드를 갖는 기본 스트림들은 오류 복구를 위하여 SL 패킷의 복제를 이용하여야 한다. 이러한 복제된 패킷(들)은 즉시 원래의 것을 따라야 한다. 복제된 SL 패킷의 packedSequenceNumber는 동일한 값을 갖아야만 하고 원래 SL 패킷에 대한 각각의 바이트가 복제되어야 하고, 만약 존재한다면, objectClockReference 필드는 예외이며, 이것은 상기 복제된 SL 패킷에 대한 유효값을 인코딩해야만 한다.
degPrioFlag - 0이 될 때, 이것은 상기 패킷 안에 degradationPriority가 존재함을 나타낸다.
degradationPriority - 상기 SL 패킷의 로드에 대한 중요성을 나타낸다. 상기 streamPriority는 하나의 ES에 대한 기초 우선순위를 정의한다. degradationPriority는 상기 기초 우선순위에 따라서 상기 SL 패킷에 대한 우선순위 감소를 정의한다. 이러한 SL 패킷에 대한 우선순위는 다음과 같이 주어진다:
SL_PacketPriority = streamPriority - degradationPriority
degradationPriority는 차기 발생이 있을 때까지 이러한 값을 유지한다. 이러한 표시는 특정 분배 계층의 인스턴스에 대한 어댑터 뿐만 아니라 상기 기본 스트림 디코더에 의하여 사용될 수 있다. 다양한 기본 스트림의 SL 패킷들 중에서 감소율은 상기 SL_PacketPriority가 감소됨에 따라서 증가한다.
objectClockReference - 객체 시간 스탬프를 포함한다. 상기 OTR t 시간값은 다음의 공식에 따라서 상기 OCR 시간 스탬프로부터 재구성된다:
t =
(objectClockReference/SL.OCRResolution) + K*(2SL OCRLength/SL.OCRResolution)
여기서 k는 상기 objectClockReference 카운터가 커버되는 시간이다.
objectClockReference는, 만약 OCRflag가 놓여진다면, 오직 상기 SL 패킷 해더 내에 존재한다.
오직 하나의 OCR 값이 상기 SL 패킷의 내부를 로딩하지 않고서도 전달될 수 있다.
다음에서는 이진 스트림에서 accessUnitStartFlag에 의하여 자세하게 표시될때 오직 액세스 유닛의 시작위치에 존재하는 신택스 요소들의 시맨택이 설명된다:
randomAccessPointFlag - 0이 될 때, 이것은 상기 기본 스트림의 컨텐츠에 대한 임의 접속이 가능함을 나타낸다. randomAccessPointFlag는 약 accessUnitStartFlag가 놓여지는 경우에 오직 놓여져야만 한다. 만약 이러한 신택스 요소가 상기 SL 패킷 해더의 형상으로부터 생략된다면, 그 디폴트 값은 이러한 기본 스트림에 대하여 SLConfigDescriptor.hasRandomAccessUnitOnlyFlag값이다.
AU_sequenceNumber - 만약 존재하는 경우에는, 이것은 각각의 액세스 유닛에 대하여 모듈 카운터로서 연속적으로 증가되어야만 한다. 상기 디코에서에의 불연속은 하나 또는 여러 개의 잃어버린 액세스 유닛에 대응한다. 이와 같은 경우에, 상기 오류는 상기 동기화 계층의 사용자에게 표시되어야만 한다. 만약 이러한 신택스 요소들이 상기 SL 패킷 해더의 형상으로부터 생략된다면, 이러한 기본 스트림에 대하여 상기 동기화 계층에 의한 상기 스트림 유닛의 연속성에 대한 제어는 실행될 수 없다.
액세스 유닛들의 복제: 상기 AU 보다 바로 전에 동일한 수의 시퀀스를 이용하여 전송된 액세스 유닛들은 무시되어야 한다. 이러한 복제 액세스 유닛은, 그 원본이 RAP가 놓여지도록 하지 않지만 상기 복제 유닛은 RAP가 놓여지도록 하며, 상기 전송된 스트림에 임의 접속 포인트들을 부가하도록 한다. 이것은 클라이언트들이 정의된 포인트들에서, 다른 클라이언트들이 이미 상기 스트림을 수신한 반면에, 그 전송되는 동안에 상기 스트림안으로 진입하도록 한다.
decodingTimeStampFlag - 하나의 디코딩 시간 스탬프가 상기 패킷 내에 존재함을 나타낸다.
compositionTimeStampFlag - 시간 스탬프 합성이 상기 패킷 내에 존재함을 나타낸다.
accessUnitLengthFlag - 상기 액세스 유닛의 길이가 상기 패킷 내에 존재함을 나타낸다.
instantBitrateFlag - instantBitrateFlag가 상기 패킷 내에 존재함을 나타낸다.
decodingTimeStamp - 관련된 SLConfigDescriptor 내에 배치되는 것과 같은 디코딩 시간 스탬프. 이러한 액세스 유닛의 디코딩 시간 td는 다음의 공식에 따라서 상기 시간 디코딩 스탬프로부터 재구성된다:
td = (decodingTimeStamp/
SL.timeStampResolution + K*2SL.timeStampLength/
SL.timeStampResolution
여기서 k는 상기 decodingTimeStamp가 커버되는 시간이다.
decodingTimeStamp는 만약 상기 디코더 시간이 이러한 액세스 유닛에 대한 시간 합성과 다른 경우에 오직 존재하여야 한다.
compositionTimeStamp - 연관된 SLConfigDescriptor 내에 배치된 것과 같은 시간 스탬프 합성. 첫째 합성 유닛의 시간 합성 tc는 상기 액세스 유닛이 다음의 공식에 따라서 상기 시간 스탬프 합성으로부터 재구성된다는 사실로부터 생기게 된다:
td = (compositionTimeStamp/
SL.timeStampResolution + K*2SL.timeStampLength/
SL.timeStampResolution
여기서 k는 상기 compositionTimeStamp 카운터가 커버하는 시간이다.
accessUnitLength - 바이트 단위의 액세스 유닛의 길이. 만약 이러한 신택스 요소가 존재하지 않거나 0의 값을 갖는 경우에는, 상기 액세스 유닛의 길이는 알려지지 않는다.
instantBitrate - 차기 instantBitrate 필드가 발결될 때까지의 상기 기본 스트림의 매 초당 비트 수 단위의 순간 비트율.
markerValue - 상기 액세스 유닛을 식별할 수 있도록 하는 마커의 값. 만약 markerDescriptor가 존재한다면 상기 마커가 정의된다.
DependecyPointerValue - 상기 DependencyDescriptor에 의하여 정의된 DTS 또는 마커 인덱스.
MarkerDescriptorCount: 마커 기술자들의 수.
DependencyDescriptorCount: 종속적인 기술자들의 수.
디코딩 시맨틱
전방 참조 메카니즘 (모드 0과 1)
ES에 연관된 SLConfigDescriptor는 상기 스트림 안으로 진입할 수 있게 하는 첫째 액세스 유닛을 나타낸다.
만약 상기 참조 모드가 DTS인 경우에는, 상기 SLConfigDescriptor은 decodingTimeStamp를 포함하여야 한다.
그렇지 않은 경우에는, 각각의 액세스 유닛을 표시하기 위하여 마커가 사용된다. 0 또는 -1은 특별한 중요성을 갖는다:
//0은 더 이상 액세스 유닛이 뒤따르지 않음을 의미한다.
//-1은 어떠한 액세스 유닛이라도 사용될 수 있음을 의미한다.
각각의 액세스 유닛은 마커와 각각의 액세스 유닛이 차기 액세스 유닛을 지시할 수 있게 하는 dependencypointer를 포함하여야 한다.
후방 참조 메카니즘 (모드 2)
상기 SLConfigDescriptor는 ESID가 참조하는 ES 내에서 액세스 유닛들을 표시할 n 개의 DepndencyDescriptor 타입 기술자들을 정의할 것이다.
현재 스트림에 있는 각각의 액세스 유닛은, 그 DTS를 통하여 ES_베이스 액세스 유닛들(ESID에 의하여 식별된)에 대한 참조로서 DependencyPointers를 사용하여 , ES_베이스라고 불리우는, 그 식별자가 ESID인 ES에 대하여 액세스 유닛을 지시할 것이다.
IPMP 모드 (모드 3)
상기 DependencyPointers는 디코딩 이전에 상기 IPMP 시스템에 전송된다. 이러한 불투명한 포인터들은 상기 IPMP 자원들이 상기 액세스 유닛을 디코딩하는 것이 가능한지 아닌지 여부를 결정할 수 있게 한다. 만약 키들이 수신되지 않거나 또는 그 권한들이 이를 허용하지 않는 경우에는 부정적으로 응답할 수 있다. 이러한 종속성 포인터는 디코딩 이후에 합성 유닛에 링크된다.
이것은 합성 이전에 상기 IPMP 시스템에 반환되고, 상기 IPMP 자원은 상기 유닛이 존재하는지 아닌지 여부를 결정할 것이다.
클록 참조 스트림
streamType = ClockReferenceStream 기본 스트림은 오브젝터 기술자를 이용하여 선언되어야 한다. 이는 객체 클록 참조 시간 스탬프를 전달하는데 사용된다. 복수의 기본 스트림은 네임 세트(name set)에서 클록 참조 정보가 반복되어 전송되는 것을 방지하기 위하여 SLConfigDescriptor 내의 OCR_ES_ID 신택스 요소를 사용하여 ClockReferenceStream과 같은 것을 참조할 수 있다. 그럼에도 불구하고, OCR_ES_ID를 이용하여 기본 스트림들 사이에 원형 참조가 허용되지 않는다는 것에 유의해야 한다.
동기화 계층에서, SL 레벨에서 패키지된 스트림에 대한 SL 패킷 해더의 신택스를 배치함으로써 ClockReferenceStream이 수행되고, 이로 인하여 오직 상기 OCRResolution의 요구된 OCR 값들과 OCRLength가 상기 SL 패킷 해더 내에 존재한다.
패키지된 스트림-streamType의 SL = ClockReferenceStream 내에는 SL 패킷 부하가 존재하지 않는다.
클록 참조 스트림에 대한 DecoderConfigDescriptor에 있어서, ObjectTypeIndication은 '0xFF', 1에 대한 hasRandomAccessUnitsOnlyFlag 및 '0'에 대한 bufferSizeDB 상에 놓여져야 한다.
아래에는 클록 참조 스트림의 SLConfigDescriptor에 대한 추천값들이 표시되어 있다.
테이블 3 - ClockReferenceStream의 SLConfigDescriptor 파라메터들의 SLConfigDescriptor 값들
동일한 시간 베이스 객체를 공유하는 기본 스트림에 대한 제한
OCR_ES_ID를 통하여 여러 기본 스트림들 사이에 하나의 시간 베이스 객체가 공유될 시, 이러한 기본 스트림들과 그 프로세싱에 대한 많은 제한들이 다음과 같이 존재한다:
여러 기본 스트림들이 하나의 단순한 시간 베이스 객체를 공유할 시, 통합된 클록 참조 정보를 갖지 않는 기본 스트림들은, 만약 접속가능한 경우일지라도, 상기 객체 클록 참조 정보를 전달하는 기초 스크림이 접속가능하게 될 때까지, 상기 단말에 의하여 사용되어서는 안된다.
만약 객체 클록 참조 정보를 전달하는 기본 스트림 이후에 통합된 클록 참조를 갖지 않는 기본 스트림이 상기 단말에 대하여 사용가능하게 된 경우에는, 이것은 다른 스트림(들)과 동기화되어 전달되어야 한다. 이는 상기 시간 베이스 객체의 현재 값에 의존하여, 위와 같은 스트림이 시작 시점에서부터 전달되지 않아야 한다는 것을 암시한다.
객체 클록 참조 정보를 전달하는 기본 스트림이 사용불가능하게 되거나 다른 곳(예를 들어, 대기 모드에서)에서 사용될 시에는, 동일한 시간 베이스 객체를 사용하는 다른 모든 기본 스트림들은 이러한 접근 방식을 따라야 한다; 즉, 이들은 사용불가능하게 되거나 또는 동일한 방향으로 조작되어야 한다.
통합된 객체 클록 참조 정보를 갖지 않는 기본 스트림이 사용불가능하게 될 시에는, 이것은 상기 동일한 시간 베이스 객체를 공유하는 다른 기본 스트림에 영향을 미치지 않는다.
클록 참조 및 시간 스탬프 값에 대한 형상 선택권의 사용
시간 베이스 객체의 복구에 있어서 모호성의 해결
상기 objectClockReference 값들의 제한된 길이에 의존하여, 이러한 시간 스탬프들은 모호할 수 있다. 상기 OTB 시간 값은 다음의 공식에 따라서 objectClockReference가 상기 SL 패킷 해더로 전송되는 매 시간마다 재구성될 수 있다:
tOTB_reconstructed= (objectClockReference /
SL.OCRResolution) + k*(2SL.OCRLength/
SL.OCRResolution)
여기서 k는 루프의 수를 나타내난 전체 값이다. 상기 결과 시간 베이스 tOTB_reconstructed는 초 단위로 측정된다.
기본 스트림에 대한 첫째 objectClockReference가 인식될 시, 상기 k값은 1로 설정되어야 한다. 각각의 뒤따라 발생하는 objectClockReference에 대하여, 상기 k값은 다음과 같이 추정된다:
상기 단말은 각각의 인스턴스에서 시간 베이스 객체의 값을 추정하기 위한 자원을 이해할 수 있어야 한다.
objectClockReference가 수신되는 매 시간 마다, OTB tOTB_estimated의 추정된 현재 값은 견본 추출되어야 한다. 따라서, tOTB_res(k)는 k에 대한 다른 값들에 대하여 평가된다. 지속기간 _tOTB_estimated- tOTB_rec(k)_를 최소화하는 k값은 tOTB_reconstructed에 대한 참값으로서 고려되어야 한다. 이러한 값은 상기 시간 베이스 객체 추정 메카니즘에 대한 새로운 기여로서 사용되어야 한다.
이러한 어플리케이션은 상기 절차가 objectClockReference 요소에 대한 적절한 길이 및 해상도와 기본 스트림내에서 objectClockReference 삽입 값에 대한 충분히 높은 주파수를 선택함으로써 k에 대한 모호하지 않은 값을 생성한다는 것을 보장해야 한다. 이러한 값에 대한 선택은 상기 단말과 수신기 사이의 클록들 사이의 최대 예상 지연뿐만 아니라, 상기 SL 패킷들에 대한 전송 지터(delivery jitter)에 의존한다.
시간 스탬프의 복구에 있어서의 모호성의 해결
상기 decodingTimeStamp와 compositionTimeStamp값들의 제한된 길이에 의존하여, 이러한 시간 스탬프들은 다음의 공식에 의하여 나타나는 바와 같이 모호하게 될 수 있다:
Tts(m)=(TimeStamp/SL.timeStampResolution)+m*
(2SL.timeStampLength/SL.timeStampResolution)
여기서 TimeStamp는 decodingTimeStamp이거나 compositionTimeStamp이며, m은 루프수를 나타내는 전체값이다.
상기 시간 스탬프의 옳바른 ttimestamp값은 다음과 같이 추정될 수 있다:
TimeStamp가 수신되는 매 시간마다, OTB의 현재 추정된 값 tOTB_estimated이 견본 추출되어야 한다. tts(m)이 m에 대한 다양한 값들에 대하여 평가된다. 구간 _tOTB_estimated- tts(m)_을 최소화하는 m값은 ttimestamp에 대한 참값으로서 고려된다.
이러한 어플리케이션은, 시간 이벤트의 모호하지 않은 위치에 관한 요구들을 충족하기 위하여, 각각의 개별 기본 스트림에 대하여 독립적으로, 상기 시간 스탬프의 길이 및 해상도를 선택할 수 있다. 이러한 선택은, 상기 시간 위치에 대하여 요구되는 정확성뿐만 아니라, 상기 TimeStamp에 의하여 표시되는 순간 이후에, TimeStamp를 갖는 SL 패킷이 전송될 수 있는 최대 시간에 의존한다.
객체 클록 참조 및 시간 스탬프의 사용에 관한 의견
객체 베이스 시간의 시간 라인은 상기 /SL.OCRResolution에 의하여 분리된 두 개의 인스턴스들을 구분할 수 있게 한다. OCRResolution은 기본 스트림 세트의 동기화를 위한 어플리케이션에서 요구되는 정확성을 얻을 수 있도록 충분히 큰 크기로서 선택되어야 한다.
상기 시간 및 합성 스탬프는 상기 /SL.timeStampResolution 에 의하여 분리된 두 개의 개별 인스턴스들을 구별할 수 있게 한다. timeStampResolution은 주어진 기본 스트림에 대한 액세스 유닛을 획득하기 위한 관점에서 상기 어플리케이션에 의하여 요구되는 정확성을 획득할 수 있도록 충분하게 큰 크기로서 선택되어야한다.
상기 OCRResolution 보다 큰 TimeStampResolution은 이벤트들 사이에서 최상의 구분을 획득할 수 있도록 하지 않을 것이다. 만약 TimeStampResolution이 OCRResolution 보다 작은 경우에는, 이러한 특정 스트림에 대한 이벤트들은 이와 같이 주어진 OCRResolution에서 가능한 최적의 정확성을 갖도록 획득될 수 없다.
상기 OCRLength 파라메타는 상기 SL 해더의 형상 내에 표시된다. 2SL.OCRLength/SL.OCRResolution은 그 루푸 이전에 상기 objectClockReference 카운터에 의하여 커버되는 시간 간격이다. 모든 기본 스트림에 대하여 시간 이벤트들의 모호하지 않은 위치에 대한 어플리케이션 요구를 충족하기 위하여 충분히 큰 OCRLength가 선택되어야 하다.
상기 어플리케이션에서 위에서 정의된 k값을 알 때에는, 상기 OTB 시간 라인은 각각의 시간값에 대하여 분명하다. 상기 어플리케이션이 k 인자를 재구성할 수 없을 때에는, 예를 들어, 부가적인 정보없이 임의 접속을 가능하게 하는 어플리케이션예에 있어서, 상기 OTB 시간 라인은 모드 2SL.OCRLength/SL.OCRResolution에 대하여 모호하게 만들어진다. 따라서, 이러한 OTB를 참조하는 각각의 시간 스탬프는 모호하다. 그럼에도 불구하고, 이는 예상되는 최대 지터(jitter)와 액세스 유닛이 디코딩되기 이전에 전송되는 동안에 제한들에 대한 지식을 이용하여 어플리케이션 환경 내에서 분명하게 고려될 수 있다.
2SL.OCRLength/SL.OCRResolution 보다 큰 시간 간격2SL.timeStampLength/SL.timeStampResolution을 선택하는 기본 스트림들이, 모호한 방식으로, 상기 두 개의 시간 간격들의 가장 작은 두개의 이벤트들을 오직 획득할 수 있다.
몇몇 경우에 있어서, k와 m이 정확하게 추정될 수 없을 때, 버퍼 모델이 제한 범위를 넘을 수 있으며, 이것은 디코더에 의하여 예상하지 못한 동작과 결과를 발생하게 한다.
예를 들어, 1ms의 정확성으로 기본 스트림을 동기화하기 원하는 어플리케이션예를 고려하는 경우에, OCRResolution은 1000과 같거나 크도록 선택되어야 한다(따라서 두 개의 연속적인 OCT 펄스 사이의 시간은 1ms와 같다). OCRResolution=2000이라고 가정될 수 있다.
상기 어플리케이션은 상기 STB와 상기 0.1%의 OTB(즉, 초당 1ms) 사이의 지터를 가정한다. 따라서 상기 클록들은 최소한 매 초마다 조절되어야 한다(즉, 최악의 시나리, 상기 클록들은 1ms 벗어나며, 이는 정확성의 제약이 된다). 상기 objectlockReference는 1초마다 전송된다는 것을 가정할 수 있다.
상기 어플리케이션은 상기 인자 k를 재구성할 필요 없이 24h의 분명한 OTB 시간 라인을 갖는 것을 원할 수 있다. 따라서 상기 OCRLength는 결과적으로, 2SL.OCRLength/SL.OCRResolution=24h로서 선택된다.
이제 상기 어플리케이션에서, 10ms의 정확성을 갖는 경우를 제외하고, 기본 스트림 내부의 이벤트들을 동기화하기 원한다고 가정한다. TimeStampResolution는100과 같거나 더 크도록 선택되어야 한다(따라서 TimeStamp의 두 개의 연속적인 펄스 사이의 시간은 10ms와 같다). TimeStampResolution=200이라고 가정한다.
상기 어플리케이션은 액세스 유닛들을 그 디코더 또는 합성 시간 이전에 최대 1분에서 전송할 수 있는 용량을 원한다. 따라서 상기 timeStampLength는 2SL timeStampLength/SL.timeStampResolution=2분으로 선택된다.

Claims (22)

  1. 적어도 하나의 데이터 스트림 - 여기서, 상기 스트림 또는 복수의 스트림은 스트림 유닛으로 구성되어 있음 - 을 적어도 하나의 단말로 전송하기 위한 방법에 있어서,
    상기 스트림 유닛의 적어도 일부는, 요구된 이전의 유닛 또는 유닛들이 수신되지 않은 경우에는 상기 스트림 유닛의 처리가 상기 단말에서 수행되지 않도록 하기 위해서, 상기 단말에서 이전에 수신되고, 요구된 이전의 유닛을 호출하는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  2. 제 1 항에 있어서, 상기 데이터 스트림 전송방법은 독립적으로 전송되는 적어도 두 개의 데이터 스트림의 전송을 포함하고, 제 1 스트림의 하나의 스트림 유닛은 적어도 하나의 제 2 스트림의 적어도 하나의 요구되는 이전의 유닛을 나타내고, 여기서 상기 제 1 스트림의 스트림 유닛은 상기 제 2 스트림에 포함된 데이터의 풍부(enrichment) 데이터를 포함하고 있음을 특징으로 하는 데이터 스트림 전송방법.
  3. 제 2 항에 있어서, 상기 데이터 스트림은 계층적 인코딩의 상이한 계층적 레벨에 해당하고, 주어진 계층적 레벨의 스트림 유닛의 처리는, 대응되는 하부의 계층적 레벨의 스트림 유닛이 수신된 경우에만 수행되는 것을 특징으로 하는 데이터 스트림 전송방법.
  4. 제 2 항 또는 제 3 항에 있어서, 상기 스트림은 요구된 이전 유닛의 순서를 정의하는 적어도 하나의 이전 유닛을 가리키는 것을 특징으로 하는 데이터 스트림 전송방법.
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서, 상기 포인터의 적어도 하나는 고려되는 스트림 유닛의 디코딩 및/또는 복호화를 하도록 하는 데이터를 포함하는 적어도 하나의 요구되는 이전 유닛을 회복하도록 하는 것을 특징으로 하는 데이터 스트림 전송방법.
  6. 제 5 항에 있어서, 상기 요구되는 이전 유닛 또는 유닛들은, 고려되는 스트림 유닛의 데이터가 디코딩 및/또는 복호화되고, 디코딩된 후에 표시되어야 하는지 여부를 단말이 판단하도록 하는 데이터를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  7. 제 1 항 내지 제 6 항 중 어느 한 항에 있어서, 상기 포인터 중에서 적어도 하나는 상기 단말에 의해서 알려질 수 있는 데이터를 가리켜서, 상기 단말이 자신의 능력으로 대응되는 데이터 스트림 유닛을 처리할 수 있는지 여부를 판단할 수 있도록 하는 것을 특징으로 하는 데이터 스트림 전송방법.
  8. 제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
    상기 스트림 유닛의 적어도 하나는 다음에 수신될 수 있는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  9. 제 8 항에 있어서,
    상기 다음에 수신될 수 있는 상기 유닛 또는 유닛들은 상기 포인터(들)과 연결되도록 하는 마커를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  10. 제 8 항 또는 제 9 항에 있어서, 별개의 시점에서 전송되는 적어도 2 개의 유사한 스트림 유닛은 다음에 수신될 수 있는 동일한 스트림 유닛을 가리키는 것을 특징으로 하는 데이터 스트림 전송방법.
  11. 제 1 항 내지 제 10 항 중 어느 한 항에 있어서,
    상기 전송방법은,
    - 디코딩되어 고려되는 스트림 유닛을 설명하도록 하는 적어도 하나의 이전의 스트림 유닛의 지정.
    고려되는 스트림 유닛을 디코딩 및/또는 복호화하기 위해서 필요한 데이터를 포함하는 적어도 하나의 이전 스트림 유닛 및/또는 상기 보호 시스템의 상태에의 참조의 지정
    - 적어도 하나의 다음의 스트림 유닛의 지정
    을 포함하는 그룹에 속하는 2 개의 역할 중으로부터 포인터(들)의 역할을 지정하는 지시기를 구현하는 것을 특징으로 하는 데이터 스트림 전송방법.
  12. 제 11 항에 있어서, 상기 스트림 유닛의 적어도 일부는, 상기 역할을 정의하는 의존성 기술자를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  13. 제 1 항 내지 제 12 항 중에서 어느 한 항에 있어서,
    상기 스트림 유닛의 적어도 일부는 요구되는 이전 유닛으로 인식하도록 하는 의존성 마커를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  14. 제 1 항 내지 제 13 항 중에서 어느 한 항에 있어서,
    상기 스트림 유닛의 적어도 일부는 상기 스트림에 있어서 상기 스트림의 인식 마커를 포함하는 것을 특징으로 하는 데이터 스트림 전송방법.
  15. 제 1 항 내지 제 14 항 중에서 어느 한 항에 있어서,
    상기 방법은, 수신된 스트림 유닛의 이전 처리가 필요하지 않도록 되기 위해서 동기화 레벨에서 구현되는 것을 특징으로 하는 데이터 스트림 전송방법.
  16. 제 1 항 내지 제 15 항 중에서 어느 한 항의 전송 방법에 따라서 전송되는 데이터의 스트림.
  17. 적어도 하나의 단말로부터 전송 및/또는 수신되고, 서로 독립되어 전송되는 스트림로 구성되는 데이터의 스트림에 있어서,
    상기 스트림 유닛의 적어도 일부는, 요구된 이전의 유닛 또는 유닛들이 수신되지 않은 경우에는 상기 스트림 유닛의 처리가 상기 단말에서 수행되지 않도록 하기 위해서, 상기 단말에서 이전에 수신되고, 요구된 이전의 유닛을 호출하는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함하는 것을 특징으로 하는 데이터 스트림.
  18. 적어도 하나의 단말에 서로 독립적으로 전송되는 스트림 유닛에 구성된 적어도 하나의 데이터 스트림의 형태로 전송되도록 구성되는 데이터를 위한 서버에 있어서,
    상기 스트림 유닛의 적어도 일부는 단말에서 이전에 수신되고, 요구된 이전의 유닛을 호출할 수 있는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함하는 것을 특징으로 하는 서버.
  19. 서로 독립적으로 전송되는 스트림 유닛에 구성되는 적어도 하나의 데이터 스트림에 수신되는 단말에 있어서,
    상기 스트림 유닛의 적어도 일부는 단말에서 이전에 수신되어, 요구된 이전의 유닛을 호출할 수 있는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함하는 것을 특징으로 하는 단말.
  20. 서로 독립적으로 전송되는 스트림 유닛에 구성되는 적어도 하나의 데이터 스트림의 수신 방법에 있어서,
    상기 스트림 유닛의 적어도 일부는 단말에서 이전에 수신되어, 요구되는 이전의 유닛을 호출할 수 있는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키는 적어도 하나의 포인터를 포함하는 것을 특징으로 하는 수신방법.
  21. 제 20 항에 있어서, 상기 포인터 중에서 적어도 하나는 단말에 이전에 수신되어, 요구되는 이전의 유닛을 호출할 수 있는 상기 스트림 또는 다른 스트림의 적어도 하나의 스트림 유닛을 가리키고, 상기 방법은,
    - 스트림 유닛의 상기 포인터를 분석하고,
    - 요구되는 이전 유닛 또는 유닛들이 수신되면 상기 스트림 유닛을 처리하는 단계들을 포함하는 것을 특징으로 하는 수신방법.
  22. - 사용자에 의해서 선택된 프로그램에 액세스하기 전에 메시지의 시스템적인 방송
    - 특정 수준의 레벨 및/또는 프로그램의 특정 선택에의 조건부 액세스
    - 대화형 텔레비전
    을 포함하는 그룹에 속하는 어플리케이션 중에서 하나를 위한 청구항 제 1 항 내지 제 15 항 중에서 하나에 따른 전송 방법의 사용.
KR1020047014101A 2002-03-08 2003-03-07 종속 데이터 플로우 전송을 위한 방법 KR100984662B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR02/02992 2002-03-08
FR0202992A FR2827447B1 (fr) 2001-07-13 2002-03-08 Procede de transmission de flux de donnees, flux de donnees, serveur, terminal, procede de reception et utilisation correspondants
PCT/FR2003/000754 WO2003077561A1 (fr) 2002-03-08 2003-03-07 Procédé de transmission de flux de données dependants

Publications (2)

Publication Number Publication Date
KR20040105761A true KR20040105761A (ko) 2004-12-16
KR100984662B1 KR100984662B1 (ko) 2010-10-01

Family

ID=27799041

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020047014101A KR100984662B1 (ko) 2002-03-08 2003-03-07 종속 데이터 플로우 전송을 위한 방법

Country Status (12)

Country Link
US (1) US8095957B2 (ko)
EP (1) EP1483915B1 (ko)
JP (2) JP2005527138A (ko)
KR (1) KR100984662B1 (ko)
CN (1) CN100471267C (ko)
AT (1) ATE487327T1 (ko)
AU (1) AU2003233368A1 (ko)
DE (1) DE60334780D1 (ko)
ES (1) ES2354872T3 (ko)
MX (1) MXPA04008659A (ko)
WO (1) WO2003077561A1 (ko)
ZA (1) ZA200407000B (ko)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2265609C (en) * 1997-07-18 2005-05-17 Sony Corporation Method and system for multiplexing image signal, method and system for demultiplexing image signal, and transmission medium
EP1499131A1 (en) * 2003-07-14 2005-01-19 Deutsche Thomson-Brandt Gmbh Method and apparatus for decoding a data stream in audio video streaming systems
US7392319B2 (en) * 2004-04-23 2008-06-24 International Business Machines Corporation Method and apparatus for failure resilient forwarding of data over a computer network
EP2019554A3 (en) * 2005-03-10 2009-03-11 Qualcomm Incorporated A decoder architecture for optimized error management in streaming multimedia
FR2889902A1 (fr) * 2005-08-19 2007-02-23 France Telecom Procedes de transmission, d'encodage et de reception de donnees multimedia protegees par des cles de cryptage, signal, support de donnees, dispositif de restition et programmes correspondants
US8269763B2 (en) * 2006-11-03 2012-09-18 Apple Inc. Continuous random access points
CN100544447C (zh) * 2007-07-11 2009-09-23 中兴通讯股份有限公司 一种移动多媒体广播业务数据流的传输方法
KR101204134B1 (ko) 2008-04-25 2012-11-23 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 트랜스포트 데이터 스트림내에서 참조하는 유연성 있는 서브스트림
CN101901187B (zh) * 2010-07-09 2012-09-19 北京红旗胜利科技发展有限责任公司 一种解码程序测试的方法和系统
KR101803970B1 (ko) * 2011-03-16 2017-12-28 삼성전자주식회사 컨텐트를 구성하는 장치 및 방법
US9424049B2 (en) 2012-03-02 2016-08-23 Apple Inc. Data protection for opaque data structures
JP6605789B2 (ja) * 2013-06-18 2019-11-13 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 送信方法、受信方法、送信装置、および、受信装置
WO2016031629A1 (ja) * 2014-08-27 2016-03-03 シャープ株式会社 再生装置、送信装置、再生方法、及び、送信方法
CN107148090A (zh) * 2017-06-30 2017-09-08 罗颖莉 一种在多个终端之间共享流量的方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1439704A3 (en) * 1997-03-17 2011-08-10 Panasonic Corporation Method and apparatus for processing, transmitting and receiving dynamic image data
JP3309069B2 (ja) * 1997-11-17 2002-07-29 株式会社日立製作所 多重符号化画像音声データの受信装置
US6205140B1 (en) * 1997-12-01 2001-03-20 Intel Corporation Communication of dynamic dependencies along media streams
KR100705992B1 (ko) 1998-07-17 2007-04-12 코닌클리케 필립스 일렉트로닉스 엔.브이. 코드화된 데이터를 디멀티플렉싱하는 장치
US7009967B1 (en) * 1999-08-07 2006-03-07 Shrikumar Hariharasubrahmanian Systems and methods for transmitting data packets
US7000245B1 (en) * 1999-10-29 2006-02-14 Opentv, Inc. System and method for recording pushed data
JP2001189713A (ja) 1999-12-28 2001-07-10 Toshiba Corp データ伝送装置およびデータ伝送方法
GB9930788D0 (en) * 1999-12-30 2000-02-16 Koninkl Philips Electronics Nv Method and apparatus for converting data streams
US20010027468A1 (en) 2000-03-09 2001-10-04 Sanyo Electric Co., Ltd. Transmission system, reception system, and transmission and reception system capable of displaying a scene with high quality
US7024685B1 (en) * 2000-09-13 2006-04-04 International Business Machines Corporation Transport demultiplexor with bit maskable filter
JP2002141945A (ja) * 2000-11-06 2002-05-17 Sony Corp データ送信装置、およびデータ送信方法、並びにプログラム記憶媒体
ATE322784T1 (de) * 2001-01-19 2006-04-15 Verfahren und vorrichtung zur zuweisung der dateneinheiten von zellen zu aufeinanderfolgenden speicherspositionen von datenrahmen durch anwendung einer schätzung der zeigersposition

Also Published As

Publication number Publication date
EP1483915B1 (fr) 2010-11-03
MXPA04008659A (es) 2004-12-13
DE60334780D1 (de) 2010-12-16
ZA200407000B (en) 2005-08-31
ATE487327T1 (de) 2010-11-15
JP5253439B2 (ja) 2013-07-31
US8095957B2 (en) 2012-01-10
ES2354872T3 (es) 2011-03-18
KR100984662B1 (ko) 2010-10-01
JP2010187381A (ja) 2010-08-26
JP2005527138A (ja) 2005-09-08
CN1647536A (zh) 2005-07-27
CN100471267C (zh) 2009-03-18
AU2003233368A1 (en) 2003-09-22
WO2003077561A1 (fr) 2003-09-18
US20060136440A1 (en) 2006-06-22
EP1483915A1 (fr) 2004-12-08

Similar Documents

Publication Publication Date Title
JP5253439B2 (ja) 従属データストリームの送信方法
JP6122982B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
US20010000962A1 (en) Terminal for composing and presenting MPEG-4 video programs
Avaro et al. MPEG-4 systems: overview
US7149770B1 (en) Method and system for client-server interaction in interactive communications using server routes
KR100580437B1 (ko) 상호 작용식 통신에서 클라이언트-서버 상호 작용에 관한방법 및 시스템
EP2341680B1 (en) Method and apparatus for adaptation of a multimedia content
JP4391231B2 (ja) 複数のターミナルへのマルチメディア信号のブロードキャスト方法
Eleftheriadis MPEG-4 systems: architecting object-based audio-visual content
Kalva et al. MPEG-4 systems and applications
Le Feuvre et al. Synchronization in MPEG-4 Systems
Kim et al. Development of interactive contents streaming system based on MPEG-4
Eleftheriadis MPEG-4 systems systems
Lugmayr et al. Synchronization of MPEG-7 metadata with a broadband MPEG-2 digiTV stream by utilizing a digital broadcast item approach
Kalva Object-Based Audio-Visual Services
Wang et al. Implementation of live video transmission in MPEG-4 3D scene
Libsie et al. Adaptation of Multimedia Resources Supported by Metadata.

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
J201 Request for trial against refusal decision
B701 Decision to grant
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130909

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20140917

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20180903

Year of fee payment: 9