KR20080033387A - 기초 스트림 콘텐트 보호 - Google Patents

기초 스트림 콘텐트 보호 Download PDF

Info

Publication number
KR20080033387A
KR20080033387A KR1020087003328A KR20087003328A KR20080033387A KR 20080033387 A KR20080033387 A KR 20080033387A KR 1020087003328 A KR1020087003328 A KR 1020087003328A KR 20087003328 A KR20087003328 A KR 20087003328A KR 20080033387 A KR20080033387 A KR 20080033387A
Authority
KR
South Korea
Prior art keywords
mau
field
bit
transport
content
Prior art date
Application number
KR1020087003328A
Other languages
English (en)
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
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20080033387A publication Critical patent/KR20080033387A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04K—SECRET COMMUNICATION; JAMMING OF COMMUNICATION
    • H04K1/00—Secret communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • 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/234327—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 layers, e.g. base layer and one or more enhancement layers
    • 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/2347—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • 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/2347—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • H04N21/23476—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption by partially encrypting, e.g. encrypting the ending portion of a movie
    • 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/4405—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 video stream decryption
    • H04N21/44055—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 video stream decryption by partially decrypting, e.g. decrypting a video stream that has been partially encrypted
    • 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/835—Generation of protective data, e.g. certificates
    • 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/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/603—Digital right managament [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

기초 스트림 미디어 콘텐트를 보호하는 것에 대하여 설명된다. 일 태양에서, 기초 스트림 미디어 콘텐트 내의 데이터 세그먼트들이 식별된다. 각각의 데이터 세그먼트는 단일의 비디오 또는 오디오 프레임을 포함한다. 페이로드 패킷들을 보호하기 위한 암호화 경계들이 선택되어 데이터 세그먼트 경계들에 대응한다. 기초 스트림 미디어 콘텐트는 그 후 선택된 암호화 경계들을 이용하여 보호된다.
기초 스트림, 미디어 콘텐트, 데이터 세그먼트, 비디오 프레임, 오디오 프레임, 페이로드 패킷, 암호화 경계

Description

기초 스트림 콘텐트 보호{PROTECTING ELEMENTARY STREAM CONTENT}
미디어 센터는, 후속하는 재암호화(re-encryption), 및 네트워크 접속을 통한 미디어 가입자(소비자, 고객, 등)로의 전달을 위하여, 미디어 콘텐트를 전달하는 피보호 전송 스트림으로부터 암호화를 제거하여 TS(transport stream)를 ES들(elementary streams)로 디멀티플렉스하는 것이 보통이다. 미디어 센터에 의한 그러한 암호 해독 및 재암호화 동작들은 보안(security)이 손상될 수 있는데, 그 이유는 암호 해독된 콘텐트는 도용 및 다른 보안 침해들에 취약하기 때문이다. "미디어 콘텐트(media content)"는 비디오, 오디오 콘텐트, 사진, 애니메이션, 텍스트, 등 중 하나 이상을 포함할 수 있는 "콘텐트" 및 "미디어 신호들"과 동의어이다.
STB들(set-top boxes), DMR들(digital media receivers), 및 PC들과 같은 미디어 가입자들은 미디어 센터, 또는 콘텐트 소스로부터 피보호 미디어 콘텐트를 수신하는 것이 보통이다. 피보호 미디어 콘텐트는 네트워크 접속을 통하여 송신되거나, 저장 매체로부터 다운로드된 암호화된 오디오/비디오 데이터를 포함한다. 암호화된 미디어 콘텐트를 처리하기 위하여(예를 들면, 인덱싱을 위하여), 미디어 가입자는 미디어 콘텐트 보호를 제거할 필요가 있는 것이 보통이다(즉, 미디어 콘텐트 암호 해독). 그러한 암호 해독 동작들은 실질적인 장치 리소스들을 소비하고 장치 성능을 감소시키며, 결과적으로는 장치의 응답성 및 기능성을 손상시킬 수 있는 것이 보통이다.
발명의 개요
본 개요는 이하 상세한 설명부에서 보다 상세히 설명되는 간략화된 형태의 개념들의 선택을 도입하기 위하여 제공된다. 본 개요는 청구된 주제의 주요한 특징들 또는 본질적인 특징들을 식별하기 위한 것이 아니며, 청구된 주제의 범위를 결정하는 데 도움이 되기 위하여 이용되는 것도 아니다.
상기의 관점에서, ES(elementary stream) 미디어 콘텐트를 보호하는 것이 설명된다. 일 양태에서, ES 미디어 콘텐트 내의 데이터 세그먼트들이 식별된다. 각각의 데이터 세그먼트는 단일의 비디오 또는 오디오 프레임을 포함한다. 페이로드 패킷들(payload packets)을 보호하기 위한 암호화 경계들은 데이터 세그먼트 경계들에 대응하도록 선택된다. ES 미디어 콘텐트는 그 후 상기 선택된 암호화 경계들을 이용하여 보호된다.
첨부 도면들을 참조하여 상세한 설명이 설명된다.
도 1은 일 실시예에 따라, ES 콘텐트를 보호하기 위한 예시적인 컴퓨팅 시스템을 도시하는 도면.
도 2는 일 실시예에 따라, 전송 스트림에 의해 전달된 ES 콘텐트를 보호하기 위한 예시적인 실시예들이 구현될 수 있는 예시적인 네트워크 환경을 도시하는 도 면.
도 3은 ES 미디어 콘텐트를 암호화하기 위하여 카운터 모드에서의 AES(Advanced Encryption Standard in Counter Mode)를 이용하는 동작들의 예시적인 양태들을 도시하는 도면.
도 4는 일 실시예에 따라, 피보호 ES 콘텐트와 함께 전송 스트림에 삽입하기 위한 예시적인 암호화 방법(TAG) 패킷을 도시하는 도면.
도 5는 일 실시예에 따라, 송신기가 전송 스트림 내의 ES들을 보호하기 위한 예시적 절차를 도시하는 도면.
도 6은 일 실시예에 따른, 예시적인 통상 스크램블링된 전송 스트림을 도시하는 도면.
도 7은 일 실시예에 따른, MAU(Media Access Unit) 페이로드 포맷(MPF) 헤더의 예시적인 고레벨 구조를 도시하는 도면.
도 8은 일 실시예에 따른, 도 7의 MPF 헤더의 예시적인 세부사항을 도시하는 도면.
도 9는 일 실시예에 따라, MPF를 이용하는 세 개의 RTP(Real-Time Transport Packet) 패킷들의 예시적인 시퀀스를 도시하는 도면.
도 10은 본 발명의 일 실시예에 따라, 단일의 MAU가 동일한 RTP 패킷 내의 세 개의 단편들(fragments)로 분할된 예를 도시하는 도면.
도 11은 표준 12 바이트 RTP 헤더를 도시하는 도면.
도 12는 MPF의 비트 필드 3의 예시적인 레이아웃을 도시하는 도면.
도 13은 일 실시예에 따른, MPF 헤더의 확장 필드의 예시적인 레이아웃을 도시하는 도면.
도 14는 일 실시예에 따라, ES 콘텐트를 보호하기 위한 예시적인 절차를 도시하는 도면.
개요
미디어 콘텐트 특정 속성들에 기초하여 암호화 경계들을 선택함으로써 ES 콘텐트를 보호하는 시스템들 및 방법들이 설명된다. 특히, 상기 시스템들 및 방법들은 ES의 MAU의 일부를 암호화(예를 들면, MPEG-2, 등을 이용하여)한다. 각각의 MAU는 단일의 비디오 또는 오디오 프레임(기초 스트림 프레임) 및 연관된 헤더들이다. 하나의 MAU는 하나 이상의 데이터 세그먼트들을 포함한다. 각각의 데이터 세그먼트는 콘텐트 암호화 파라미터들의 동일한 세트가 적용되는 MAU의 연속 섹션이다. 데이터 세그먼트는 완전히 암호화되거나 완전히 비암호화 상태(즉, 암호 해독된 상태)에 있다. ES들은 TS로부터 발생하지 않았을 수도 있다. 그러나, 이 ES 보호 동작들은 TS 스트림에 적용된 통상 스크램블링 동작들과 호환 가능하다.
TS가 피보호 ES 콘텐트를 포함하면, TS는 기존의 암호화를 유지하면서(즉, TS는 암호 해독되지 않음) ES들로 디멀티플렉스된다. ES들은, PC들 및 셋톱 박스들과 같은, 미디어 소비자들로의 후속 통신을 위하여 ES의 MAU들을 전송 프로토콜(예를 들면, RTP(Real-Time Transprot Protocol))에 캡슐화하도록 MPF(MAU payload format)로 맵핑된다. 각각의 MAU를 MPF로 맵핑하는 것은 각각의 ES를 임의의 다른 ES와는 독립적으로 처리(예를 들면, 디멀티플렉스, 인덱스, 저장, 등)하고, 각각의 MAU를 임의의 다른 MAU와는 독립적으로 처리하기 위한 충분한 정보를 미디어 소비자에게 제공한다. 이 기술들은, 하나 이상의 데이터 세그먼트들을 포함하는 MAU 부분들에 암호화를 적용하여 ES 콘텐트를 보호하지 않는 종래의 시스템들과는 대조적이다.
ES 콘텐트를 보호하기 위한 시스템들 및 방법들의 이들 및 다른 양태들이 이제 도 1 내지 14를 참조하여 보다 상세히 설명된다.
예시적인 장치
설명을 위하여, 요구되지는 않지만, ES 콘텐트를 보호하는 것이 일반적으로 퍼스널 컴퓨터와 같은 컴퓨팅 장치에 의해 실행되는 컴퓨터 실행 가능 명령어들에 관련하여 설명된다. 프로그램 모듈은 일반적으로는 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 개체, 컴포넌트, 데이터 구조, 등을 포함한다. 시스템들 및 방법들은 상기와 관련하여 설명되지만, 이후 설명된 행위들(acts) 및 동작들(operations)은 하드웨어로도 구현될 수 있다.
도 1은 ES 콘텐트를 보호하기 위한 예시적인 시스템(100)을 도시한다. 시스템(100)은 범용 컴퓨팅 장치(102)를 포함한다. 컴퓨팅 장치(102)는 퍼스널 컴퓨터, 랩톱, 서버, 핸드헬드 또는 모바일 컴퓨팅 장치, 등과 같은 컴퓨팅 장치 중 임의의 유형을 나타낸다. 컴퓨팅 장치(102)는 컴퓨터 판독 가능 매체(106)에 연결된 프로세서(104)를 포함한다. 컴퓨터 판독 가능 매체(106)는 컴퓨팅 장치(102)에 의 해 액세스 가능한 매체는 그 어떤 것이든지 될 수 있고, 이러한 컴퓨터 판독가능 매체는 휘발성 및 비휘발성 매체(예를 들면, ROM 및 RAM), 이동식 및 비이동식 매체를 포함한다. 컴퓨터 판독 가능 매체(106)의 RAM 부분은 즉시 액세스 가능하고/거나 프로세서(104)에 의하여 현재 동작되고 있는 프로그램 모듈 및 프로그램 데이터를 포함한다.
제한이 아닌 예로서, 컴퓨터 판독 가능 매체(106)는 프로그램 모듈(108) 및 프로그램 데이터(110)를 포함한다. 프로그램 모듈(108)은, 예를 들면, ES 보호 모듈(112), 피보호 ES 콘텐트 맵핑 모듈(114), 및 다른 프로그램 모듈(116)(예를 들면, 운영체제)을 포함한다. ES 보호 모듈(112)은 미디어 콘텐트 특정 속성들에 기초하여 암호화 경계들을 선택하여 ES 콘텐트를 보호한다. 특히, ES 보호 모듈(112)은 ES 콘텐트(118)를 암호화하여(예를 들면, MPEG-2, 등을 이용) 피보호 ES 콘텐트(120)를 생성한다. 이를 위하여, ES 보호 모듈(112)은 ES를 포함하는 MAU들의 부분들(즉, 데이터 세그먼트들)에 암호화를 적용한다. 일 실시예에서, 암호화 동작들은 카운터 모드에서의 AES(Advanced Encryption Standard in Counter Mode)이다. 각각의 MAU는, 후속하여 헤더들(예를 들면, 시작 코드들 및 패딩 비트들)과 연관되는 단일의 비디오 또는 오디오 프레임(기초 스트림 프레임)이다. 각각의 MAU는 하나 이상의 데이터 세그먼트들을 포함한다. 각각의 데이터 세그먼트는 ES 보호 모듈(112)이 콘텐트 암호화 파라미터들의 동일 세트를 적용하는 MAU의 연속 섹션이다. ES 보호 모듈(112)은 데이터 세그먼트를 완전히 암호화하거나, 데이터 세그먼트를 완전히 비암호화 상태에 둔다. ES들은 TS로부터 발생하지 않았을 수도 있다. 그러나, 이 ES 보호 동작들은 TS 스트림(예를 들면, "다른 데이터"(122))에 적용된 통상 스크램블링 동작들과 호환 가능하다.
피보호 ES 콘텐트 맵핑 모듈(114)("맵핑 모듈(114)")은 전송 패킷들(124)로의 캡슐화를 위하여 피보호 ES 콘텐트(120)를 MPF에 맵핑한다. MPF는 MAU의 일부를 비암호화 상태(비암호화 상태)로 전달하도록 한다. MPF는 또한 퍼스널 컴퓨터 또는 셋톱 박스(예를 들면, 도 2 참조)와 같은 미디어 소비자가, 각각의 피보호 ES(120)를 임의의 다른 ES와는 독립적으로 처리하고, 피보호 ES 내의 각각의 MAU를 임의의 다른 MAU와는 독립적으로 처리하게 하는 데 충분한 정보를 제공한다. MPF는 이하에서 "전송 프로토콜 캡슐화를 위한 피보호 ES 맵핑(Mapping Protected ES for Transport Protocol Encapsulation)" 섹션을 참조하여 보다 상세히 설명된다. 일 실시예에서, 전송 패킷들은 RTP에 기초한 패킷들에 대응한다.
일 실시예에서, ES 콘텐트(예를 들면, ES 콘텐트(118))는 미디어 콘텐트 전송 스트림에서 발생하지 않는다. 다른 실시예에서, 예를 들면, 이하에서 도 2를 참조하여 설명된 바와 같이, ES 콘텐트는 전송 스트림에서 발생한다. 또한, 예시적인 시스템(100)은 ES 보호 모듈(112)와 동일한 컴퓨팅 장치에서 구현되는 피보호 ES 콘텐트 맵핑 모듈(114)을 도시하지만, 맵핑 모듈(114)은 보호 모듈(112)을 구현하는 컴퓨팅 장치와는 상이한 컴퓨팅 장치에서 구현될 수 있다. 이러한 대안의 구현은 이하에서 도 2를 참조하여 설명되며, 보호 모듈(112)의 동작들은 콘텐트 소스에 의하여 구현되고, 맵핑 모듈(114)의 동작들은 미디어 센터에 의해 구현된다.
예시적 시스템
도 2는 본 발명의 일 실시예에 따라, ES 콘텐트를 보호하기 위한 예시적인 시스템(200)을 도시하며, 여기에서 ES 콘텐트는 전송 스트림에서 발생한다. 전송 스트림은 미디어 콘텐트를 캡슐화한다. 시스템(200)은, 예를 들면, 네트워크(206)를 통하여 하나 이상의 미디어 가입자들(208)에 연결된 콘텐트 소스(202) 및 미디어 센터(204)를 포함한다. 콘텐트 소스(100)는 비디오 게임 서버, 웹사이트, 비디오 서버, 음악 서버, 소프트웨어 아카이브(archive), 데이터베이스, 텔레비젼 네트워크, 등과 연관될 수 있다. 콘텐트 소스(202)의 스크램블링 모듈(210)은 전송 스트림을 암호화한다. 일 실시예에서, 전송 스트림 암호화(210)는 전송 스트림을 통상 스크램블링한다. 통상 스크램블링은 암호화된 전송 스트림을 스트림의 암호화된 부분들이 암호 해독되는 것을 요구하지 않고 처리되게(예를 들면, 디멀티플렉스, 인덱스, 등) 한다. ES 보호 모듈(112)의 연관된 동작들이 TS 스트림에 적용되는 통상 스크램블링 동작들과 호환 가능하므로, TS 스크램블링 모듈(210)은 전송 스트림에서 발생한 ES 콘텐트를 도 1의 ES 보호 모듈(112)에 관하여 전술된 바와 같이 보호한다.
미디어 센터(204)는, 예를 들면, TCP/IP(Transmission Control Protocol/Internet Protocol) 또는 다른 표준 통신 프로토콜들을 이용하여, 직접 또는 네트워크(206)를 경유하여 콘텐트 소스(content source, 202)에 연결될 수 있는 중심에 위치된 컴퓨팅 장치이다. 네트워크(206)의 예들은 IP 네트워크들, CATV(cable television) 네트워크들 및 DBS(direct broadcast satellite) 네트워크 들을 포함한다. 미디어 센터(204)는 디멀티플렉싱 및 맵핑 모듈(212)을 포함한다. 단일 컴퓨터 프로그램 모듈로서 도시되지만, 모듈(212)은 임의의 수의 컴퓨터 프로그램 모듈들로 구현될 수 있다. 프로그램 모듈(212)의 디멀티플렉싱 동작들은, TS의 암호화된 부분들을 암호 해독하지 않고, TS를 각각의 ES들로 디멀티플렉스한다.
미디어 소비자로의 통신을 위한 전송 패킷들로의 후속 캡슐화를 위하여, 도 1의 피보호 ES 콘텐트 맵핑 모듈(114)의 상기 동작들에 따라, 프로그램 모듈(212)의 맵핑 동작들은 디멀티플렉스된 피보호 ES 콘텐트를 MPF에 맵핑한다. 전술된 바와 같이, MPF는 전송 패킷(들)에 캡슐화되는 경우 MAU의 데이터 세그먼트가 비암호화 상태로 되도록 한다. MPF는 또한 미디어 가입자(208)가 수신 피보호 ES를 임의의 다른 ES와는 독립적으로 처리하게 하고, 피보호 ES 내의 각각의 연관된 MAU를 임의의 다른 MAU와는 독립적으로 처리하게 하기에 충분한 정보를 제공한다. MPF는 이하에서 " 전송 프로토콜 캡슐화를 위한 피보호 ES 맵핑" 섹션을 참조하여 더욱 상세히 설명된다. 일 실시예에서, 전송 패킷들은 RTP에 기초한 패킷들에 대응한다.
미디어 센터(204)는 캡슐화된 피보호 ES 콘텐트를, 네트워크(206)를 통하여, 하나 이상의 가입자들(208)에게 통신하며, 여기에서 PC(214) 및/또는 STB(216)가 미디어 콘텐트를 수신한다. PC(214) 상에서 처리되고 렌더링된 미디어 콘텐트는 PC(214)와 연관된 모니터 상에 디스플레이될 수 있고; STB(216) 상에서 처리되고 렌더링된 미디어 신호들은 TV(218) 또는 유사한 디스플레이 장치 상에 디스플레이될 수 있다. 일 실시예에서, TV(218)는 내부에 통합된 STB(216)의 성능들을 갖는 다.
전송 스트림 통상 스크램블링 분석
일 실시예에서, ES 콘텐트는 전송 스트림에 의해 전달된다. 이 시나리오에서, 콘텐트 소스(202)의 TS 스크램블링 모듈(210)은 통상 스크램블링을 위하여 전송 스트림을 분석한다. 특히, 암호화 후 전송 스트림이 거칠 수 있는 적어도 하나의 처리를 위한 데이터 요건들의 관점에서 전송 스트림이 분석된다. 처리들 중 하나 이상에 대응하는 통계 모델에 기초하여 결정이 이루어진다면, 가장 광범위한(즉, 임계적인) 데이터 요건들을 갖는 특정 처리에 대하여 임계 데이터 요건들이 결정될 수 있다. 이 분석은 전송 스트림의 어느 부분들이 암호화되지 않고 전달되는지 여부를 결정하기 위하여 수행된다.
통상 스크램블링 분석은 임의의 헤더 정보를 포함하는 전송 스트림 내의 임의의 패킷이 암호화되지 않고 전달되는 것에 대한 승인을 포함할 수 있다. 그러한 패킷들 및 헤더 정보의 설명이 이하에서 도 6을 참조하여 제공된다. PES 헤더 정보의 임의의 부분 또는 "엑스트라 헤더 데이터"의 임의의 부분을 포함하는 패킷들은 암호화되지 않고 전달된다. 또한, 완전한, 또는 부분적인 스트림 마크(Stream Mark)를 포함하는 패킷들은 암호화되지 않고 전달한다.
Figure 112008010049387-PCT00001
표 1을 참조하면, 본 실시예에서 비암호화 상태로 남겨지는 데이터의 양은 스트림 마크의 길이와 최대 데이터 페이로드 길이를 더한 것에 대응한다. 결합된 길이가, 예를 들면, 2개의 연속하는 TV 패킷 페이로드들의 길이를 초과하지 않는 한, 비암호화 섹션(clear section)은 스트림 마크 이전에 시작하여 스트림 마크 길이와 최대 데이터 페이로드 길이의 결합된 길이 이후에 종료할 수 있는 것을 주의한다. 예를 들면, 송신기(예를 들면, 도 2의 콘텐트 소스(202), 등)는 시퀀스 헤더를 나타내는 스트림 마크에 대하여 16 내지 368 바이트를 비암호화 상태로 할 수 있다(스트림 마크를 위한 4 바이트와 최대 데이터 페이로드 길이를 위한 12 바이트들을 합함).
스트림 마크가 현재 MAU의 시작 근처에 나타나는 경우, 이전의 MAU로부터의 일부의 데이터 량이 비암호화 상태에 남겨지도록 하는 것도 가능하다. 일 실시예에서, 이것은 비암호화 섹션의 길이가 368 바이트를 초과하지 않을 때 허용된다.
전송 스트림의 임의의 부분이 암호화되지 않고 전달할 수 있으므로, 다른 대안의 실시예들은, 프레임 헤더들 및 PES 헤더들에 포함된 데이터가 전송 스트림을 디스크램블링(descrambling)하지 않고서 처리하는 데 이용되지 않는다면, 프레임 헤더들 및 PES 헤더들에 통상의 스크램블링이 적용되는 것을 고려할 수 있다.
암호화
도 3은 ES 미디어 콘텐트를 암호화하기 위하여 카운터 모드에서의 AES를 이용하는 동작들의 예시적인 양태들을 도시하는 블럭도이다. 이하에서 도 3을 참조하여 설명된 다양한 데이터 및 동작들은 도 1의 ES 보호 모듈(112)의 예시적인 동작들 및 도 2의 TS 스크램블링 모듈(210)의 예시적인 동작들을 나타낸다. 데이터 세그먼트는 보호중인 콘텐트의 유형에 기초한 상이한 정의들을 가질 수 있지만, ES들의 암호화시, 임의의 수의 데이터 세그먼트들을 포함하는 MAU는 비디오 또는 오디오의 단일의 프레임을 나타낸다.
도 3을 참조하여, 카운터 모드 내에서의 AES는 전송 스트림의 각각의 데이터 세그먼트들에 기초하여 바이트들의 스트림을 생성한다. 바이트들의 스트림은 콘텐트의 임의의 비암호화 텍스트 바이트들과 XOR되어 암호화된 콘텐트를 생성한다. 키 스트림 생성기(Key Stream Generator)는 AES 라운드를 이용하여 한 번에 16 바이트 블럭의 키 스트림을 생성한다. AES 라운드로의 입력들은 콘텐트 암호화 키(KC) 및 새로운 세그먼트 내의 데이터 세그먼트 ID와 블럭 ID의 128 비트 연쇄(concatenation)이다. 키 스트림 생성기의 출력은 데이터 세그먼트의 대응 블럭(i)으로부터의 데이터와 바이트 단위로 XOR된다. 데이터 세그먼트가 16 바이트에 의해 균일하게 분할 가능하지 않은 경우, 최후 블럭으로부터의 데이터 세그먼트의 나머지 바이트들만 키 스트림과 XOR되고 암호화된 데이터 세트를 위하여 유지된다. MAU, 및 연관된 헤더들은 더 많은 데이터 세그먼트들을 나타낸다.
도 4는 피보호 ES들을 전달하는 전송 스트림으로의 삽입을 위한 예시적인 암호화 방법("TAG") 패킷을 도시한다. 도 4를 참조하면:
● adatation_field_control 비트들은 10b(적응 필드만 있음, 페이로드 없음)로 설정되어, 연속성 카운터(continuity counter)를 증분할 필요가 없다.
● AF 헤더는 MPEG 명세와 부합하는 4개의 바이트들을 포함한다.
○ 제1 바이트 = 적응 필드 길이
○ 제2 바이트 = 적응 필드 프리젠스 플래그(프라이빗 데이터 = 0x02)
○ 제3 바이트 = 프라이빗 데이터 길이(DRM 길이)
○ 제4 바이트 = 버전 번호(현재 0x00)
● DrmGuid는 {B0AA4966-3B39-400A-AC35-44F41B46C96B}로 설정된 GUID를 포함한다.
● base_counter는 후속하는 암호화된 패킷을 위하여 AES 카운터를 재동기화한다.
● SM 바이트(스트림 마크)는 후속하는 패킷이 처음 몇 개의 바이트가 소실될 수 있는 스트림 마크의 시작을 포함하는 것을 나타낸다.
○ SM = 0 - 다음 패킷이 PES 헤더의 시작 또는 전체 PES 헤더를 전달한다.
○ SM = 1 - 다음 패킷은 스트림 마크의 시작을 포함한다.
○ SM = 2 - 다음 패킷은, 첫 번째 바이트(00)가 소실되어 있는 스트림 마크의 시작을 포함한다.
○ SM = 3 - 다음 패킷은, 처음 두 바이트들(00 00)이 소실되어 있는 스트림 마크의 시작을 포함한다.
○ SM = 4 - 다음 패킷은 처음 세 바이트들(00 00 01)이 소실되어 있는 스트림 마크의 시작을 포함한다.
○ SM = 기타 - 보존됨.
● Private_DRM_parameters는 대응하는 Key ID 값을 갖는 Key ID 확장 세트를 포함하는 데이터 세그먼트 서술자(Data Segment Descriptor)를 포함한다. 데이터 세그먼트 ID는 TAG 패킷의 base_counter 섹션에서 지시되므로, AES128 초기화 벡터 확장(AES128 Initialization Vector extension)은 존재하지 않는다.
● 패킷은 0xFF로 패드된다.
따라서, TAG 패킷은 각각의 피보호 PES 유닛의 앞에 삽입되는 KID(Key Identifier)를 갖는 단일 TS 패킷이다. 이 실시예에서는, 콘텐트가 미디어 소비자에게 전달될 때 매칭 DRM(Digital Rights Management)을 검색하기 위하여 TAG 패킷이 이용된다. 콘텐트 보호층은 카운터 모드에서의 AES 128 비트 키를 포함하며, 이 경우 다음의 요건들이 적용되는데, 즉 128 비트 카운터는 base_counter(MSB) 및 minor_counter(LSB)의 두 64 비트 필드들로 분할된다. base_counter 및 minor_counter는 전술된 데이터 세그먼트 ID 및 블럭 ID와 등가이다. TAG 패킷은 전송 스트림의 암호화된 부분에서 이용된 암호화 알고리즘을 위한 식별을 제공하고, 허가된 암호 해독자(decryptor)가 암호 해독 키를 유도하는 데 필요한 데이터를 제공하며, 암호화되지 않거나 암호화되어 전달하는 전송 스트림의 부분들을 식별할 수 있다. TAG 패킷은 각각의 처리들(트릭 모드들 또는 썸네일 추출을 위한 디멀티플렉싱 또는 인덱싱)을 위해 상기 암호화된 스트림의 어느 부분들이 이용되는 지를 식별하는 또 다른 데이터를 포함할 수 있다. 또한, 멀티플렉스된 전송 스트림에 따라 TAG 패킷이 삽입된다.
전송 스트림의 모든 암호화된 부분들에 대응하여 TAG 패킷이 생성될 수 있다. 대안적으로, 암호화 방법 패킷들은 암호화된 PES 페이로드 데이터의 개별 패킷들 또는 바이트들에 대응하여 생성될 수 있다. 따라서, TAG 패킷은 전송 스트림의 각각의 PES 헤더에 대응하여, 전송 스트림 내의 미리 정해진 수의 PES 헤더들에 대응하여, 또는 다른 처리들을 위하여 암호화되지 않고 전달하는 패킷들의 미리 정해진 패턴에 대응하여 생성될 수 있다.
도 5는 일 실시예에 따라, 전송 스트림 내의 ES 콘텐트를 보호하기 위한 송신기의 동작들의 예시적인 흐름을 도시한다(ES 콘텐트가 전송 스트림에 의해 운반되지 않는 경우와 비교하여). 이하의 리스트는 도 5의 양태들을 설명한다.
● scr - 이 변수는 현재의 TS 패킷이 통상 스크램블링된다면 "예"로 설정되고, 그렇지 않으면 "아니오"로 설정된다.
● key _ sync - 이 변수는 송신기가 AES 키를 갱신하고 있다면 "예"로 설정되고, 그렇지 않으면 "아니오"로 설정된다.
● PID (13 bit ) - 선택된 기초 스트림의 PID 값.
● base _ counter - 이 64 비트 필드는 송신기의 수명에 걸쳐 송신기에 의해 고유하게 정의된다. 일 실시예에서, 비트 0 내지 50은 section_counter를 나타내고, 비트 51 내지 63은 PID를 위해 보존된다.
● Section _ counter (51 bit ) - scr 상태 변수의 각각의 no-to-yes 전환에 대하여 증분되는 주기적 카운터.
● minor _ counter - 16 스크램블링된 바이트들의 각각의 블럭에 대하여 증분되는 64 비트 카운터.
● i - 각각의 스크램블링된 바이트에 대하여 증분되는 4 비트 카운터.
● scramble16 - AESKEY[base_counter│minor_counter].
Replace AES Key 이벤트가 발생한 후, 송신기는 각각의 PES 컴포넌트와 재동기할 때까지 모든 PID들을 스크램블링하는 것을 즉시 중지한다. 이 전환은 동일한 프로그램으로부터의 모든 PID들이 동일한 키로 스크램블링되는 것을 보장한다. scr 상태를 정의할 때, 송신기는, 각각의 수신된 TS 패킷에 대하여, 아래 조건들 중 어느 하나가 적용되면 scr 상태 변수를 "아니오"로 설정한다:
● key _ sync = yes
● TS 패킷은 PES 헤더의 전체 또는 일부를 포함한다.
● TS 패킷은 이하의 테이블에 열거된 스트림 마크들 중 하나 이상의 전체 또는 일부를 포함한다. 상기 표 1에서 도시된 바와 같이, 스트림 마크는 MPEG 시작 코드 및 그것의 후속하는 데이터 페이로드로 구성된다.
도 6은 일 실시예에 따른, 예시적인 전송 스트림을 도시한다. 송신기는 비암호화 상태로 남은 임의의 TS 패킷의 앞에 TAG 패킷을 삽입한다. 도 6에 도시된 바와 같이, 다음 두 개의 가능한 시나리오들이 발생할 수 있다. 케이스 A: PES 헤더의 전부 또는 일부를 포함하는 패킷의 앞에 TAT 패킷이 삽입된다. 케이스 B: 스트림 마크의 전부 또는 일부를 포함하는 패킷의 앞에 TAG 패킷이 삽입된다.
또한, 실시예들은 TAG 패킷이 전송 스트림에 삽입되는 것이 필요하지 않다. 암호 해독의 시점까지는 TAG 패킷이 필요하지 않으므로, TAG 패킷은 암호 해독 시점까지 프로세서에 의해 수신되지 않는 한, 프로세서에 대역내(in-band) 또는 대역외(out-of-band)(예를 들면 프라이빗 테이블에 의해) 송신될 수 있다. 또한, TAG 패킷은 그 후 프로세서에 대역내 또는 대역외 송신되는 콘텐트 이용 라이센스(content usage license)에 송신될 수 있다.
MAU 페이로드 포맷으로의 피보호 ES 맵핑
피보호 ES가 MPF로 맵핑되어 통상 스크램블링된 전송 스트림 내의 MAU의 섹션들은 비암호화 상태로 남는다. 이 맵핑은 미디어 소비자가 각각의 MAU를 독립적으로 처리하는 것을 허용한다. 일 구현에서, 콘텐트 소스(content source, 202)와 같은 송신기가 이 맵핑 동작들을 실시한다.
종래의 RTP 헤더의 구문(syntax)은 RFC-3550에서 정의되며 도 11에 도시된다. RTP 헤더와 함께, 도 1의 시스템들(100) 및 도 2의 시스템(200)은 피보호 ES 콘텐트(예를 들면, 도 1의 피보호 ES 콘텐트(120))를 MPF(MAU Payload Format)로 맵핑한다. 그러나, 멀티미디어 프리젠테이션의 모든 미디어 스트림들은 동일한 MPF를 이용할 필요가 없으며, 상이한 페이로드 포맷들이 이용될 수 있다. 이제 MAU들이 MPF에 캡슐화되는 방법을 설명한다.
도 7은 일 실시예에 따른, MPF 헤더의 예시적인 고레벨 구조를 도시한다. 표준 RTP 헤더와 관련하여 헤더가 도시된다. 전송 패킷 내의 각각의 MAU, 또는 그 단편의 앞에 송신기(예를 들면, 도 1의 컴퓨터(102) 및/또는 도 2의 미디어 센터(204))에 의하여 MPF 헤더가 삽입된다. 도 7에 도시된 바와 같이, 본 실시예에서의 MPF 헤더는 세 개의 섹션들로 분할된다. 각각의 섹션은 1 바이트 비트 필드로 시작하며, 하나 이상의 선택적 필드들이 후속된다. 어떤 경우에는, 최대 두 개의 전체 섹션들이 MPF 헤더로부터 생략될 수 있다. 따라서, MPF 헤더는 1 바이트 정도로 작을 수 있다.
"페이로드"가 MPF 헤더에 후속한다. 페이로드는 완전한 MAU 또는 그 단편을 포함한다. 페이로드는 부분 MAU를 포함할 수 있어, 큰 MAU들이 복수의 전송 패킷들 내의 복수의 페이로드들에 걸쳐 단편화되도록 한다. 첫 번째 페이로드는, 전송 패킷의 사이즈에 의해 허용되는 바대로, MPF 헤더들 및 페이로드들의 추가적인 쌍들이 후속될 수 있다.
도 7에서 "패킷 특정 정보(Packet Specific Info)"로 호칭되는 MPF 헤더의 제1 섹션은 전송 패킷의 모든 페이로드들에 특정한 정보를 포함한다. "패킷 특정 정보" 섹션은, 각각의 전송 패킷 내에서 RTP 헤더의 종료 직후 나타나는 제1 MPF 헤더 내에 한 번만 포함된다. "MAU 속성들"로 호칭되는 제2 섹션은 페이로드를 서술하는 정보를 포함한다. 예를 들어, 이 섹션은 페이로드가 비디오 I-frame과 같은 sync-point인 MAU를 포함하는지 여부를 특정하고, 또한 페이로드의 사이즈가 어떻게 결정되는 지를 특정한다. 또한, 이 섹션은 이전의 패킷이 소실되었다면 수신기가 전송 패킷을 파스하는 것을 허용하기 위한 정보를 포함한다. 이것은 MAU가 복수의 전송 패킷들에 걸쳐 단편화되는 경우에 유용하다.
"MAU 타이밍"으로 호칭되는 제3 섹션은, 페이로드 내의 MAU와 연관된 다양한 타임스탬프들(timestamps)에 관한 정보를 제공한다. 예를 들면, 이 섹션은 MAU의 프리젠테이션 시간이 어떻게 결정되는 지를 특정한다. 이 섹션은 또한 추가적인 정보가 MPF 헤더에 포함되게 하는 확장 메커니즘들을 포함한다.
도 8은 일 실시예에 따른, 도 7의 MPF 헤더의 예시적인 상세한 레이아웃을 도시한다. 도 8의 세 개의 섹션들(802 내지 806)의 각각은 수 개의 개별 헤더 필드들을 포함한다. 이 필드들은 도 8에서 박스들로 도시된다. 박스들의 높이들은 헤더 필드들의 상대적 사이즈들을 표시한다. 그러나, 이 도면은 완전히 비례적으로 그려진 것은 아니며, "확장(Extension)" 필드는 가변 사이즈를 갖는 것을 유의해야 한다.
도 8을 참조하면, 세 섹션들의 각각의 제1 헤더 필드는 비트 필드이다. 한 섹션 내의 다른 헤더 필드들은, 그 섹션의 비트 필드에 의해 지시되면, 존재한다. 어떤 경우에는, 비트 필드를 포함한 전체 섹션이 생략될 수 있다. 패킷 특정 정보(Info) 섹션은 "비트 필드 1(Bit Field 1)"을 포함하며, 도 8에 도시된 다른 필드들 중 어느 하나를 포함할 수도 있다. 동일한 전송 패킷 내의 부가적인 MPF 헤더들은 "비트 필드 2"로 시작하며 "MAU 속성" 섹션 및 "MAU 타이밍" 섹션 내의 필드들을 포함한다.
가장 간단한 가능성 있는 경우에, 전송 패킷은 단일의, 완전한 MAU를 포함한다. 이 경우, 헤더 필드들의 전부를 포함하는 것이 가능하다. 그러나, 필요하지 않은 필드들은 생략될 수 있다. MPF 헤더의 세 섹션들의 각각은 (필드들이 존재한다면)섹션 내의 필드들 중 어느 것이 존재하는 지를 나타내는 비트 필드를 갖는다.
예를 들어, 현재 페이로드의 종료에 대한 바이트 오프셋을 특정하는 "오프셋(Offset)" 필드는 패킷이 단일 페이로드를 포함할 때는 필요하지 않은데, 왜냐하면 페이로드의 길이는 전송 패킷의 사이즈에 의해 추정될 수 있기 때문이다. "비트 필드 2(Bit Field 2)" 내의 "OP" 비트는 "오프셋" 필드가 존재하는지 여부를 나타낸다. "비트 필드 3" 내의 모든 비트들이 0이라면, "비트 필드 3" 자신은 생략될 수 있으며, 이것은 "비트 필드 2" 내의 "B3P" 비트를 0으로 설정하여 나타낸다.
복수의 페이로드들을 단일의 전송 패킷에서 결합하는 것이 가능하다. 이것은 "그룹화(grouping)"로 지칭된다. "오프셋" 필드는 "그룹화"의 사용을 나타낸다. "오프셋" 필드가 존재하면, 다른 MPF 헤더 및 다른 페이로드가 현재 페이로드의 종료후 후속할 수 있다. "오프셋" 필드는 "오프셋" 필드 자신의 종료로부터 카운트하여, 현재 페이로드의 종료까지의 바이트 수를 지정한다. 다른 MPF 헤더가 현재 페이로드의 종료에 후속한다면, "오프셋" 필드의 값뿐만 아니라 전송 패킷의 크기, 및 RTP가 전송 프로토콜로서 이용되는 경우라면 RTP 패딩 영역의 사이즈를 고려할 필요가 있다.
단일의 MAU는 복수의 페이로드들로 분할될 수 있다. 이것은 "단편화(fragmentation)"로 호칭된다. 단편화는 MAU가 단일의 전송 패킷 내에서 적합할 수 있는 것보다 더 큰 경우에 1차적으로 사용된다. "비트 필드 2" 내의 "F" 필드는 페이로드가 완전한 MAU 또는 그 단편을 포함하는지 여부를 나타낸다.
"MAU 타이밍" 섹션 내의 필드들은 MAU의 제1 단편을 포함하는 페이로드에 대한 MPF 헤더 내에서만 지정되어야 한다. 이에 대한 유일한 예외는 "MAU 타이밍" 섹션 내의 "확장" 필드가 동일한 MAU의 상이한 단편들에 대하여 상이한 확장을 포함하는 경우이다. MAU가 단편화되는 경우, "비트 필드 2" 내의 비트들 "S", "D1", 및 "D2"는 제1 단편을 포함하는 페이로드에 대한 MPF 헤더에서만 의미가 있다. 따라서, 수신기들(미디어 소비자들)은 "F" 필드의 값이 0 또는 2라면 이 비트들을 무시한다.
이 실시예에서, MAU가 너무 커서 단일의 전송 패킷에 적합하지 않게 되는 경우가 아니라면 MAU는 단편화되지 않는다. 이 실시예에서는, 단일의 전송 패킷 내에서, 하나의 MAU의 단편은 다른 MAU, 또는 다른 MAU의 단편과 결합되지 않는다. 그러나, 수신기들은 여전히 이 경우들을 취급할 수 있다. 이것의 일 예가 도 9에 도시된다.
도 9는 일 실시예에 따라, MPF를 사용하는 세 개의 RTP 패킷들의 예시적인 시퀀스를 예시한다. 세 개의 전송 패킷들은 4 MAU들의 데이터를 운반한다. 제4 MAU는 제4 전송 패킷(비도시)에서 연속된다. 상기 도면은, 원하는 경우에, 고정된 사이즈의 전송 패킷들을 생성하기 위하여 MAU들의 단편화가 어떻게 이용될 수 있는 지를 도시한다. 도면에서 알 수 있는 바와 같이, MAU 2는 두 개의 전송 패킷들에 걸쳐 단편화된다. 제1 전송 패킷에서, MAU 2를 위한 MPF 헤더는 MAU 2가 다음 전송 패킷에서 연속되는 것을 지정한다. (이것은 비트 필드 2 내의 "F" 필드를 이용하여 신호된다).
제2 전송 패킷은 "MAU 타이밍" 필드를 생략한 MPF 헤더로 시작하는데, 왜냐하면 MAU 2에 대한 "MAU 타이밍" 필드는 이미 제1 전송 패킷에서 지정되었기 때문이다. MAU 3에 대한 페이로드 포맷 헤더(Payload Format Header)의 시작을 찾기 위하여 "MAU 속성(properties)" 섹션의 "오프셋" 필드가 이용된다. 이것은 이전의 전송 패킷이 소실된 경우라도 클라이언트가 MAU 3을 디코드하게 한다. 유사하게, 상기 도면은 MAU 4가 제2 및 제3 전송 패킷들에 걸쳐 어떻게 단편화되는 지를 도시한다. 그러나, MAU 4는 너무 커서 제3 전송 패킷에는 추가적인 MAU들이 삽입될 수 없다. 이 예에서, MAU 4는 제4 전송 패킷에서 연속되며, 이것은 도시되어 있지 않다. 이와 같은 상황들에서는, 제3 전송 패킷의 페이로드 포맷 헤더는 "오프셋" 필드를 포함할 필요가 없으며, 전체 "MAU 속성" 섹션을 생략하는 것이 가능할 수 있다. 그러면, MPF 헤더의 나머지 부분은 "패킷 특정 정보 섹션(Packet Specific Info section)"만 포함하며, 단일의 바이트 정도로 작을 수 있다.
하나의 MAU가 복수의 페이로드들로 단편화되면, 페이로드들은 별도의 전송 패킷들 내에서 전달되는 것이 보통이다. 그러나, 이 MPF는 또한 동일한 MAU에 대한 복수의 페이로드들이 단일의 전송 패킷 내에서 전달되게 한다.
전송 패킷 내의 페이로드가 MAU의 단편을 포함하면, 이것은 "비트 필드 2" 내의 "F" 필드에 의해 나타낸다.
도 10은 일 실시예에 따라, 동일한 RTP 패킷 내에서 단일의 MAU가 세 개의 단편들로 분할된 예를 도시한다. 이 예에서, 제1 MPF 헤더 내의 "F" 필드는 1로 설정되어, 제1 페이로드가 MAU의 제1 단편을 포함하는 것을 나타낸다. "MAU 타이밍" 섹션은 이 제1 페이로드에만 존재한다. 제2 MPF 헤더 내의 "F" 필드는 0으로 설정되어, 그 페이로드가 MAU의 첫 단편도 아니고 최종 단편도 아닌 단편을 포함하는 것을 나타낸다. 제3 MPF 헤더 내의 "F" 필드는 2로 설정되어, 그 페이로드가 MAU의 최종 단편을 포함하는 것을 나타낸다.
통상의 RTP 샘플링 클럭 및 월클럭(wallclock)에 더하여, MPF는 이제 설명되는 수 개의 추가적인 타임스탬프들 및 시간의 개념들을 제공한다. RTP 헤더는 단일의 타임스탬프를 가지며, 이것은 패킷의 데이터가 샘플링된 시간을 지정한다. 이 타임스탬프는 종종 샘플링 클럭으로 호칭된다. 상이한 미디어 스트림들에 속하는 패킷들의 RTP 타임스탬프들은 비교될 수 없는 것을 주목하는 것이 유용하다. 그 이유는 샘플링 클럭은 상이한 미디어 스트림들에 대하여 상이한 주파수들에서 실행될 수 있기 때문이다. 예를 들면, 오디오 스트림의 샘플링 클럭은 44100 Hz에서 실행될 수 있는 한편, 비디오 스트림의 샘플링 클럭은 90000 Hz에서 실행될 수 있다. 더욱이, RFC-3550은 초기 RTP 타임스탬프에 대한 값이 무작위로 선택되어야 하는 것을 지정한다. 사실상, 각각의 미디어 스트림은 그 자체의 타임라인을 갖는다. 본 출원에서, 각각의 그러한 타임라인은 "미디어 타임라인"으로 호칭된다.
RTP는 상이한 미디어 스트림들에 대한 타임라인들이 "월클럭"으로 호칭되는 기준 클럭의 타임라인에 동기화되도록 한다. RTP 송신기들(senders)은 수신기로 하여금, RTCP 송신기 리포트 패킷(RTCP Sender Report packet) 내에 샘플링 클럭과 월클럭 간의 맵핑을 송신함으로써 이 동기화를 수행하도록 한다. 각각의 미디어 스트림에 대하여 상이한 RTCP 송신기 리포트가 송신되어야 하는데, 그 이유는 미디어 스트림들은 상이한 샘플링 클럭들을 사용할 수 있기 때문이다.
맵핑들은 일정 간격에서 다시 업데이트되고 송신되어 수신기가 월클럭과 샘플링 클럭 간의 가능한 드리프트(drift)에 대하여 정정하도록 한다. 송신기의 월클럭이 수신기의 월클럭과 관련하여 드리프트한다면, 클럭 드리프트는 여전히 문제가 될 수 있다. 두 클럭들은, 예를 들면, NTP 프로토콜을 이용하여 동기화될 수 있지만, RTP 명세(specification)는 특별한 동기화 방법을 지정하지 않는다. 월클럭은 인코더로부터 발생하는 것을 유의한다. RTP 송신기 및 인코더가 별개의 엔티티(entity)라면, 월클럭은 송신기에서의 임의의 물리적 클럭과 관련되지 않는 것이 보통이다.
이 MPF는 NPT(Normal Play Time) 타임라인으로 호칭되는 제3 타임라인을 사용한다. NPT 타임라인은 미디어 "프리젠테이션"을 송신하는 데 RTP가 이용되는 경우에 주로 유용하다. NPT 타임라인으로부터의 타임스탬프들은 프리젠테이션의 시작시 0에서 시작하는 것이 보통이다. NPT 타임스탬프들은 미리 기록된 프리젠테이션을 송신하는 경우 특히 유용한데, 그 이유는 이 타임스탬프들은 수신기가 프리젠테이션 내에서 검색할 위치를 특정하는 것을 도울 수 있기 때문이다. 이것은 수신기가 RTP 송신기에 새로운 위치를 통신하기 위한 어떤 메커니즘의 존재를 가정한다.
RTP는 멀티 미디어 컨퍼런싱 응용들을 위해 설계되었으므로, RTP 명세는 NPT 타임라인은 논하지 않는다. 그러나, RTSP(비디오 주문형 응용들을 위한 제어 프로토콜)과 같은 RTP상에 구성되는 다른 프로토콜들은 NPT 타임라인의 개념을 포함한다. RTSP에서, 제어 프로토콜은 각각의 미디어 스트림에 대하여 미디어 타임라인과 NPT 타임라인 간의 맵핑을 제공한다.
MPF는 MAU와 연관된 NPT 타임라인 타임스탬프를 특정하기 위한 메커니즘을 정의한다. 그러나, 실제로는 RTSP에 의하여 정의된 것과 같은, 미디어 타임라인과 NPT 타임라인 간의 대역외 맵핑이 선호될 수 있는데, 그 이유는 MPF 헤더의 오버헤드를 감소시키기 때문이다.
모든 RTP 순응 시스템들은 타임스탬프들의 랩어라운드(wrap around)를 처리한다. 90000 Hz의 전형적인 클럭 주파수에서, RTP 타임스탬프는 거의 13 시간 마다 랩어라운드할 것이다. 그러나, RTP 명세는 샘플링 클럭에 무작위 오프셋이 반드시 부가되어야 한다고 기술하고 있으므로, 수신기는 13시간 보다 크게 적은 시간 내에 첫 번째 랩어라운드를 경험할 수 있다. RTP 타임스탬프의 랩어라운드는 모듈러 연산을 이용하여 처리되는 것이 보통이다. 모듈러 연산이 이용되는 경우, 타임스탬프들은 한 타임스탬프를 다른 것으로부터 빼서 결과가 양인지 음인지 여부를 관찰하여 비교되는 것이 보통이다.
MPF에서, 각각의 MAU는 "디코드 시간(Decode Time)" 및 "프리젠테이션 시간Presentation Time)"을 갖는다. 디코드 시간은 그 때까지 MAU가 수신기의 디코더에 전달되어야 하는 시간이며, 프리젠테이션 시간은 MAU가 수신기에 의해 제공(디스플레이 또는 재생)되어야 하는 시간이다. 두 시간들은 모두 미디어 타임라인에 속한다. 네트워크 및 디코더 내의 지연들은 RTP 송신기에 알려져 있지 않은 것이 보통이므로, 수신기는 디코드 타임스탬프 또는 프리젠테이션 타임스탬프의 절대값들을 이용하지 않는다. 수신기는 한 쌍의 디코드 타임스탬프들 또는 한 쌍의 프리젠테이션 타임스탬프들 간의 상대적인 차이만 고려한다.
비디오 코덱(video codec)이 양방향 비디오 프레임들을 생성하는 경우와 같은 경우에, MAU들은 그들이 제공될 상이한 순서로 디코드될 수 있다. 이 실시예에서, RTP 송신기는 MAU들을 그들이 디코드되어야 하는 순서로 송신한다.
RTP 헤더 내의 "타임스탬프" 필드는 전송 패킷 내의 제1 MAU의 프리젠테이션 시간으로 맵핑한다. 전송 패킷들은 디코드 순서로 송신되므로, 연속적인 MAU들의 프리젠테이션 시간 타임스탬프들은 단조롭게 비감소(monotonically non-decreasing)하지 않을 수 있다.
MPF 헤더는 페이로드 내에 MAU의 디코드 시간을 특정하는 데 이용되는 선택적인 "디코드 시간(Decode Time)" 필드를 포함한다. MPF는 또한 전송 패킷이 하나 보다 많은 MAU를 포함하는 경우, MAU의 프리젠테이션 시간을 특정하는 데 이용되는 "프리젠테이션 시간(Presentation Time)" 필드를 포함한다. 전송 패킷에 단일 MAU만 포함되는 경우에는, "프리젠테이션 시간" 필드는 대체되는데, 그 이유는 패킷의 제1 MAU 내에서 그 필드를 "타임스탬프" 필드가 대체하는 기능을 하기 때문이다. 이 실시예에서, "디코드 시간" 및 "프리젠테이션 시간" 필드들은 모두 "타임스탬프" 필드와 동일한 클럭 분할(clock resolution)을 이용하여 표현된다.
용어 "트릭 재생(trick play)"은 수신기가 비실시간 속도(non-real time rate)로 미디어 프리젠테이션을 렌더링하는 것을 의미한다. 트릭 재생의 예들은 프리젠테이션의 고속 포워딩 및 리와인딩을 포함한다. RTP 송신기가 트릭 재생 모드에서 송신 중이라면, 각각의 MAU에 대한 디코드 타임스탬프 및 프리젠테이션 타임스탬프는 실시간 속도로 증가해야 한다. 이것은 디코더가 트릭 재생이 이용되는 것을 모르고 MAU들을 디코드하도록 한다. MPF 헤더 내의 "디코드 시간" 및 "프리젠테이션 시간" 필드들은 트릭 재생에 의하여 영향받지 않지만, "NPT" 필드는(존재하는 경우) 그렇지 않다. 예를 들어, 미디어 프리젠테이션이 리와인드되고 있다면, MAU들의 "프리젠테이션 시간" 타임스탬프는 증가하는 중일 것이지만, "NPT" 필드의 값은 감소하는 중일 것이다.
MPF 헤더 내의 "NPT" 필드는, MAU가 속하는 정규 재생 시간(Normal Play Time) 타임라인 내의 위치를 지정한다. "NPT" 필드가 존재하는 경우, 두 타임라인들 간의 맵핑이 이용 가능하다면, 수신기는 프리젠테이션 시간으로부터 MAU의 정규 재생 시간을 계산할 수 있다. 이 맵핑을 설정하기 위한 다양한 접근법들이 후술된다. RTP 송신기는 미디어 타임라인 내의 타임스탬프들에 무작위 오프셋을 부가하므로, 프리젠테이션 시간 타임스탬프는 NPT 타임스탬프를 직접 대체하는 것으로서 사용되지 않는다. 이 무작위 오프셋은 수신기에 알려져 있더라도, 미디어 타임라인 타임스탬프들의 랩어라운드는 문제가 될 수 있다.
이 문제들에 대한 가능한 해법은 정규 재생 시간 타임라인과 미디어 타임라인 간의 맵핑을 제공하기 위한 대역외 메커니즘을 송신기가 사용하는 것이다. 이 맵핑은 송신의 시작시 한 번만 또는 필요에 따라 반복하여 제공될 수 있다. 또한, 트릭 재생이 가능하다면, 송신기는 트릭 재생 속도(trick play rate)를 통신할 수 있다. 예를 들어, 프리젠테이션이 리와인드되는 중이라면, 트릭 재생 속도는 음이다. 수신기는 프리젠테이션 시간이 증가함에 따라 감소하는 NPT 타임스탬프들을 생성하기 위하여 트릭 재생 속도를 이용한다.
맵핑이 송신의 시작시 한 번만 제공된다면, 수신기는 정규 재생 시간 타임라인과 월클럭 타임라인 간의 맵핑을 설정한다. 이것은 적절한 RTCP 송신기 리포트 패킷이 수신되자마자 가능한 것이 보통이다. MAU의 월클럭 시간에 기초하여 각각의 MAU에 대하여 NPT 타임스탬프를 계산하는 것이 바람직한데, 그 이유는 미디어 타임라인으로부터의 타임스탬프들은 월클럭 타임라인에 대하여 드리프트할 수 있기 때문이다.
RTSP 프로토콜은 송신의 시작시 미디어 타임라인과 정규 재생 시간 타임라인 간의 맵핑을 제공하는 제어 프로토콜의 일 예이다. 복잡도(complexity)와 오버헤드(overhead)간의 적절한 절충(trade-off)를 제공할 수 있는 다른 해법은 sync-point MAU들에서만 "NPT" 필드를 포함하는 것이다. "NPT" 필드는 정규 재생 시간 타임라인과 프리젠테이션 또는 월클럭 타임라인들 간의 맵핑을 설정하는 데 이용된다. non-sync point MAU들의 경우, 수신기는 이전에 설정된 맵핑을 이용하여 NPT 타임스탬프를 계산한다. 트릭 재생이 이용되는 경우, 송신기는 모든 MAU에 대하여 "NPT" 필드를 포함할 것이다.
MPF 헤더 내의 "송신 시간" 필드는 전송 패킷의 송신 시간을 특정한다. 이것은 전송 패킷들의 시퀀스가 한 서버로부터 제2 서버로 전송되는 경우 유용할 수 있다. 제1 서버만이 패킷들에 대한 송신 스케쥴을 계산할 필요가 있다. 제2 서버는 "송신 시간" 필드의 값에 기초하여 다른 클라이언트들에 전송 패킷들을 포워딩할 것이다. 전송 패킷들을 클라이언트에 포워딩하는 경우에는 "송신 시간" 필드를 포함할 필요는 없다. 그러나, 클라이언트들은 패킷 도달 시간들의 차이에 대하여 일련의 패킷들 내의 "송신 시간" 필드들의 값들 간의 차이를 비교함으로써 네트워크 정체(network congestion)를 검출하기 위하여 "송신 시간" 필드를 이용할 수 있다. "송신 시간" 필드는 미디어 타임라인과 동일한 유닛들을 사용한다.
"대응(Correspondence)" 필드는 월클럭 타임라인과 현재 미디어 타임라인 간의 맵핑을 제공한다. RTP가 전송 프로토콜인 경우, 이것은 RTCP 송신기 리포트들에 제공된 동일한 맵핑이다. 전송 패킷에 상기 맵핑을 포함하는 것은 별개의 RTCP 패킷을 송신하는 것보다 더 효율적이다. 이것은 송신기가 RTCP 송신기 리포트의 주파수를 감소시키고 원하는 바에 따라 여전히 빈번히 맵핑을 송신하도록 한다.
도 11은 참고 목적으로 표준 12 바이트 RTP 헤더를 도시한다. 도 11을 참조하면:
● "버전(Version)"(V) 필드: 2 비트. 이 필드는 2로 설정된다.
● "패딩(Padding)"(P) 비트: 이 비트는 RTP 패킷의 종료에 패딩을 부가하는 데 사용된다.
● "확장(Extension)"(X) 비트: 이 비트는 RTP 헤더 확장이 존재하면 1로 설정된다. RTP 프로파일은 헤더 확장이 사용되는 방법을 정의한다. RTP 헤더가 0이 아닌 "확장" 비트를 가진다면 수신기는 헤더 확장을 파스하거나 스킵할 수 있다.
● "기여 소스(Contributing Source)"(CC) 필드: 4 비트. RTP 헤더가 0이 아닌 기여 소스 필드를 가진다면 수신기는 기여 소스들의 리스트를 정확히 파스, 또는 스킵할 수 있다.
● "마커"(M) 비트: 이 비트는 전송 패킷 내의 페이로드 중 어느 하나가 완전한 MAU 또는 MAU의 최종 단편을 포함하면 1로 설정된다.
● "페이로드 유형(Payload Type)"(PT) 필드: 7 비트. RTP 페이로드 유형의 할당은 이 문서의 범위 밖에 있다. 그것은 이 페이로드 포맷이 사용되거나 동적으로 대역외 신호되도록 하는(예를 들면, SDP 이용) RTP 프로파일에 의해 지정된다.
● "시퀀스 번호(Sequence Number)" 필드: 16 비트. 이 필드는 동일한 SSRC 값을 가지고 송신된 각각의 전송 패킷에 대하여 1씩 증가하는 숫자를 포함한다. RTP 시퀀스 번호의 초기값은 non-RTP 수단을 통해 클라이언트에게 통신될 수 있다.
● "타임스탬프" 필드: 32 비트. 이 필드는 전송 패킷에 포함되어 있는 제1 페이로드에 적용되는 타임스탬프를 지정한다. 디폴트로, 상기 필드는 프리젠테이션 시간으로서 해석된다. "타임스탬프" 필드의 클럭 주파수는 90kHz, 즉 1/90000 초로 분할되는 것이 권장된다. 송신기 및 수신기는 non-RTP 수단을 통해 상이한 클럭 주파수를 교섭할 수 있다.
● "동기화 소스(Synchronization Source)"(SSRC) 필드: 32 비트. SSRC필드에 대하여 동일한 값을 갖는 전송 패킷들은 "타임스탬프" 필드에 대하여 동일한 타임라인과 "시퀀스 번호" 필드에 대하여 동일한 번호 공간(number space)을 공유한다.
RTP 헤더는 MPF 헤더가 후속된다. 유일한 예외는 오직 패딩을 포함하는 전송 패킷이다. 그 경우에는, MPF 헤더가 존재하지 않는다. 전송 패킷이 복수의 MAU들로부터의 데이터를 포함하면, MPF 헤더는 각각의 MAU 앞과 각각의 단편된(부분적인) MAU 앞에 나타난다. 따라서, 이 페이로드 포맷을 이용하는 전송 패킷들은 하나 이상의 MPF 헤더들을 포함할 수 있다. MPF 헤더의 레이아웃은 도 7에 도시된다. MPF 헤더가 표준 12 바이트 RTP 헤더에 바로 후속하는 경우, "비트 필드 1"로 호칭되는 1 바이트 필드로 시작하고, 일련의 선택적인 필드들이 후속된다. 페이로드가 헤더에 후속한다. 페이로드는 완전한 MAU 또는 단편(부분적인) MAU를 포함한다.
제1 데이터 페이로드 이후, 다른 데이터 페이로드가 후속되는 다른 MPF 헤더가 나타날 수 있다. 데이터 페이로드 이후 다른 MPF 헤더를 부가하는 처리는 복수 회 반복될 수 있다. 제1 데이터 페이로드에 후속하는 각각의 MPF 헤더는 "비트 필드 2" 필드를 갖는다.
이하에서는 필드 "비트 필드 1"의 레이아웃을 설명한다.
● "송신 시간 존재(Send Time Present)" (ST) 비트: 이 비트가 1이면, "비트 필드 1" 필드의 종료에 바로 후속하여 32 비트 "송신 시간" 필드가 삽입된다.
● "대응 존재(Correspondence Present)" (CP) 비트: 이 비트가 1이면, "송신 시간" 필드 이후에 96 비트 "대응" 필드가 삽입된다.
● R1, R2, R3 (각각 1 비트): 이 비트들의 각각이 1로 설정되는 경우, 수신기는 "대응" 필드와 "비트 필드 2" 사이에 32 비트 필드가 부가된 것을 가정한다. 이 32 비트 필드들의 의미는 이 명세서에는 정의되지 않는다. 32 비트 필드들의 의미를 알지 못하는 수신기는 그들을 무시한다.
● R4, R5(각각 1 비트): 장래의 사용을 위해 보존됨; 현재 0으로 설정.
● "비트 필드 2 존재(Bit Field 2 Present)" (B2P) 비트: 이 비트가 1이면, 1 바이트 "비트 필드 2" 필드가 "대응" 필드 이후 삽입된다.
● "송신 시간(Send Time)" 필드: 32 비트. 이 필드는 RTP 헤더 내의 "타임스탬프" 필드에 대하여 사용된 동일한 시간 유닛들을 이용하여 전송 패킷의 송신 시간을 특정한다.
● "대응" 필드: 96 비트. 이 필드는 두 개의 타임스탬프들을 포함한다. NTP 포맷의 64 비트 월클럭 타임스탬프 및 32 비트 디코드 시간 타임스탬프. 상기 RFC-3550의 6.4.1 섹션에 정의되어 있는 RTCP 송신기 리포트의 "NTP 타임스탬프" 및 "RTP 타임스탬프" 필드와 동일한 방식으로 두 개의 필드들이 이용된다.
"비트 필드 1"이 존재하는 경우, "비트 필드 2"는 선택적이다. "비트 필드 1" 내의 "B2P" 비트는 "비트 필드 2"가 존재하는지 여부를 결정한다. "비트 필드 2" 내의 모든 비트들에 대한 디폴트 값은 0이다. "단편(Fragmentation)" 필드 (F)는 데이터 페이로드가 부분적인 MAU를 포함하는지 여부를 나타낸다. 하나 이상의 그러한 페이로드들이 결합되어 완전한 MAU를 재구성한다. "F" 필드는 또한 페이로드가 MAU의 처음 또는 최종 단편을 포함하는지 여부를 나타낸다. "S", "D1" 및 "D2" 비트들(아래)은 "F" 필드의 값이 0 또는 3일 때만 유효하다. 표 2는 F 필드 값의 예시적인 의미들을 도시한다.
Figure 112008010049387-PCT00002
"오프셋 존재(Offset Present)" 비트 (OP): 이 비트가 1이면, "비트 필드 2" 직후 16 비트 "오프셋" 필드가 삽입된다. "오프셋" 필드는 현재 페이로드의 종료를 찾는 데 이용된다. "비트 필드 2"로 시작하는 다른 MPF 헤더는 현재 페이로드의 종료에 후속할 수 있다. "오프셋 존재" 비트가 0이면, "오프셋" 필드는 존재하지 않으며, MPF가 RTP와 함께 사용되는 경우, 현재 페이로드는 전송 패킷의 종료까지 확장하거나 또는 RTP 헤더 내의 "패딩" 비트가 1이면 RTP 패딩 영역의 시작까지 확장한다.
"동기 포인트(Sync Point)" 비트 (S): 이 비트는 MAU가 sync-point MAU인 경우 1로 설정된다. "불연속(Discontinuity)" 비트(D1): 이 비트는 1로 설정되어 전송 패킷들의 시퀀스 번호(예를 들어, RTP가 사용되고 있다면 RTP 시퀀스 번호)가 "갭(gap)"을 나타내지 않더라도, 하나 이상의 MAU들이 소실되어 있는 것을 나타낸다. "드롭가능(Droppable)" 비트 (D2): 이 비트가 1이고, 어떤 MAU를 드롭할 필요가 있는 경우, 이 MAU는 D2 비트가 0으로 설정되게 하는 MAU들 보다 덜 부정적인 영향을 갖고 드롭될 수 있다. "암호화(Encryption)" 비트 (E): 이 비트는 1로 설정되어 페이로드가 암호화된 데이터를 포함하는 것을 나타낸다. 이 비트는 페이로드가 암호화된 데이터를 포함하지 않으면 0으로 설정되어야 한다. "비트 필드 3 존재" (B3P) 비트: 이 비트가 1이면, 1 바이트 "비트 필드 3" 필드는 "길이(Length)" 필드 이후에 삽입된다. "오프셋": "오프셋" 필드에 후속하는 첫 번째 바이트로부터 카운트하여, 현재 페이로드의 종료까지, 바이트로, 오프셋을 특정하는 16 비트 필드. 즉, "오프셋" 필드의 값은 "MAU 타이밍" 섹션의 사이즈(존재하는 경우라면)와 현재 페이로드의 사이즈의 합이다.
"비트 필드 2" 내의 "B3P" 비트의 값은 "비트 필드 3"이 존재하는지 여부를 결정한다. "비트 필드 3" 내의 모든 비트들에 대한 디폴트 값은 0이다. 도 12는 MPF의 비트 필드 3의 예시적인 레이아웃이다. "디코드 시간 존재(Decode Time Present)" 비트 (D3): 이 비트가 1이면, "비트 필드 3" 이후 그러나 "프리젠테이션 시간" 필드 이전에 32 비트 "디코드 시간" 필드가 삽입된다. "프리젠테이션 시간 존재" 비트 (P): 이 비트가 1이면, "디코드 시간" 필드 이후 그러나 "NPT" 필드 이전에 32 비트 "프리젠테이션 시간" 필드가 삽입된다. "NPT 존재" 비트 (N): 이 비트가 1이라면, "프리젠테이션 시간" 필드 직후 64 비트 "NPT" 필드가 삽입된다. R6, R7, R8, R9: 1로 설정되어 있는 이 비트들의 각각에 대하여, 수신기는 "NPT" 필드와 "확장" 필드 사이에 32 비트 필드가 부가된 것을 가정한다. 이 32 비트 필드들의 의미는 이 명세서에서는 정의되지 않는다. 32 비트 필드들의 의미를 알지 못하는 수신기는 그들을 무시한다.
"확장 존재" 비트 (X): 이 비트가 1이면, "NPT" 필드 이후 가변 사이즈 "확장" 필드가 삽입된다. "디코드 시간": 32 비트 필드. 이 필드는 MAU의 디코드 시간을 특정한다. RTP가 사용되는 경우, 이 필드는 RTP 헤더 내의 "타임스탬프 필드에 대하여 사용되는 것과 동일한 시간 유닛들을 이용하여 MAU의 디코드 시간을 특정한다. "프리젠테이션 시간": 32 비트 필드. 이 필드는 MAU의 프리젠테이션 시간을 특정한다. "NPT" 필드: 64 비트 타임스탬프. NPT 필드는 MAU가 속하는 정규 재생 시간(Normal Play Time) 타임라인 내의 위치를 지정한다.
도 13은 일 실시예에 따라, MPF 헤더의 확장 필드의 예시적인 레이아웃을 도시한다. "확장" 필드는 필드들의 하나 이상의 컬렉션들을 포함한다. 도 13은 하나의 그러한 컬렉션 내에 포함된 필드들의 레이아웃을 도시한다. "L" 비트: 이 비트가 1이면, 이것은 "확장" 필드들의 최후의 컬렉션이다. 이 비트가 0이면, "확장" 필드들의 적어도 하나 이상의 컬렉션이 "확장 데이터" 필드의 종료에 후속한다.
"확장 유형": "확장 데이터" 필드의 콘텐트들을 식별하는 데 이용되는 7 비트 필드. 또한, 값들 0 및 127이 장래의 사용을 위하여 보존된다. "확장 길이(Extension Length)": 이 필드 직후 나타나는 "확장 데이터(Extension Data)" 필드의 바이트들로 사이즈를 부여하는 8비트 수. "확장 데이터(Extension Data)": 가변 길이 필드. 이 필드의 길이는 "확장 길이" 필드에 의해 주어진다.
"확장" 필드 내의 필드들은 초기화 벡터 확장이 사용되는 경우 다음 값들을 가진다.
● "확장 유형(Extension Type)": 2이다.
● "확장 길이": "확장 데이터" 필드의 사이즈(바이트).
● "확장 데이터": 현재 MAU에 대한 초기화 벡터의 일부로서 사용될, 하나 이상의 바이트들의 시퀀스. 이 확장이 존재하는 경우, 암호화 유닛은 완전한 MAU이다. MAU가 복수의 페이로드들로 단편화되면, 초기화 벡터 확장은 제1 페이로드에만 존재한다.
"확장" 필드 내의 필드들은 Key ID 확장이 사용되는 경우 아래 값들을 가진다.
● "확장 유형": 3이다.
● "확장 길이": "확장 데이터" 필드의 사이즈(바이트).
● "확장 데이터": 현재 페이로드를 암호 해독하는 데 사용하기 위한 암호 해독 키를 식별하는 하나 이상의 바이트들의 시퀀스.
Key ID 확장은 다른 Key ID 확장으로 대체될 때까지 유효하게 유지된다. 따라서, 상기 확장은 페이로드가 이전 페이로드의 암호 해독 키와 상이한 암호 해독 키의 사용을 요구하는 경우에만 사용된다. 그러나, 소실된 전송 패킷에 이전 페이로드가 포함되어 있었다면, 수신기는 암호 해독 키의 변화가 필요한 것을 인식하지 못할 수 있다. 페이로드가 잘못된 키로 암호 해독되면, 이 상황은 검출되지 않아서, 바람직하지 못한 렌더링 아티팩트들(redering artifacts)을 야기할 수 있다.
이 문제의 심각성을 감소시키는 한 접근은 sync-point인 모든 MAU의 제1 페이로드에 대한 Key ID 확장을 특정하는 것이다. 이것은 소실된 MAU가 수신기로 하여금 다음 sync-point MAU를 수신할 때까지 모든 MAU들을 포기하도록 강제할 것이라는 점이 알려진다면 양호한 해법이다. 보다 신중한 해법은 각각의 멀티플-페이로드 전송 패킷 내의 제1 페이로드에 대한 Key ID 확장을 특정하는 것이다. 이 해법은 패킷 소실에 대하여 강건한(robust) 것인데, 그 이유는 단일의 전송 패킷 내에 상호 의존적 페이로드들이 모두 포함되어 있기 때문이다.
MPEG 비디오 헤더들이 존재하는 경우, 그들은 후속하는 프레임에 우선한다.
특히:
● MPEG Video_Sequence_Header는, 존재하는 경우, MAU의 시작에 있다.
● MPEG GOP_header는, 존재하는 경우, MAU의 시작에 있거나, 또는 Video_Sequence_Header에 후속한다.
● MPEG Picture_Header는, 존재하는 경우, MAU의 시작에 있거나, 또는 GOP_header에 후속한다.
RFC 2250과 달리, 비디오를 포함하는 MAU가 단편화된다면, 슬라이스 경계에서 단편화를 수행할 필요가 없다.
MAU들은 상이한 이유로 복수의 전송 패킷들에 걸쳐 단편화될 수 있다. 예를 들면, MAU는 전송 패킷 사이즈 제한이 존재하는 경우 및 MAU의 특정 부분들에 대한 암호화 파라미터들에서 차이가 존재하는 경우 단편화될 수 있다. RTP 헤더 필드가 해석되는 경우, RTP 헤더 내의 "타임스탬프" 필드는 90 kHz의 정확도로 샘플의 PTS로 설정되며, "페이로드 유형(Payload Type)"(PT)은 대역외 교섭 메커니즘들(예를 들면, SDP 사용)에 따라 설정된다. MPF, 패킷 특정 정보 섹션에 관하여는, "송신 시간" 필드의 존재가 선택적이고, "대응" 필드의 존재가 선택적이며,암호화되어 있는 MAU의 일부 또는 암호화되어 있는 MAU의 일 단편을 페이로드가 포함하는 경우 "비트 필드 2 존재" 비트(B2P)가 설정된다.
상기와 관련하여, MPF는 단일의 MAU가 상이한 암호화 파라미터들에 따라 암호화되는 것을 허용한다. 그것은 다른 것들이 비암호화 상태로 남을 수 있는 한편 암호화되는 단일의 MAU의 단편들을 가지는 능력을 포함한다. 그 경우, MAU는 각각 상이한 암호화 파라미터들을 갖는 복수의 페이로드들로 단편화될 수 있다. 예를 들어, 암호화되는 MAU 또는 MAU의 단편은 아래 기준에 따라 설정된 값들 및 필드들을 갖는다.
● 패킷 정보 섹션(Packet Info section) 내의 "비트 필드 2 존재" 비트(B2P)는 1로 설정되어, "비트 필드 2"가 존재하는 것을 나타낸다.
● MAU 속성 섹션(MAU Properties section) 내의 "암호화" 비트(E)는 1로 설정되어, 페이로드가 암호화되는 것을 나타낸다.
● "MAU 타이밍" 섹션 내의 "확장 존재(Extension Present)" 비트(X)는 1로 설정되어, 확장 필드들의 존재를 나타낸다.
● "초기화 벡터" 확장이 포함된다. 다음의 값들이 설정된다:
○ "확장 유형"은 2로 설정된다.
○ "확장 길이"는 "확장 데이터" 필드가 데이터 세그먼트 ID만 포함한다면 8(64 비트를 의미)로 설정되거나, "확장 데이터" 필드가 데이터 세그먼트 ID 및 블럭 ID를 모두 포함한다면 16(128 비트를 의미)으로 설정된다.
○ "확장 데이터"는 초기 블럭 ID가 0인 경우 상기한 바와 같이 데이터 세그먼트 ID 값으로 설정된다. 초기 블럭 ID가 0과 다르다면, "확장 데이터"는 초기 블럭 ID가 후속하는 데이터 세그먼트 ID로 설정된다.
○ 이 확장은 MAU의 각각의 암호화된 페이로드에 대하여 포함된다.
● "Key ID" 확장이 포함된다. 다음의 값들이 설정된다:
○ "확장 유형"은 3으로 설정된다.
○ "확장 길이"는 16(128 비트를 의미)으로 설정된다.
○ "확장 데이터"는 이 MAU에 대응하는 라이센스로부터 Key ID 값으로 설정된다.
복수의 MAU들을 포함하는 각각의 복수의 페이로드 전송 패킷 내의 새로운 MAU의 제1 페이로드를 위하여 "초기화 벡터(Initial Vector)" 및 "Key ID" 확장들이 포함된다. 이것은 어떤 전송 패킷들이 소실되더라도 수신기가 현재 Key ID에 대하여 알고 있는 것을 확실히 한다.
MAU 속성 섹션은 아래와 같이 해석된다:
● "Sync Point" 비트 (S)는 MAU가 비디오 I-프레임 또는 오디오 프레임을 포함하는 경우 설정된다.
● "불연속" 비트 (D1)는 하나 이상의 MAU들이 소실되어 있는 경우 설정된다. 예를 들면, 프레임 드롭핑 변환기(frame dropping translator)에 의해 드롭된 경우.
● "드롭 가능(Droppable)" 비트(D2)의 이용은 선택적이다. 어떤 경우에 이용되어야 하는지를 정하는 것은 본 명세서의 범위 밖이다.
● "암호화" 비트 (E)는 암호화되어 있는 MAU의 일부, 또는 암호화되어 있는 MAU의 단편을 페이로드가 포함하는 경우 설정된다.
MAU 타이밍 섹션은 아래와 같이 해석된다.
● "디코드 시간" 필드는 선택적이다. 사용되면, MAU의 DTS를 포함한다.
● "프리젠테이션 시간" 필드는 선택적이다.
● "NPT" 필드는 선택적이다.
○ "확장 존재" 비트 (X)는 하나 이상의 확장 헤더들이 존재하는 경우 설정된다.
예시적인 절차들
도 14는 일 실시예에 따라, ES 콘텐트를 보호하는 예시적인 절차(1400)을 도시한다. 예시적인 목적으로, 절차(1400)의 동작들은 도 1의 ES 보호 모듈(112), 맵핑 모듈(114), 도 2의 전송 스트림 스크램블링 모듈(210), 및/또는 디멀티플렉싱 및 패키징 모듈(212) 중 하나 이상에 의하여 수행된다. 행위들(actions)의 순서에 대한 변경 및 수정을 포함하여, 다양한 변경들 및 수정들은 본 명세서로부터 당업자에게는 자명할 것이다.
도 14를 참조하면, 블럭(1405)에서, ES들(elementary streams)이 수신되거나 컴퓨팅 장치(102) 또는 콘텐트 소스(202)에 의해 액세스된다. 액세스된 ES들은 전송 스트림과는 독립적일 수 있거나, 전송 스트림에 의해 전달될 수 있다. 블럭(1410)에서, 절차(1400)는 ES들의 MAU 부분들을 보호한다. 일 실시예에서, 이 보호 동작들은, 통상의 스크램블링과는 독립적으로 수행된다. 다른 실시예에서, 예를 들어,전송 스트림을 통상 스크램블링하는 경우, 이 보호 동작들은 통상 스크램블링을 이용하여 수행된다. 블럭(1415)에서, 블럭(1405)에서 전송 스트림이 액세스되었다면, 원래의 암호화가 유지되도록 전송 스트림이 ES들로 디멀티플렉스된다. 모듈(212)의 디멀티플렉싱 동작들은 전송 스트림 디멀티플렉싱 동작들을 수행하기 위한 예시적 컴포넌트를 도시한다.
블럭(1420)에서, 절차(1400)는 피보호 ES들을 MAU 페이로드 포맷(MPF)으로 맵핑한다. 각각의 MAU를 MPF로 맵핑하는 것은 맵핑된 ES들을 캡슐화하는 전송 패킷들을 수신하는 미디어 소비자에게 임의의 다른 ES와는 독립적으로 각각의 ES를 처리하고, 각각의 MAU를 임의의 다른 MAU와는 독립적으로 각각의 MAU를 처리하도록 하기 위한 충분한 정보를 제공한다. 블럭(1430)에서, 절차(1400)는 MPF로 맵핑된 ES들을 전송 프로토콜에 캡슐화한다. 일 실시예에서, 전송 프로토콜은 RTP(Real-Time Transport Protocol)이다. 블럭(1440)에서, 절차(1400)는 프로세싱을 위하여 전송 프로토콜에 기초하여 전송 패킷들을 미디어 소비자에게 통신한다. 암호 해독을 포함하는 이러한 프로세싱은 미디어 소비자가 전송 패킷들 내에 포함된 페이로드 데이터를 경험하도록 한다.
결론
ES 콘텐트를 보호하는 것이 구조적 특징들 및/또는 방법적인 동작들 또는 행위들 특유의 언어로 설명되었지만, 첨부된 청구범위에 정의된 실시예들은 설명된 특정의 특징들 또는 행위들로 한정되지 않는 점이 이해된다. 오히려, 특정의 특징들 및 동작들은 청구물을 구현하는 예시적인 형태로서 개시된다.

Claims (20)

  1. 각각이 단일 비디오 또는 오디오 프레임을 포함하는, 기초 스트림 콘텐트의 데이터 세그먼트들을 식별하는 단계;
    상기 기초 스트림 콘텐트의 보호를 위해 상기 데이터 세그먼트들에 대응하는 암호화 경계들을 선택하는 단계; 및
    상기 암호화 경계들을 이용하여 상기 기초 스트림 콘텐트를 보호하는 단계
    를 포함하는 컴퓨터 구현 방법.
  2. 제1항에 있어서, 상기 기초 스트림 콘텐트는 전송 스트림에 의하여 전달되는 방법.
  3. 제1항에 있어서, 상기 보호하는 단계는 카운터 모드의 AES(Advanced Encryption Standard in Counter Mode)로 상기 데이터 세그먼트들의 각각을 암호화하는 단계를 더 포함하는 방법.
  4. 제1항에 있어서, 상기 보호하는 단계는 전송 스트림을 분석하여 암호화되지 않은 상태로 전달할 상기 전송 스트림의 부분들을 결정하는 단계를 더 포함하며,
    상기 보호하는 단계는 상기 전송 스트림의 통상 스크램블링된 부분들을 바이패스하는 처리에 대하여 상기 전송 스트림을 준비시키는 단계를 더 포함하는 방법.
  5. 제1항에 있어서, 상기 기초 스트림 콘텐트의 기초 스트림은 MAU들(Media Access Units)을 포함하며, 상기 보호하는 단계는,
    상기 MAU들의 각각에 대하여, 그 MAU와 연관된 하나 이상의 데이터 세그먼트들의 각각에 암호화 파라미터들의 각각의 세트를 적용시키는 단계 - 상기 각각의 암호화 파라미터들은 데이터 세그먼트를 암호화하거나 데이터 세그먼트를 비암호화 상태에 두어 상기 암호화 파라미터들의 각각의 세트들이 각각의 별개의 데이터 세그먼트에 적용되게 함 - 를 더 포함하는 방법.
  6. 제5항에 있어서, 각각의 데이터 세그먼트는 상기 MAU의 연속적인 섹션인 방법.
  7. 제5항에 있어서, 상기 MAU의 일 부분은 비암호화 상태로 남겨지는 방법.
  8. 제5항에 있어서, 상기 전송 프로토콜은 RTP(Real-Time Transport Protocol)인 방법.
  9. 제5항에 있어서, 전송 프로토콜로의 캡슐화를 위하여 상기 MAU들을 MAU 페이로드 포맷으로 맵핑하는 단계를 더 포함하는 방법.
  10. 제9항에 있어서, 상기 MAU 페이로드 포맷은 상기 MAU들의 각각에 연관된 패킷 특정 정보를 포함하는 방법.
  11. 제9항에 있어서, 상기 MAU 페이로드 포맷은 상기 MAU들 중 특정의 MAU를 서술하기 위한 MAU 속성부를 더 포함하며,
    상기 MAU가 단편화되어 있다면, 상기 속성부는 상기 MAU의 단편화된 부분이 소실되는 경우 수신기가 상기 MAU를 파스(parse)하도록 하는 정보를 포함하는 방법.
  12. 제9항에 있어서, 상기 MAU 페이로드 포맷은 상기 MAU들 중 한 MAU와 연관된 타임스탬프들에 관한 정보를 제공하기 위한 MAU 타이밍부를 포함하는 방법.
  13. 제12항에 있어서, 상기 정보는 상기 MAU와 연관된 NPT(Normal Play Time) 타임라인을 포함하며, 상기 NPT는 수신기가 프리젠테이션 내에서 검색할 위치를 특정하는 것을 돕는 방법.
  14. 제12항에 있어서, 상기 정보는 상기 수신기가 언제 상기 MAU의 콘텐트를 제시하는 지를 나타내는 프리젠테이션 시간을 포함하는 방법.
  15. 기초 스트림(ES)의 암호화 부분들을 수신하는 단계 - 상기 ES는 복수의 MAU 들로 표현되고, 각각의 MAU는 상기 ES의 비디오 또는 오디오의 단일 프레임에 대응하고, 상기 ES는 상기 ES가 임의의 다른 ES와는 독립적으로 처리되도록 하는 정보와 연관되며, 각각의 MAU는 상기 MAU가 임의의 다른 MAU와는 독립적으로 처리되도록 하는 정보와 연관됨 - ; 및
    상기 ES 또는 상기 MAU들 중 적어도 하나의 MAU를 처리하는 단계
    를 포함하는 컴퓨터 구현 방법.
  16. 제15항에 있어서, 상기 기초 스트림은 통상 스크램블링된 전송 스트림에 의해 전달되는 방법.
  17. 제15항에 있어서, 상기 ES는 RTP 패킷들에 의해 캡슐화되는 방법.
  18. 제15항에 있어서, 상기 기초 스트림은 전송 스트림에 의해 전달되고, 상기 처리하는 단계는 상기 전송 스트림을 디멀티플렉싱하여 기초 스트림들을 도출하는 단계를 더 포함하는 방법.
  19. 기초 스트림 콘텐트의 MAU들을 식별하는 단계;
    단일의 비디오 또는 오디오 프레임을 나타내는 하나 이상의 데이터 세그먼트들을 포함하는 MAU들의 각각에 대하여, 단일의 비디오 또는 오디오 프레임 및 연관된 헤더들의 보호를 위해 하나 이상의 데이터 세그먼트들에 기초하여 암호화 경계 들을 선택하는 단계; 및
    각각의 데이터 세그먼트가 다른 데이터 세그먼트의 대응하는 암호화 파라미터들과는 독립적인 암호화 파라미터들의 각각의 세트와 연관되도록 상기 암호화 경계들에 기초하여 상기 기초 스트림 콘텐트를 보호하는 단계
    를 포함하는 컴퓨터 구현 방법.
  20. 제19항에 있어서, 상기 기초 스트림 콘텐트는 전송 스트림에 의해 전달되며, 상기 보호하는 단계는 암호화된 콘텐트를 바이패스하는 처리에 대하여 상기 전송 스트림을 준비하도록 상기 전송 스트림을 통상적으로 스크램블링하는 단계를 더 포함하는 방법.
KR1020087003328A 2005-08-12 2006-08-10 기초 스트림 콘텐트 보호 KR20080033387A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/202,836 US20060036551A1 (en) 2004-03-26 2005-08-12 Protecting elementary stream content
US11/202,836 2005-08-12

Publications (1)

Publication Number Publication Date
KR20080033387A true KR20080033387A (ko) 2008-04-16

Family

ID=37757897

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020087003328A KR20080033387A (ko) 2005-08-12 2006-08-10 기초 스트림 콘텐트 보호

Country Status (9)

Country Link
US (1) US20060036551A1 (ko)
EP (1) EP1913727A1 (ko)
JP (1) JP2009505515A (ko)
KR (1) KR20080033387A (ko)
CN (1) CN101243640A (ko)
BR (1) BRPI0614765A2 (ko)
MX (1) MX2008001857A (ko)
RU (1) RU2008105041A (ko)
WO (1) WO2007022033A1 (ko)

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8875199B2 (en) * 2006-11-13 2014-10-28 Cisco Technology, Inc. Indicating picture usefulness for playback optimization
US20080115175A1 (en) * 2006-11-13 2008-05-15 Rodriguez Arturo A System and method for signaling characteristics of pictures' interdependencies
US20090180546A1 (en) * 2008-01-09 2009-07-16 Rodriguez Arturo A Assistance for processing pictures in concatenated video streams
US8023973B2 (en) * 2007-01-03 2011-09-20 Motorola Solutions, Inc. Expandable text messaging service protocol for use with a two-way radio transceiver
US7936873B2 (en) 2007-05-07 2011-05-03 Apple Inc. Secure distribution of content using decryption keys
US8804845B2 (en) * 2007-07-31 2014-08-12 Cisco Technology, Inc. Non-enhancing media redundancy coding for mitigating transmission impairments
US8958486B2 (en) * 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
EP2213097A2 (en) * 2007-10-16 2010-08-04 Cisco Technology, Inc. Conveyance of concatenation properties and picture orderness in a video stream
US8155090B2 (en) * 2007-11-01 2012-04-10 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for efficient multimedia delivery in a wireless packet network
US8718388B2 (en) * 2007-12-11 2014-05-06 Cisco Technology, Inc. Video processing with tiered interdependencies of pictures
US9892390B2 (en) * 2007-12-12 2018-02-13 Microsoft Technology Licensing, Llc Digital content packaging, licensing and consumption
US20100316001A1 (en) * 2008-02-05 2010-12-16 Telefonaktiebolaget Lm Ericsson (Publ) Method of Transmitting Synchronized Speech and Video
WO2009152450A1 (en) 2008-06-12 2009-12-17 Cisco Technology, Inc. Picture interdependencies signals in context of mmco to assist stream manipulation
US8971402B2 (en) 2008-06-17 2015-03-03 Cisco Technology, Inc. Processing of impaired and incomplete multi-latticed video streams
US8705631B2 (en) * 2008-06-17 2014-04-22 Cisco Technology, Inc. Time-shifted transport of multi-latticed video for resiliency from burst-error effects
US8699578B2 (en) 2008-06-17 2014-04-15 Cisco Technology, Inc. Methods and systems for processing multi-latticed video streams
WO2009158550A2 (en) * 2008-06-25 2009-12-30 Cisco Technology, Inc. Support for blocking trick mode operations
US8422679B2 (en) * 2008-10-17 2013-04-16 Motorola Solutions, Inc. Method and device for sending encryption parameters
US20100218232A1 (en) * 2009-02-25 2010-08-26 Cisco Technology, Inc. Signalling of auxiliary information that assists processing of video according to various formats
US8782261B1 (en) * 2009-04-03 2014-07-15 Cisco Technology, Inc. System and method for authorization of segment boundary notifications
US8949883B2 (en) 2009-05-12 2015-02-03 Cisco Technology, Inc. Signalling buffer characteristics for splicing operations of video streams
US8279926B2 (en) 2009-06-18 2012-10-02 Cisco Technology, Inc. Dynamic streaming with latticed representations of video
US9185335B2 (en) * 2009-12-28 2015-11-10 Thomson Licensing Method and device for reception of video contents and services broadcast with prior transmission of data
US9160978B2 (en) * 2010-08-10 2015-10-13 Google Technology Holdings LLC Method and apparatus related to variable duration media segments
CN102469344B (zh) * 2010-11-16 2013-10-09 腾讯科技（深圳）有限公司 一种视频码流加、解密方法、装置及通信、存储终端
KR20120084237A (ko) 2011-01-19 2012-07-27 삼성전자주식회사 엠엠티(ｍｍｔ)에서 엠엠티 인캡슐레이터를 전송하는 방법
CN102737678B (zh) * 2011-04-12 2016-12-07 上海广茂达光艺科技股份有限公司 一种灯光场景多媒体文件格式及其存储、同步播放方法
JP5148765B1 (ja) * 2011-09-06 2013-02-20 株式会社東芝 情報処理装置及び情報処理方法
US9467424B2 (en) * 2011-10-07 2016-10-11 Salesforce.Com, Inc. Methods and systems for proxying data
US9088805B2 (en) * 2012-02-08 2015-07-21 Vixs Systems, Inc. Encrypted memory device and methods for use therewith
KR20140008237A (ko) * 2012-07-10 2014-01-21 한국전자통신연구원 엠엠티의 하이브리드 전송 서비스에서 패킷 전송 및 수신 장치 및 방법
US9197568B2 (en) * 2012-10-22 2015-11-24 Electronics And Telecommunications Research Institute Method for providing quality of service in software-defined networking based network and apparatus using the same
US10237354B2 (en) * 2014-09-25 2019-03-19 Intel Corporation Technologies for offloading a virtual service endpoint to a network interface card
CN108322778B (zh) * 2018-02-09 2020-11-20 珠海迈科智能科技股份有限公司 一种提升dvb数据流加扰速度的方法及装置
CN108322811A (zh) * 2018-02-26 2018-07-24 宝鸡文理学院 一种钢琴视频教学中的同步方法及系统
CN110213669B (zh) * 2019-05-18 2021-03-23 杭州当虹科技股份有限公司 一种基于ts切片的视频内容防盗系统和方法

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5420866A (en) * 1994-03-29 1995-05-30 Scientific-Atlanta, Inc. Methods for providing conditional access information to decoders in a packet-based multiplexed communications system
US5684876A (en) * 1995-11-15 1997-11-04 Scientific-Atlanta, Inc. Apparatus and method for cipher stealing when encrypting MPEG transport packets
US7809138B2 (en) * 1999-03-16 2010-10-05 Intertrust Technologies Corporation Methods and apparatus for persistent control and protection of content
BR9906523A (pt) * 1998-06-11 2000-07-25 Koninkl Philips Electonics N V Aparelho e processo para gravar um sinal de informação de vìdeo digital em um portador de gravação, e, portador de gravação
US6256071B1 (en) * 1998-12-11 2001-07-03 Hitachi America, Ltd. Methods and apparatus for recording video files and for generating a table listing the recorded files and links to additional information
US7058803B2 (en) * 2002-05-22 2006-06-06 Broadcom Corporation System and method for protecting transport stream content
US6941459B1 (en) * 1999-10-21 2005-09-06 International Business Machines Corporation Selective data encryption using style sheet processing for decryption by a key recovery agent
US6931532B1 (en) * 1999-10-21 2005-08-16 International Business Machines Corporation Selective data encryption using style sheet processing
US6961849B1 (en) * 1999-10-21 2005-11-01 International Business Machines Corporation Selective data encryption using style sheet processing for decryption by a group clerk
US6654389B1 (en) * 1999-11-23 2003-11-25 International Business Machines Corporation System and method for searching patterns in real-time over a shared media
CN1239021C (zh) * 2000-04-21 2006-01-25 索尼公司 信息处理设备及方法、程序和记录介质
US7165175B1 (en) * 2000-09-06 2007-01-16 Widevine Technologies, Inc. Apparatus, system and method for selectively encrypting different portions of data sent over a network
US6959090B1 (en) * 2000-11-20 2005-10-25 Nokia Corporation Content Protection scheme for a digital recording device
JP2002197794A (ja) * 2000-12-25 2002-07-12 Toshiba Corp 音声映像データ同期再生方法
US7127619B2 (en) * 2001-06-06 2006-10-24 Sony Corporation Decoding and decryption of partially encrypted information
JP4291525B2 (ja) * 2001-07-31 2009-07-08 日本放送協会 スクランブル方法、送信方法、送信装置、及び受信機
US7242766B1 (en) * 2001-11-21 2007-07-10 Silicon Image, Inc. Method and system for encrypting and decrypting data using an external agent
KR100927322B1 (ko) * 2001-12-19 2009-11-19 이르데토 액세스 비.브이. 디지털 콘텐트 분배 시스템
US7233669B2 (en) * 2002-01-02 2007-06-19 Sony Corporation Selective encryption to enable multiple decryption keys
US7231516B1 (en) * 2002-04-11 2007-06-12 General Instrument Corporation Networked digital video recording system with copy protection and random access playback
US7061942B2 (en) * 2002-05-31 2006-06-13 Skystream Networks Inc. Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
US7702101B2 (en) * 2002-07-09 2010-04-20 Kaleidescape, Inc. Secure presentation of media streams in response to encrypted digital content
US8015584B2 (en) * 2002-10-18 2011-09-06 Seachange International, Inc. Delivering interactive content to a remote subscriber
AU2003295519A1 (en) * 2002-11-13 2004-06-03 General Instrument Corporation Efficient distribution of encrypted content for multiple content access systems
US7298741B2 (en) * 2003-02-27 2007-11-20 Sharp Laboratories Of America, Inc. Robust MPEG-2 multiplexing system and method using an adjustable time stamp
US7483532B2 (en) * 2003-07-03 2009-01-27 Microsoft Corporation RTP payload format

Also Published As

Publication number Publication date
WO2007022033A1 (en) 2007-02-22
EP1913727A1 (en) 2008-04-23
JP2009505515A (ja) 2009-02-05
US20060036551A1 (en) 2006-02-16
MX2008001857A (es) 2008-04-14
BRPI0614765A2 (pt) 2011-04-12
RU2008105041A (ru) 2009-08-20
CN101243640A (zh) 2008-08-13

Similar Documents

Publication Publication Date Title
US20060036551A1 (en) Protecting elementary stream content
US20060184790A1 (en) Protecting elementary stream content
US7636439B2 (en) Encryption method, encryption apparatus, data storage distribution apparatus and data delivery system
US7356147B2 (en) Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient
US8135949B2 (en) Digital content distribution
US8755524B2 (en) Motion picture file encryption method and digital rights management method using the same
US8949592B2 (en) System and methods for providing live streaming content using digital rights management-based key management
JP4188958B2 (ja) 暗号化方法及びデータ配信システム及び暗号化装置及びデータ蓄積配信装置
US7447313B2 (en) Pointers to encrypted data in RTP header
EP2540054B1 (en) Play-out control for a media data stream
US20190246148A1 (en) Method and system for scrambling broadcast with low latency
EP1499061A1 (en) Individual video encryption system and method
KR100840200B1 (ko) Ｈ.２６４ 형식의 동영상 파일의 보호를 위한패키징/언패키징 장치 및 그 방법
EP2685737B1 (en) Method and device for allowing seamlessly switching from one layer to another in a conditional access system context
EP1499062A1 (en) Individual video encryption system and method
AU2004224936A1 (en) Encryption of MPEG Bitstreams

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid