KR20160025603A - 방송 신호 송/수신 처리 방법 및 장치 - Google Patents

방송 신호 송/수신 처리 방법 및 장치 Download PDF

Info

Publication number
KR20160025603A
KR20160025603A KR1020167002411A KR20167002411A KR20160025603A KR 20160025603 A KR20160025603 A KR 20160025603A KR 1020167002411 A KR1020167002411 A KR 1020167002411A KR 20167002411 A KR20167002411 A KR 20167002411A KR 20160025603 A KR20160025603 A KR 20160025603A
Authority
KR
South Korea
Prior art keywords
delivery
attribute
fec
delivery object
route
Prior art date
Application number
KR1020167002411A
Other languages
English (en)
Other versions
KR101757306B1 (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
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of KR20160025603A publication Critical patent/KR20160025603A/ko
Application granted granted Critical
Publication of KR101757306B1 publication Critical patent/KR101757306B1/ko

Links

Images

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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • 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
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • 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
    • 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/21—Server components or server architectures
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • 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
    • 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/232—Content retrieval operation locally within server, e.g. reading video streams from disk arrays
    • 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/233—Processing of audio elementary streams
    • 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
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • 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/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
    • H04N21/23611—Insertion of stuffing data into a multiplex stream, e.g. to obtain a constant bitrate
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • 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 
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Library & Information Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

방송 송신 장치는 서비스의 적어도 하나의 콘텐트 컴포넌트에 포함되며, 독립적으로 복원되는(recovered individually) 적어도 하나의 딜리버리 오브젝트를 생성하는 딜리버리 오브젝트 제너레이터(Delivery Object Generator); 상기 서비스 및 상기 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 생성하는 시그널링 정보 제너레이터(시그널링 정보 Generator); 및 상기 적어도 하나의 딜리버리 오브젝트 및 상기 시그널링 정보를 단방향 채널(unidirectional channel)을 통해서 전송하는 트랜스미터(Transmitter)를 포함한다.

Description

방송 신호 송/수신 처리 방법 및 장치 {APPARATUS AND METHOD FOR TRANSMITTING/RECEIVING PROCESSES OF A BROADCAST SIGNAL}
본 발명은 미디어 신호를 전송/수신하는 방법 및 장치에 관한 것이다. 보다 상세하게는, 본 발명은 브로드밴드 (broadband)와 브로드캐스트 (broadcast) 가 결합된 방송 시스템에서, 브로드밴드와 브로드캐스트로 각각 전송되는 미디어에 대한 데이터를 처리하는 방법 및 장치에 관한 것이다.
아날로그 방송 신호 송신이 종료됨에 따라, 디지털 방송 신호를 송수신하기 위한 다양한 기술이 개발되고 있다. 디지털 방송 신호는 아날로그 방송 신호에 비해 더 많은 양의 비디오/오디오 데이터를 포함할 수 있고, 비디오/오디오 데이터뿐만 아니라 다양한 종류의 부가 데이터를 더 포함할 수 있다.
본 발명이 이루고자 하는 기술적 과제는, 전술한 문제점을 해결하기 위한 것으로, 하이브리드 방송 시스템에서는 기존의 방송망을 통하여 데이터가 전송되는 방식과 브로드밴드망을 통하여 데이터가 전송되는 방식이 공존하므로, 이들 데이터를 처리하는 적절한 방법 및 장치를 제공하는 것에 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 방송 송신 장치는, 서비스의 콘텐트 컴포넌트에 포함되고 독립적으로 복원되는(recovered individually) 적어도 하나의 딜리버리 오브젝트(Delivery Object)를 생성하는 딜리버리 오브젝트 제너레이터 (delivery object generator); 상기 서비스 및 상기 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 생성하는 시그널링 정보 제너레이터(signaling information generator); 및 상기 적어도 하나의 딜리버리 오브젝트 및 상기 시그널링 정보를 단방향 채널(unidirectional channel)을 통해서 전송하는 트랜스미터(transmitter)를 포함할 수 있다.
바람직하게는, 상기 딜리버리 오브젝트는, 파일, 상기 파일의 일부분, 상기 파일의 그룹, HTTP (Hyper Text Transfer Protocol) 엔티티(Entity) 및 상기 HTTP 엔티티 중 하나이다.
바람직하게는, 상기 시그널링 정보는 상기 서비스의 상기 콘텐트 컴포넌트를 전송하는 전송 세션(transport session)을 기술하는 제 1 정보를 포함한다.
바람직하게는, 상기 제 1 정보는 상기 전송 세션에서 전송된 소스 데이터를 기술하는 제 2 정보를 포함한다.
바람직하게는,상기 제 2 정보, 상기 파일 전달 데이터의 세부 내용을 지정하는 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성(attribute), 상기 딜리버리 오브젝트가 실시간으로 전달되는 지를 지시하는 realtime 속성, 수신기에 저장될 필요가 있는 데이터의 최대 양을 정의하는 minBufferSize, 애플리케이션에 매핑될 수 있는 정보를 제공하는 ApplicationIdentifier 엘리먼트, 및/또는 상기 딜리버리 오브젝트를 나르는 패킷의 페이로드 포팻(payload format)을 정의하는 PayloadFormat 엘리먼트 중 적어도 하나를 포함한다.
바람직하게는, 상기 PayloadFormat 엘리먼트는, CodePoint 값이 페이로드를 위해 사용되는 것을 정의하는 codePoint 속성, 딜리버리 오브젝트의 상기 페이로드 포맷을 지정하는 deliveryObjectFormat 속성, 상기 딜리버리 오브젝트의 단위를 지시하는 fragmentation 속성, 상기 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전달 순서를 지시하는 deliveryOrder 속성, Source FEC Payload ID의 포맷을 정의하는 sourceFecPayloadID 속성 및 FEC 파라미터들을 정의하는 FECParamenters 엘리먼트 중 적어도 하나를 포함한다.
바람직하게는, 상기 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성, 상기 EFDT 엘리먼트의 버전을 식별하는 version 속성, 상기 전송 세션 내의 오브젝트에 대한 최대 만료 시간을 지시하는 maxExpiresDelta 속성, 상기 EFDT 엘리먼트에 의해 기술되는 오브젝트의 최대 전송 크기(maximum transport size)를 지시하는 maxTransportSize 속성 및 파일 URL을 지정하는 FileTemplate 엘리먼트 중 적어도 하나를 포함한다.
기술적 과제를 해결하기 위하여 본 발명의 또 다른 실시예에 따른 방송 수신 장치는, 서비스를 포함하는 방송 신호를 단방향 채널(unidirectional channel)을 통해서 수신하는 브로드캐스트 인터페이스(broadcast interface); 상기 서비스 및 상기 서비스의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출하는 시그널링 파서(signaling parser); 및 상기 시그널링 정보에 기초하여 적어도 하나의 딜리버리 오브젝트(Delivery Object)를 복원하는 딜리버리 오브젝트 프로세서를 포함할 수 있다.
바람직하게는, 상기 딜리버리 오브젝트는, 파일, 상기 파일의 일부분, 상기 파일의 그룹, HTTP (Hyper Text Transfer Protocol) 엔티티(Entity) 및 상기 HTTP 엔티티 중 하나이다.
바람직하게는, 상기 시그널링 정보는 상기 서비스의 상기 콘텐트 컴포넌트를 전송하는 전송 세션(transport session)을 기술하는 제 1 정보를 포함한다.
바람직하게는, 상기 제 1 정보는 상기 전송 세션에서 전송된 소스 데이터를 기술하는 제 2 정보를 포함한다.
바람직하게는, 상기 제 2 정보, 상기 파일 전달 데이터의 세부 내용을 지정하는 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성(attribute), 상기 딜리버리 오브젝트가 실시간으로 전달되는 지를 지시하는 realtime 속성, 리시버(receiver)에 저장될 필요가 있는 데이터의 최대 양을 정의하는 minBufferSize, 애플리케이션에 매핑될 수 있는 정보를 제공하는 ApplicationIdentifier 엘리먼트, 및/또는 상기 딜리버리 오브젝트를 나르는 패킷의 페이로드 포팻(payload format)을 정의하는 PayloadFormat 엘리먼트 중 적어도 하나를 포함한다.
바람직하게는, 상기 PayloadFormat 엘리먼트는, CodePoint 값이 페이로드를 위해 사용되는 것을 정의하는 codePoint 속성, 딜리버리 오브젝트의 상기 페이로드 포맷을 지정하는 deliveryObjectFormat 속성, 상기 딜리버리 오브젝트의 단위를 지시하는 fragmentation 속성, 상기 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전달 순서를 지시하는 deliveryOrder 속성, Source FEC Payload ID의 포맷을 정의하는 sourceFecPayloadID 속성 및 FEC 파라미터들을 정의하는 FECParamenters 엘리먼트 중 적어도 하나를 포함한다.
바람직하게는, 상기 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성, 상기 EFDT 엘리먼트의 버전을 식별하는 version 속성, 상기 전송 세션 내의 오브젝트에 대한 최대 만료 시간을 지시하는 maxExpiresDelta 속성, 상기 EFDT 엘리먼트에 의해 기술되는 오브젝트의 최대 전송 크기(maximum transport size)를 지시하는 maxTransportSize 속성 및 파일 URL을 지정하는 FileTemplate 엘리먼트 중 적어도 하나를 포함한다.
발명의 일 실시예에 따른 방송 신호 송신 장치는 멀티미디어 콘텐츠를 전송하는데 걸리는 전송 대기 시간을 줄일 수 있는 효과가 있다.
또한, 본 발명의 일 실시예에 따른 방송 신호 수신 장치는 멀티미디어 콘텐츠를 재생하는데 걸리는 재생 대기 시간을 줄일 수 있는 효과가 있다.
또한, 본 발명의 일 실시예에 따르면, 멀티미디어 콘텐츠의 획득에서부터 사용자에게 보여지기까지의 총 시간을 줄일 수 있는 효과가 있다.
또한, 본 발명의 일 실시예에 따르면, 사용자가 방송 채널에 접근하였을 때의 초기 지연시간을 줄일 수 있는 효과가 있다.
또한, 본 발명의 일 실시예에 따르면, MPEG-DASH Media Segment file들을 실시간으로 전송 및/또는 수신할 수 있다.
도 1는 본 발명의 일 실시예에 따른 방송 시스템을 나타낸 도면이다.
도 2는 본 발명의 일 실시예에 따른 ROUTE 프로토콜 스택을 도시한 도면이다.
도 3는 본 발명의 일 실시예에 따른 방송 시스템을 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 ROUTE Protocol의 방송 송신 장치의 동작을 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 LSID를 나타낸 도면이다.
도 6은 본 발명의 일 실시예에 따른 SourceFlow Element를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른 딜리버리 오브젝트의 포맷을 나타낸 도면이다.
도 8은 본 발명의 일 실시예에 따른 파일 모드에서 ROUTE Distribution과 FLUTE Distribution의 비교를 나타낸 도면이다.
도 9는 본 발명의 일 실시예에 따른 EFDT를 나타낸 도면이다.
도 10은 본 발명의 일 실시예에 따른 File templates에 대한 식별자들을 나타낸 도면이다.
도 11은 본 발명의 일 실시예에 따른 ROUTE Packet Format을 나타낸 도면이다.
도 12는 본 발명의 일 실시예에 따른 EXT_PRESENTATION_TIME Header를 나타낸 도면이다.
도 13은 본 발명의 일 실시예에 따른 방송 송신 장치의 흐름도를 나타낸 도면이다.
도 14는 본 발명의 일 실시예에 따른 방송 수신 장치를 나타낸 도면이다.
도 15는 본 발명의 일 실시예에 따른 방송 수신 장치의 흐름도를 나타낸 도면이다.
도 16은 본 발명의 일 실시예에 따른 방송 수신 장치의 FEC 패킷 생성을 나타낸 도면이다.
도 17은 본 발명의 일 실시예에 따른 FEC Transport Object를 나타낸 도면이다.
도 18은 본 발명의 일 실시예에 따른 EXT_TOL Header를 나타낸 도면이다.
도 19는 본 발명의 일 실시예에 따른 RepairFlow Element를 나타낸 도면이다.
도 20은 본 발명의 일 실시예에 따른 ProtectedObject Element를 나타낸 도면이다.
도 21은 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도 22는 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도 23은 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도 24는 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도 25는 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도 26는 본 발명의 일 실시예에 따른 방송 수신 장치를 나타낸 도면이다.
도 27는 본 발명의 일 실시예에 따른 MPD를 나타낸 도면이다.
도 28는 본 발명의 일 실시예에 따른 URI Form을 나타낸 도면이다.
도 29는 본 발명의 일 실시예에 따른 URI Form을 나타낸 도면이다.
도 30은 본 발명의 일 실시예에 따른 Parameters for MP4 Fragment identifiers을 나타낸 도면이다.
도 31은 본 발명의 일 실시예에 따른 수신기의 동작을 나타낸 도면이다.
이하 첨부 도면들 및 첨부 도면들에 기재된 내용들을 참조하여 본 발명의 실시예를 상세하게 설명하지만, 본 발명이 실시예들에 의해 제한되거나 한정되는 것은 아니다.
본 명세서에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 가지는 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다.
본 명세서에서 ‘시그널링 (signaling)’ 이라 함은 방송 시스템, 인터넷 방송 시스템 및/또는 방송/인터넷 융합 시스템에서 제공되는 서비스 정보 (Service Information; SI)를 전송/수신하는 것을 나타낸다. 서비스 정보는 현재 존재하는 각 방송 시스템에서 제공되는 방송 서비스 정보 (예를 들면, ATSC-SI 및/또는 DVB-SI)를 포함한다.
본 명세서에서 ‘방송 신호’ 라 함은, 지상파 방송, 케이블 방송, 위성 방송, 및/또는 모바일 방송 이외에도, 인터넷 방송, 브로드밴드 방송, 통신 방송, 데이터 방송 및/또는 VOD (Video On Demand) 등의 양방향 방송에서 제공되는 신호 및/또는 데이터를 포함하는 개념으로 정의한다.
본 명세서에서 ‘PLP’ 라 함은, 물리적 계층에 속하는 데이터를 전송하는 일정한 유닛을 의미한다. 따라서, 본 명세서에서 ‘PLP’로 명명된 내용은, ‘데이터 유닛’ 또는 ‘데이터 파이프 (data pipe)’ 로 바꾸어 명명될 수도 있다.
디지털 방송 (DTV) 서비스에서 활용될 유력한 어플리케이션 (application) 중의 하나로, 방송 망과 인터넷 망과의 연동을 통한 하이브리드 방송 서비스를 꼽을 수 있다. 하이브리드 방송 서비스는 지상파 방송망을 통해서 전송되는 방송 A/V (Audio/Video) 컨텐츠와 연관된 인핸스먼트 데이터 (enhancement data) 혹은 방송 A/V 컨텐츠의 일부를 인터넷 망을 통하여 실시간으로 전송함으로써, 사용자로 하여금 다양한 컨텐츠를 경험할 수 있도록 한다.
도 1는 본 발명의 일 실시예에 따른 방송 시스템을 나타낸 도면이다.
도면을 참고하면, 본 발명의 일 실시예에 따른 방송 시스템(C11)은 방송 송신 장치(C110, Broadcast Transmitting Apparatus), 방송 수신 장치(C120, Broadcast Receiving Apparatus), 콘텐트 프로바이더(C130, Content Provider), 및/또는 콘텐트 서버(C140, Content Server) 중에서 적어도 하나를 포함할 수 있다.
콘텐트 프로바이더(C130)는 방송 서비스를 방송 송신 장치(C110)와 콘텐트 서버(C140)에 제공할 수 있다.
방송 송신 장치(C110)는 위성, 지상파, 및/또는 케이블 방송망 중에서 적어도 하나를 이용하여 방송 서비스를 포함하는 방송 신호를 송신할 수 있다. 방송 송신 장치(C110)는 제어부(미도시) 및 전송부(미도시)를 포함할 수 있다. 제어부는 방송 송신 장치(C110)의 동작을 제어할 수 있다. 예를 들어, 방송 송신 장치(C110)는 컨텐츠 프로바이더(C130) 및/또는 콘텐트 서버(C140)를 더 포함할 수 있다.
콘텐트 서버(C140)는 방송 수신 장치(C120)의 요청에 기초하여 방송 서비스를 전송할 수 있다.
방송 수신 장치(C120)는 방송망(예를 들어, 브로드캐스트) 및/또는 인터넷망(예를 들어, 브로드밴드) 중에서 적어도 하나를 이용하여 방송 서비스를 수신할 수 있다. 방송 수신 장치(C120)는 브로드캐스트 인터페이스(C1210, Broadcast Interface), 브로드밴드 인터페이스(C1230, Broadband Interface), 및/또는 제어부(C1250, Control Unit) 중에서 적어도 하나를 포함할 수 있다.
방송 수신 장치(C120)는 브로드캐스트 인터페이스(C1210)를 이용하여 방송 서비스를 포함하는 방송 신호를 수신할 수 있다. 이때 방송 신호는 위성, 지상파, 및/또는 케이블 방송망 중에서 적어도 하나를 이용하여 전송될 수 있다. 따라서 브로드케스트 인터페이스(C1210)는 방송 신호를 수신하기 위하여 위성 튜너, 지상파 튜너, 및/또는 케이블 튜너 중에서 적어도 하나를 포함할 수 있다.
방송 수신 장치(C120)는 브로드밴드 인터페이스(C1230)를 이용하여 콘텐트 서버(C140)에 방송 서비스를 요청할 수 있다. 방송 수신 장치(C120)는 브로드밴드 인터페이스(C1230)를 이용하여 콘텐트 서버(C140)로부터 방송 서비스를 수신할 수 있다.
방송 수신 장치(C120)는 디코더(미도시)를 이용하여 방송 서비스를 디코딩할 수 있다.
방송 수신 장치(C120)는 제어부(C1250)를 이용하여 브로드캐스트 인터페이스(C1210), 브로드밴드 인터페이스(C1230), 및/또는 디코더 중에서 적어도 하나를 제어할 수 있다.
도 2는 본 발명의 일 실시예에 따른 ROUTE 프로토콜 스택을 도시한 도면이다.
본 발명의 일 실시예에 따른 방송 송신 장치는 ROUTE 프로토콜 스택을 기초로 방송 서비스를 송신할 수 있다.
본 발명의 일 실시예에 따른 방송 서비스는 미디어 데이터(예를 들어, Video data, Auido data, Closed Caption data)뿐만 아니라 HTML5 어플리케이션, 양방향 서비스, ACR 서비스, 세컨드 스크린(second screen) 서비스, 개인화(personalization) 서비스 등의 부가 서비스를 포함할 수 있다.
예를 들어, IP 기반의 하이브리드 방송을 지원하는 차세대 방송 시스템의 방송 서비스는 실시간 콘텐트 데이터, 시그널링 데이터, ESG(Electronic Service Guide) 데이터, 및/또는 NRT(Non Real Time) 콘텐트 데이터를 포함할 수 있다.
이러한 방송 서비스는 지상파, 케이블, 및/또는 위성 등의 방송 망(broadcast)를 통하여 전송될 수 있다. 또한 본 발명의 일 실시예에 따른 방송 서비스는 인터넷 망(broadband)을 통하여 전송될 수 있다.
먼저, 방송 서비스가 방송 망을 통하여 전송되는 방법에 대해서 설명한다.
미디어 데이터는 비디오 데이터, 오디오 데이터, 및/또는 자막 데이터를 포함할 수 있다. 미디어 데이터는 MPEG(Moving Picture Expert Group)-DASH(Dynamic Adaptive Streaming over HTTP)의 Segment 및/또는 MMT(MPEG Media Transport)의 MPU (Media processing unit)로 encapsulation 될 수 있다. 예를 들어, MPEG-DASH의 Segment 및/또는 MMT의 MPU의 파일 형식은 ISO Base Media File(이하 ISO BMFF) 일 수 있다.
Signaling data, ESG data, NRT(Non Real Time) Content data, and/or 실시간 콘텐트 데이터들은 실시간 전송을 지원하는 Application Layer Transport Protocol 패킷으로 encapsulation 될 수 있다. 예를 들어, 실시간 콘텐트 데이터는 비디오 데이터, 오디오 데이터, 및/또는 자막 데이터와 같은 미디어 데이터를 포함할 수 있다. 또한, NRT Content data는 미디어 데이터 및/또는 어플리케이션을 포함할 수 있다. 또한, Application Layer Transport Protocol은 ROUTE(Real-Time Object Delivery over Unidirectional Transport) 및/또는 MMT를 포함할 수 있다. Application Layer Transport Protocol 패킷은 ROUTE packet 및/또는 MMT packet을 포함할 수 있다. 이하에서는, Application Layer Transport Protocol 패킷을 단순히 패킷으로 표현할 수도 있다.
그리고 나서, Application Layer Transport Protocol 패킷으로 encapsulation 된 데이터들은 UDP 데이터그램으로 encapsulation될 수 있다.
그리고 나서, UDP 데이터그램은 IP 데이터그램으로 encapsulation될 수 있다. 예를 들어, IP 데이터그램은 IP Multicast 또는 IP Unicast 방식에 기초한 데이터그램일 수 있다.
그리고 나서, IP 데이터그램은 방송 신호에 실려서 전송될 수 있다. 예를 들어, IP 데이터그램은 physical layer(Broadcast PHY)를 통해서 전송될 수 있다.
본 발명의 일 실시예에 따른 Signaling data는 시그널링의 속성에 따라서 차세대 방송 전송 시스템 및 방송망의 physical layer에 전달되는 transport frame(또는 프레임)의 특정 Physical Layer Pipe(PLP)를 통하여 전송될 수 있다. 예를 들어, 시그널링 형태는 비트 스트림 또는 IP 데이터그램으로 encapsulation 된 형태일 수 있다.
다음으로, 방송 서비스가 인터넷 망을 통하여 전송되는 방법에 대해서 설명한다.
Signaling data, ESG data, NRT Content data, and/or 실시간 콘텐트 데이터들은 HyperText Transfer Protocol(HTTP) 패킷으로 encapsulation 될 수 있다.
그리고 나서, HTTP 패킷으로 encapsulation된 데이터들은 Transmission Control Protocol(TCP) 패킷으로 encapsulation될 수 있다. 본 발명의 일 실시예에 따른 방송 서비스는 직접적으로 TCP 패킷으로 encapsulation될 수 있다.
그리고 나서, TCP 패킷은 IP 데이터그램으로 encapsulation될 수 있다. 예를 들어, IP 데이터그램은 IP Multicast 또는 IP Unicast 방식에 기초한 데이터그램일 수 있다.
그리고 나서, IP 데이터그램은 방송 신호에 실려서 전송될 수 있다. 예를 들어, IP 데이터그램은 physical layer(Broadband PHY)를 통해서 전송될 수 있다.
인터넷 망의 경우, Signaling data, ESG data, NRT Content data, and/or 실시간 콘텐트 데이터들은 수신기의 요청에 대한 응답으로서 전달될 수 있다.
방송 수신 장치는 전술한 ROUTE 프로토콜 스택을 기초로 방송 서비스를 수신할 수 있다.
이하에서는, 상술한 Signaling data, ESG data, NRT Content data, and/or 실시간 콘텐트 데이터들이 ROUTE의 transport packet으로 encapsulation 된 경우를 중심으로 설명한다.
ROUTE (Real-Time Object Delivery over Unidirectional Transport)은 IP 멀티캐스트 네트워크를 통한 파일 전달을 위한 프로토콜이다. ROUTE 프로토콜은 ALC (Asynchronous Layered Coding), 메시블리 스케일러블 멀티케스트 디스트리뷰션(massively scalable multicast distribution)을 위해 설계된 베이스 프로토콜, LCT(Layered Coding Transport) 및 기타 공지의 인터넷 표준들을 활용한다. ROUTE은 FLUTE을 개선한 것으로서 추가적인 특징을 가지고 FLUTE을 기능적으로 대체한다.
도면에서는 실시간 및 NRT 콘텐트의 하이브리드(브로드캐스트/브로드밴드) 전달을 위한 수신기 프로토콜 스택의 컨텍스트 상의 ROUTE을 도시하고 있다. 도시한 바와 같이, ROUTE는 시그널링 메시지, ESG(Electronic Service Guide) 메시지 및 NRT 콘텐트를 전달하는 기능을 수행한다. 이는 특히 예를 들어 MPEG-DASH Media Segment 파일들과 같은 스트리밍 미디어의 전달에 적합하다. FLUTE과 비교하여 ROUTE는 딜리버리 체인(delivery chain)을 통해 단대단 지연(end-to-end latency)을 제공한다.
ROUTE 프로토콜은 임의의 종류의 오브젝트의 전송을 제공하는 제네릭 트랜스포트 애플리케이션(generic transport application)이다. ROUTE 프로토콜은 장면 디스크립션들(scene descriptions), 미디어 오브젝트들, 및 DRM 관련 정보를 포함하는 풍부한 프리젠테이션(rich presentation )을 지원한다. ROUTE는 특히 실시간 미디어 콘텐트의 전송에 매우 적합하고, 많은 특징들을 제공한다.
예를들어, ROUTE는 상이한 미디어 컴포넌트들(예: language tracks, subtitles, alternative video views)에 대한 개별적인 전달(delivery) 및 접근을 제공한다. 그리고, ROUTE는 상이한 전송 세션들(transport sessions) 또는 심지어 ROUTE 세션들(ROUTE sessions)에서 전달을 가능하게 함으로써 계층화된 코딩(layered coding)의 지원을 제공한다. 또한, ROUTE는 멀티 스테이지(multistage)를 포함하는 유연한 FEC 보호에 대한 지원을 제공한다. 또한, ROUTE는 쉬운 MPEG-DASH 조합을 제공한다. MPEG-DASH 조합은 DASH의 브로드캐스트 및 브로드밴드 전달(delibery) 모드들 사이에서 시너지(synergy)를 가능하게 한다. 또한, ROUTE는 ROUTE 세션 및/또는 전송 세션(transport session)에 참가(join)할 때, 미디어에 빠른 접근을 제공한다. 또한, ROUTE는 전달 컨셉에 집중함으로서 높은 확장성을 제공한다. 그리고, ROUTE는 기존의 IETF 프로토콜들과의 호환성을 제공하고, IETF 기반의 확장 메커니즘들(IETF-endorsed extension mechanisms)의 사용과도 호환성을 제공한다.
ROUTE 프로토콜은 두 가지 주요 컴포넌트들로 나누어 진다. 첫 번째 컴포넌트는 오브젝트들 또는 오브젝트들의 흐름들/세트의 전달을 위한 소스 프로토콜(source protocol)이다. 두 번째 컴포넌트는 소스 프로토콜을 통하여 전달되는 딜리버리 오브젝트들 또는 딜리버리 오브젝트들의 묵음들(bundles)을 유연하게 보호하기 위한 리페어 프로토콜(repair protocol)이다.
소스 프로토콜은 리페어 프로토콜에 대하여 독립적이다. 즉, 소스 프로토콜은 ROUTE 리페어 프로토콜 없이도 배치(deploy)될 수 있다. 리페어는 오직 특정 배치 시나리오들 위해서, 예를 들어 모바일 수신을 위해서, 특정 지리적 영역들에서, 또는 특정 서비스를 위해서 추가될 수 있다.
소스 프로토콜은 3GPP TS 26.346에서 정의된 확장뿐만 아니라 RFC 6726에서 정의된 FLUTE와 맞추어 조정되지만, 예를 들어, 오브젝트 메타데이터와 오브젝트 콘텐츠가 합성(compound) 오브젝트에서 함께 전송될 수 있는 RFC 6968에서 정의된 FCAST의 일부의 원리들을 이용한다.
기본 FLUTE 프로토콜에 더하여, 미디어 데이터, 그로 인한 프로토콜의 이름의 실시간 전달을 위한 최적화된 지원이 가능한 소정의 최적화 및 제한이 추가된다. 그 중에서도, 소스 ROUTE 프로토콜은 오브젝트 기반 미디어 데이터의 실시간 전달을 제공한다. 또한, 소스 ROUTE 프로토콜은 딜리버리 오브젝트의 전송 인식 패킷화(transport-aware packetization) 뿐만 아니라 미디어 인식 패킷화의 인에이블링을 포함하여 유연한 패킷화를 제공한다. 또한, 소스 ROUTE 프로토콜은 파일 및 딜리버리 오브젝트의 독립성을 제공하고, 즉, 딜리버리 오브젝트는 파일의 일부 또는 파일의 그룹일 수 있다.
ROUTE 리페어 프로토콜은 FEC 기반이고, 전송 레이어(예를 들어, UDP) 및 오브젝트 딜리버리 레이어 프로토콜 사이에 추가적인 레이어로서 이용가능하다. FEC는 RFC 6363에 정의된 FEC 프레임워크의 개념을 재사용하지만, RFC 6363의 FEC 프레임워크와 대조적으로, ROUTE 리페어 프로토콜은 패킷을 보호하지 않고, 대신, 소스 프로토콜에서 전달된 딜리버리 오브젝트를 보호한다. 각 FEC 소스 블록은 (FLUTE와 유사한) 단일 딜리버리 오브젝트처럼 또는 FEC 보호 전에 번들링된 다수의 딜리버리 오브젝트에 의해 딜리버리 오브젝트의 일부로 구성될 수 있다. ROUTE FEC는 RFC 5052에서 정의된 것과 유사한 의미로 FEC 스킴을 이용하고, 그 문서의 용어를 이용한다. FEC 스킴은 FEC 인코딩 및 디코딩을 정의하고, FEC 스킴의 컨텍스트에서 패킷 패이로드 데이터를 식별하는데 사용되는 프로토콜 필드 및 절차를 정의한다.
ROUTE에서, 모든 패킷은 RFC 5651에서 정의된 LCT 패킷이다. 소스 및 리페어 패킷들은 서로 다른 ROUTE 세션들에 의해 구별될 수 있다. 즉, 상이한 ROUTE 세션은 상이한 IP/UDP 포트 조합 상에서 전송된다. 또한, 소스 및 리페어 패킷들은 서로 다른 LCT 전송 세션들로 구별될 수 있다. 즉, 상이한 LCT 전송 세션들은 LCT 헤더에서 상이한 TSI 값을 이용한다. 또한, 소스 및 리페어 패킷은, 동일한 LCT 전송 세션에서 전송되면, LCT 내의 PSI 비트에 의해 구별될 수 있다. 이 동작 모드는 FLUTE 호환가능 배치에 가장 적합하다.
ROUTE는 패킷 포맷들, 전송 동작(sending behavior), 및/또는 수신 동작(receiving behavior)을 포함하는 소스 프로토콜을 정의한다. 또한, ROUTE는 리페어 프로토콜을 정의한다. 또한, ROUTE는 전송 세션 확립(transport session establishment)을 위한 메타데이터 및 오브젝트 플로우 전달을 위한 메타데이터를 정의한다. 또한, ROUTE는 MPEG DASH 설정 및 ROUTE로의 맵핑에 대한 추천을 정의하여 풍부한 고품질의 선형 TV 방송 서비스를 가능하게 한다.
도 3는 본 발명의 일 실시예에 따른 방송 시스템을 나타낸 도면이다.
본 발명의 일 실시예에 따른 방송 시스템은 방송 송신 장치 및/또는 방송 수신 장치 중에서 적어도 하나를 포함할 수 있다. 방송 송신 장치는 제어부(C3150) 및/또는 전송부(미도시)중에서 적어도 하나를 포함할 수 있다. 방송 수신 장치는 브로드캐스트 인터페이스(미도시), 브로드밴드 인터페이스(미도시), 및/또는 제어부(C3250) 중에서 적어도 하나를 포함할 수 있다. 본 발명의 일 실시예에 따른 방송 시스템에 대한 기본적인 내용은 전술한 바와 동일하다.
방송 송신 장치는 방송 서비스를 방송 수신 장치로 전달할 수 있다. 예를 들어, 방송 송신 장치는 Media 및/또는 DASH Formats의 데이터를 방송 수신 장치로 전달할 수 있다.
방송 송신 장치의 제어부(C3150)는 Encoder & DASHer(C31530) 및/또는 ROUTE Sender(C31550) 중에서 적어도 하나를 포함할 수 있다.
Encoder & DASHer(C26110)는 방송 서비스를 인코딩하고, 인코딩된 방송 서비스를 MPEG-DASH의 적어도 하나의 Segment로 encapsulation할 수 있다.
예를 들어, Encoder & DASHer(C31530)는 Signaling data, ESG data, NRT Content data, 실시간 콘텐트 데이터 중에서 적어도 하나를 인코딩하고, 인코딩된 데이터를 MPEG-DASH의 적어도 하나의 Segment로 encapsulation할 수 있다. MPEG-DASH의 Segment의 파일 형식은 ISO BMFF일 수 있다.
ROUTE Sender(C31550)는 적어도 하나의 Segment를 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트(또는, 오브젝트)를 생성할 수 있다.
시그널링 정보는 방송 서비스의 발견 및/또는 서술 정보를 포함할 수 있다. 예를 들어, 시그널링 정보는 링크 레이어 시그널링 정보 및/또는 서비스 레이어 시그널링 정보를 포함할 수 있다. 또한, 시그널링 정보는 ROUTE Session Description, LCT Transport Session Description(또는, LCT Session Description), 및/또는 딜리버리 오브젝트 메타데이터(또는, Object metadata)를 포함할 수 있다. ROUTE Session Description은 ROUTE Session과 관련된 시그널링 정보를 포함할 수 있다. LCT Transport Session Description은 LCT Transport Session과 관련된 시그널링 정보를 포함할 수 있다. 딜리버리 오브젝트 메타데이터는 딜리버리 오브젝트와 관련된 시그널링 정보를 포함할 수 있다.
딜리버리 오브젝트는 Segment와 관련된 데이터를 포함할 수 있다. 예를 들어, 딜리버리 오브젝트는 Segment를 구성하는 데이터의 일부 및/또는 전체를 포함할 수 있다.
ROUTE Sender(C31550)는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 패킷에 패킷타이징 할 수 있다. 예를 들어, 패킷은 LCT 패킷을 포함할 수 있다.
그리고 나서, 방송 송신 장치는 ROUTE Sender(C26120) 및/또는 전송부(미도시)를 이용하여 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 포함하는 패킷을 송신할 수 있다.
방송 수신 장치는 방송 서비스를 수신하고, 방송 서비스를 디코딩할 수 있다. 예를 들어, 방송 수신 장치는 브로드캐스트 인터페이스 및/또는 브로드밴드 인터페이스 중에서 적어도 하나를 이용하여 방송 서비스를 포함하는 방송 신호를 수신할 수 있다. 방송 수신 장치는 제어부(C3250)를 이용하여 방송 서비스를 디코딩할 수 있다. 방송 수신 장치의 제어부(C3250)는 ROUTE Receiver(C32530) 및/또는 DASH Client(C32550) 중에서 적어도 하나를 포함할 수 있다.
ROUTE Receiver(C32530)는 방송 서비스를 수신하고, 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. ROUTE Receiver(C32530)는 방송 서비스를 포함하는 패킷을 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. 시그널링 정보는 물리적 레이어 시그널링 정보, 링크 레이어 시그널링 정보, 서비스 레이어 시그널링 정보, 딜리버리 오브젝트 메타데이터, 및/또는 타이밍 정보 중에서 적어도 하나를 포함할 수 있다. 예를 들어, 시그널링 정보는 ROUTE session Description, LCT transport session description, 및/또는 딜리버리 오브젝트 메타데이터를 포함할 수 있다. 딜리버리 오브젝트는 소스 프로토콜과 관련된 딜리버리 오브젝트 및/또는 리페어 프로토콜과 관련된 딜리버리 오브젝트 중에서 적어도 하나를 포함할 수 있다. ROUTE Receiver(C32530)는 Packet Receiver(C32531), Object Recovery(C32533), FEC Decoder(C32535), 및/또는 Delivery Object Cache(C32537) 중에서 적어도 하나를 포함할 수 있다.
Packet Receiver(C32531)는 방송 서비스를 포함하는 적어도 하나의 패킷을 수신할 수 있다. 예를 들어, 패킷은 LCT 패킷을 포함할 수 있다.
Object Recovery(C32533)는 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 소스 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
FEC Decoder(C32535)는 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 리페어 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
Delivery Object Cache(C32537)는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 저장하고, 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 DASH Client(C32550)로 전달할 수 있다. Delivery Object Cache(C32537)는 타이밍 정보를 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 DASH Client(C32550)로 전달할 수 있다.
예를 들어, 타이밍 정보는 동기화 정보, 하나의 채널 프로그램에 대한 기준이 되는 시각을 지시하는 PCR(Program Clock Reference), 디코딩 시각을 지시하는 DTS(Decoding Time Stamp), 및/또는 재생 시각을 지시하는 PTS(Presentation Time Stamp) 중에서 적어도 하나를 포함할 수 있다.
DASH Client(C32550)는 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 디코딩할 수 있다. 예를 들어, DASH Client(C32550)는 DASH Media Presentation 및/또는 타이밍 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 디코딩할 수 있다.
ROUTE 프로토콜의 범위는 LCT 패킷을 이용한 딜리버리 오브젝트 및 연관된 메타데이터의 신뢰성있는 전달이다. 오브젝트는 딜리버리 오브젝트 캐쉬(Delivery Object Cache)를 통해 애플리케이션에 이용가능하다. 이 캐쉬의 구현은 애플리케이션에 종속적이다.
ROUTE 프로토콜은 딜리버리 오브젝트를 전달하는 LCT 패킷의 포맷에 초점을 맞춘다. 또한, ROUTE 프로토콜은 FEC에 기초한 리페어 프로토콜을 이용한 딜리버리 오브젝트의 신뢰성있는 전달에 초점을 맞춘다. 또한, ROUTE 프로토콜은 딜리버리 오브젝트와 함께 오브젝트 메타데이터의 정의 및 전달에 초점을 맞추어 딜리버리 오브젝트 캐쉬 및 애플리케이션 간의 인터페이스를 가능하게 한다. 또한, ROUTE 프로토콜은 ROUTE 및 LCT 세션 기술에 초점을 맞추어 그 메타데이터와 함께 오브젝트의 수신을 확립한다. 또한, ROUTE 프로토콜은 패킷과 함께 전달될 보조 정보의 규범적 형태(normative aspects)(포맷, 시맨틱)에 초점을 맞추어 특정한 애플리케이션에 대한 성능, 예를 들어, 실시간 전달을 최적화한다.
또한, ROUTE 프로토콜은 전달에 사용될 적절한 DASH 포맷뿐만 아니라 특정 DASH Media Presentation 포맷들의 ROUTE 전달로의 추천 맵핑을 제공한다. 중요한 문제는 ROUTE를 이용하여 DASH 미디어 포맷이 그대로 사용될 수 있다는 것이다. 이 아키텍쳐 설계는 집중된(converged) 유니캐스트/브로드캐스트 서비스를 가능하게 한다.
도 4는 본 발명의 일 실시예에 따른 ROUTE Protocol의 방송 송신 장치의 동작을 나타낸 도면이다.
이 도면은 기본 송신자 개념을 도시하고 있다. LCT 패킷을 전달하는 ROUTE 세션이 확립된다. 이들 패킷은 소스 오브젝트 또는 FEC 리페어 데이터를 전송할 수 있다. 탑다운 접근 방식(top down approach)으로, 소스 프로토콜은 하나 이상의 LCT 세션으로 구성되고, 각 LCT 세션은 자신의 메타데이터와 함께 연관된 오브젝트를 전달한다. 메타데이터는 엔티티 모드 내의 합성 오브젝트로서 또는 패킷 헤더 내의 LCT 확장 헤더로서 LSID(LCT 세션 인스턴스 디스크립션(Session Instance Description))에서 정적으로 전달되거나 동적으로 전달될 수 있다. 패킷은 임의의 바이트 경계에서 오브젝트의 유연한 분할(fragmentation)을 허용하는 특정 FEC 스킴을 이용하여 ALC에서 전달된다. 또한, 딜리버리 오브젝트는 개별적으로 또는 번들링되어 FEC 보호될 수 있다. 어떤 경우에도, 번들링된 오브젝트는 인코딩되고, 리페어 패킷만이 전달된다. 소스 패킷들과 조합된 형태로 딜리버리 오브젝트 번들들의 복원을 허용한다. 예를 들어, 각각 상이한 특성을 갖는 하나 또는 다수의 리페어 플로우가 생성되어 상이한 레이턴시 요건(latency requirements), 상이한 보호 요건 등을 지원할 수 있다.
DMD(Dynamic MetaData)는 클라이언트에서 동적으로 FDT 동등 디스크립션들(equivalent description)을 생성하는 메타데이터이다. 이는 엔티티 모드에서는 엔티티 헤더에서 전송되고, 다른 전달 모드에서는 LCT 헤더에서 전송된다.
ROUTE 프로토콜은 소스 데이터의 서로 다른 보호 및 전달 스킴을 지원한다. 이는 또한 역호환성 모드로 배치될 수 있기 때문에 NRT 전달을 위한 기존의 모든 use case를 지원한다.
실시간 전달의 경우, 딜리버리 오브젝트 및 가능한 경우로서 연관된 FEC가 전달되어, 딜리버리 오브젝트가 예정된 시간이 되면 애플리케이션에 이용가능할 수 있도록 해야 한다.
소스 프로토콜만 전달될 수도 있다. ROUTE 프로토콜은 실시간 전달을 위해 사용될 수 있다. 이 경우, LSID 내의 @realtime 플래그는 true로 설정된다.
@realtime 플래그가 true로 설정된 경우, 아래와 같이 유지된다. 애플리케이션 특정 기한 이전에 마지막 패킷이 이용가능하도록 모든 패킷들이 전달된다. 더 상세한 내용들은 애플리케이션에 의해 제공된다. 모든 랜덤 액세스 포인트들에 대해 EXT_PRESENTATION_TIME 헤더가 제공된다. @minBufferSize는 모든 패킷들을 그 수신 시간과 프리젠테이션 시간 사이에 저장하기 위해 킬로바이트 단위의 최소 요구 크기를 제공한다. LSID 내의 EFDT는 내장되거나 참조로서 제공될 수 있다.
리페어 프로토콜이 전달될 수 있다. FEC이 포함되고, 리페어 플로우 선언(repair flow declaration)의 @minBufferTime이 존재하는 경우, @minBufferTime는 리페어 플로우를 위한 최소 버퍼 시간을 전달한다.
Security Considerations를 참조하면, 이는 RFC 5775에서 정의된 ALC와 관련되어 있다.
regular NRT Content Delivery를 참조하면, 정기적 파일 전달은 FLUTE 또는 ROUTE로 이루어 질 수 있다. 메타데이터 전달은 FLUTE 또는 ROUTE로 이루어 질 수 있다.
도 5는 본 발명의 일 실시예에 따른 LSID를 나타낸 도면이다.
ROUTE 세션은 IP 주소/포트 조합에 관련된다. 일반적으로, 이러한 세션에 참가함으로서, 세션의 모든 패킷들이 수신될 수 있고, 애플리케이션 프로토콜은 다른 프로세싱을 적용할 수 있다.
각각의 ROUTE 세션은 하나 또는 다수의 LCT 전송 세션으로 구성된다. LCT 전송 세션은 ROUTE 세션의 서브세트이다. 미디어 전달의 경우, LCT 전송 세션은 일반적으로, 미디어 컴포넌트, 예를 들어, DASH Representation을 전송하게 된다. 브로드캐스트 DASH의 관점에서, ROUTE 세션은 하나 이상의 DASH Media Presentation의 구성 미디어 컴포넌트를 전달하는 LCT 전송 세션의 멀티플렉스로서 간주될 수 있다. 각 LCT 전송 세션 내에서, 하나 또는 다수의 오브젝트, 일반적으로, 관련된 오브젝트, 예를 들어, 하나의 Representation과 연관된 DASH 세그먼트가 전송된다. 각각의 오브젝트와 함께, 메타데이터 특성은 오브젝트가 애플리케이션에 사용될 수 있도록 전달된다. 애플리케이션은 DASH Media Presentations, HTML-5 Presentations, 또는 다른 오브젝트 소모(object-consuming) 애플리케이션을 포함하지만, 이에 제한되지 않는다.
ROUTE 세션은 시간적으로 제한되거나 제한되지 않을 수 있다. ROUTE 세션은 하나 또는 다수의 LCT 전송 세션을 포함한다. 각각의 전송 세션은 LCT 헤더 내의 고유 TSI(Transport Session Identifier) 값에 의해 고유하게 식별된다.
수신기가 ROUTE 세션에 참가할 수 있기 전에, 수신기는 ROUTE Session Description을 얻을 필요가 있다. ROUTE Session Description은 전송자 IP 주소, 세션에 사용되는 어드레스 및 포트 번호, 세션이 ROUTE 세션이고 모든 패킷이 LCT 패킷이라는 지시 및/또는 IP/UDP 레벨에서 세션에 참가하고 소비하는데 필수적인 다른 정보 중 적어도 하나를 포함한다.
Session Description은 또한 ROUTE 세션에 사용되는 데이터 레이트(data rate) 및 ROUTE session의 지속기간(duration)에 대한 임의의 정보를 포함할 수 있고, 이에 제한되지 않는다.
Session Description은 RFC 4566에 정의된 SDP(Session Description Protocol) 또는 RFC 3023에서 정의된 XML 메타데이터 등의 형태일 수 있다. 이는 스케줄링 정보가 있는 웹 페이지에 위치한 등록 세션 제어 프로토콜(proprietary session control protocol)을 이용하여 임의의 세션 발표 프로토콜(session announcement protocol)을 통해서 전송되거나, 이메일 또는 다른 아웃-오브-밴드 방식으로 전달될 수 있다.
전송 세션은 ROUTE session description에 기술되지 않고 LSID(LCT Session Instance Description)에 기술된다. 전송 세션(즉, LCT 세션 또는 간단히 LCT 세션)은 소스 플로우(Source Flows) 및 리페어 플로우(Repair Flows) 중의 하나 또는 양쪽을 포함할 수 있다. 소스 플로우는 소스 데이터를 전송한다. 또한, 리페어 플로우는 리페어 데이터를 전송한다.
ROUTE 세션에 포함되는 LCT 전송 세션은 LSID(LCT Session Instance description)에 의해 기술된다. 특히, ROUTE 세션의 각각의 구성 LCT 전송 세션에서 전송되는 것을 정의한다. 각각의 전송 세션은 LCT 헤더 내의 TSI(Transport Session Identifier)에 의해 고유하게 식별된다.
LSID는 이 ROUTE 세션 상에서 전송되는 모든 전송 세션을 기술한다. LSID는 LCT 전송 세션들을 포함하는 동일한 ROUTE 세션에서 전달되거나, ROUTE 세션 이외의 수단에 의해, 예를 들어, 유니캐스트 또는 상이한 ROUTE 세션을 통해 전달될 수 있다. 전자의 경우, LSID는 TSI = 0를 갖는 전용 LCT 전송 세션 상에서 전달되고, 또한, TOI = 0에 의해 식별된 딜리버리 오브젝트일 것이다. TSI=0 상에서 전달되는 임의의 오브젝트에 대하여, 엔티티 모드가 사용되어야 한다. 이들 오브젝트가 엔티티 모드로 전달되지 않으면, LSID는 수신된 오브젝트에 대한 확장된 FDT를 얻기 전에 복원되어야 한다.
LSID의 인터넷 미디어 타입 (Internet Media Type)은 application/xml+route+lsid이다.
LSID는 다른 데이터 프래그먼트를 참조할 수 있다. LSID에서 참조되는 오브젝트도 TSI = 0 상에서 LSDI 자체보다는 TOI의 상이한 값을 가지고 전달되거나 전용 TSI ≠ 0인 별도의 LCT 세션 상에서 전달될 수 있다.
도면에서는 LSID 엘리먼트를 나타낸다. LSID 엘리먼트는 version 속성, validity 속성 및/또는 expiration 속성을 포함할 수 있다. 따라서, LSID 엘리먼트는 validity 속성 및 expiration 속성뿐만 아니라 version 속성을 이용하여 업데이트될 수 있다. 예를 들어, 어떤 전송 세션들은 어떤 시간 후에 종료될 수 있고 새로운 세션이 시작될 수 있다.
version 속성은 이 LSID 엘리먼트의 버전을 나타낸다. 버전은 디스크립터가 업데이트될 때 1만큼 증가한다. 수신된 가장 높은 버전 번호를 가진 LSID 엘리먼트가 현재 유효한 버전이다.
validity 속성은 LSID 엘리먼트가 유효한 날짜 및/또는 시간을 나타낸다. validity 속성은 존재하거나 존재하지 않을 수 있다. 존재하지 않으면, 수신기는 즉시 LSID 엘리먼트 버전이 유효한 것으로 가정해야 한다.
expiration 속성은 LSID 엘리먼트가 만료하는 날짜 및 시간을 지시한다. expiration 속성은 존재하거나 존재하지 않을 수 있다. 존재하지 않는 경우, 수신기는 LSID 엘리먼트가 모든 시간 동안 또는 연관된 만료 값을 가진 더 새로운 LSID 엘리먼트를 수신할 때까지 유효한 것으로 가정해야 한다.
LSID 엘리먼트는 적어도 하나의 TransportSession 엘리먼트를 포함할 수 있다. TransportSession 엘리먼트는 LCT 전송 세션에 대한 정보를 제공한다. 각각의 TransportSession 엘리먼트는 tsi 속성, SourceFlow 엘리먼트 및/또는 RepairFlow 엘리먼트 중 적어도 하나를 포함할 수 있다.
tsi 속성은 전송 세션 식별자를 지정한다. 세션 식별자는 0이 아니어야 한다.
SourceFlow 엘리먼트는 이 tsi 상에서 전달되는 소스 플로우의 정보를 제공한다.
RepairFlow 엘리먼트는 tsi 상에서 전송되는 리페어 플로우의 정보를 제공한다.
도 6은 본 발명의 일 실시예에 따른 SourceFlow Element를 나타낸 도면이다.
소스 프로토콜은 단방향 채널을 통해 딜리버리 오브젝트로를 전송하기 위한 ROUTE의 핵심 컴포넌트이다. 소스 프로토콜은 오브젝트 플로우로 관련 오브젝트를 전달하기 위해 ROUTE 세션 내에서 하나 이상의 소스 플로우를 확립한다. 각 오브젝트는 개별적으로 복원된다.
소스 프로토콜은 3GPP TS 26.346에서 정의된 확장뿐만 아니라 RFC 6726에서 정의된 FLUTE와 맞추어 조정되지만, 예를 들어, 오브젝트 메타데이터와 오브젝트 콘텐트가 합성(compound) 오브젝트에서 함께 전송될 수 있는 RFC 6968에서 정의된 FCAST의 일부 원리들을 이용한다. 소스 프로토콜은 리페어 프로토콜에 대하여 독립적이다. 즉, 소스 프로토콜은 ROUTE 리페어 프로토콜 없이도 배치(deploy)될 수 있다. 리페어는 특정 배치 시나리오들 위해서만, 예를 들어 모바일 수신을 위해서만, 특정 지리적 영역들에서만, 또는 특정 서비스를 위해서만 추가될 수 있다.
소스 프로토콜은 소스 플로우의 기술에 의해 정의된다. 소스 플로우는 딜리버리 오브젝트를 전송한다. 소스 프로토콜은 ALC 및 LCT를 이용하여 오브젝트를 전달한다.
도면에서는 SourceFlow 엘리먼트의 시맨틱을 도시하고 있다. 이하의 엘리먼트들은 소스 플로우를 기술한다.
SourceFlow 엘리먼트는 세션 내의 소스 플로우를 정의한다. SourceFlow는 EFDT element, idRef attribute, realtime attribute, minBufferSize attribute, ApplicationIdentifier element, 및/또는 적어도 하나의 PayloadFormat element 중 적어도 하나를 포함한다.
EFDT element는 파일 전달 데이터의 세부 사항을 지정한다. 이는 확장된 FDT instance이다. EFDT는 내장형(embedded)이거나 참조로서 제공될 수 있다. 잠조로서 제공되는 경우, EFDT는 LSID 대하여 독립적으로 업데이트 될 수 있다. 참조되는 경우, EFDT는 포함된 소스 플로우의 TOI=0 상에서 인밴드 (in-band) 오브젝트로서 전달될 것이다.
idRef attribute은 EFDT의 식별자로서, 해당 Transport Session에 의해 URI로서 나타내어질 수 있다.
realtime attribute는 딜리버리 오브젝트 및/또는 가능한 경우로서 연관된 FEC가 실시간으로 전달되는지 여부를 지시한다. realtime attribute가 존재하여 true로 설정된 경우, ROUTE 프로토콜은 실시간 전달을 위해 사용될 수 있다. realtime attribute가 존재하여 true로 설정된 경우, LCT 패킷은 포함된 딜리버리 오브젝트의 프리젠테이션 시간을 표현하는 NTP 타임스탬프를 포함하는 확장 헤더를 포함한다. realtime attribute가 존재하지 않는 경우, false이다.
minBufferSize attribute는 수신기에 저장될 필요가 있는 데이터의 최대 양을 정의한다. 이 값은 @realtime이 true로 설정된 경우에 존재할 수 있다.
ApplicationIdentifier 엘리먼트는 렌더링을 위한 LCT 전송 세션를 선택하기 위해, 이 전송 세션에서 전송되는 애플리케이션에 매핑될 수 있는 추가적인 정보, 예를 들어 DASH 콘텐트의 Representation ID 또는 DASH Representation의 Adaptation Set 파라미터들을 제공한다.
예를 들어, ApplicationIdentifier element는 매핑 정보를 포함할 수 있다. 매핑 정보는 시그널링 정보의 URL을 지시할 수 있다. 또한, 매핑 정보는 세션, 오브젝트, 또는 딜리버리 오브젝트의 고유한 주소뿐만 아니라, 시그널링 정보에서 할당된 식별자를 포함할 수 있다. 식별자는 Period ID, Adaptation Set ID, representation ID, 및/또는 component ID를 포함할 수 있다. 따라서, MPEG-DASH 콘텐츠의 경우, 매핑 정보는 세그먼트 URL, representation ID, component ID, Adaptation Set ID, 및/또는 Period ID 등을 포함할 수 있다.
보다 완벽한 매핑을 위하여, 본 발명의 일 실시예에 따른 ApplicationIdentifier element는 식별자 또는 오브젝트의 URL을 TOI 또는 TSI에 각각 매핑하는 매핑 정보를 더 포함할 수 있다. 즉, ApplicationIdentifier element는 현재 전송하고 있는 TOI 및/또는 TSI가 식별자 및/또는 오브젝트의 URL 중에서 어디에 매핑되는지를 지시하는 정보를 더 포함할 수 있다. 이때, 매핑 정보는 식별자 및/또는 오브젝트의 URL과 TOI 및/또는 TSI를 1:1, 1:多, 및/또는 多:1 중에서 하나로 매핑하는 정보일 수 있다.
PayloadFormat는 소스 플로우의 오브젝트을 나르는 ROUTE 패킷의 페이로드 포맷을 정의한다. PayloadFormat는 codePoint attribute, deliveryObjectFormat attribute, fragmentation attribute, deliveryOrder attribute, sourceFecPayloadID attribute, 및/또는 FECParamenters 중 적어도 하나를 포함할 수 있다.
codePoint attribute는 이 페이로드에 무슨 CodePoint 값이 사용되는지 정의한다. 이는 LCT header 내 CP 필드의 값이다. 이 값을 알려줄 때 오브젝트의 전달은 아래의 규칙들을 따르게 된다.
deliveryObjectFormat attribute는 딜리버리 오브젝트의 페이로드 포맷을 지정한다.
fragmentation attribute는 딜리버리 오브젝트의 단위를 지시한다. 예를 들어, fragmentation attribute가 0으로 설정된 경우, 그 단위는 임의의 단위일 수 있다. fragmentation attribute가 1로 설정된 경우, 그 단위는 sample 기반 단위인 애플리케이션 특정적 단위일 수 있다. fragmentation attribute가 2로 설정된 경우, 그 단위는 box들의 모음인 애플리케이션 특정적 단위일 수 있다.
fragmentation attribute는 패킷이 전송하고 있는 딜리버리 오브젝트의 단위를 지시할 수 있다. 또는, Fragmentation attribute는 딜리버리 오브젝트가 분할되는 규칙을 나타낼 수 있다. 예를 들어, Fragmentation attribute는 DASH Segment가 sample 단위, box 단위, 및/또는 일정 길이 단위 중에서 하나로 분할 된 것인지를 지시할 수 있다.
오브젝트는 MPEG-DASH의 Segment 및/또는 MMT의 MPU에 해당할 수 있는데, 딜리버리 오브젝트는 오브젝트를 구성하는 하위 구성요소에 해당할 수 있다. 딜리버리 오브젝트는 이전(preceding)의 데이터에 대한 의존성 없이 독립적으로 복호화 및/또는 재생될 수 있는 데이터 단위를 의미한다.
예를 들어, 딜리버리 오브젝트의 단위는 파일, 프래그먼트, 청크(chunk), GOP, Access Unit, 및/또는 NAL Unit을 포함할 수 있다. 딜리버리 오브젝트의 단위는 이에 한정되지 않고 의미 있는 단위들을 더 포함할 수 있다.
프래그먼트는 한 쌍의 무비 프래그먼트 박스(moof) 및 미디어 데이터 컨테이너 박스(mdat)를 포함하는 데이터 단위를 의미할 수 있다. 예를 들어, 프래그먼트는 MPEG-DASH의 서브세그먼트(Subsegment)에 해당할 수 있고, MMT의 프래그먼트에 해당할 수 있다. 프래그먼트는 적어도 하나의 Chunk 또는 적어도 하나의 GOP를 포함할 수 있다.
Chunk는 동일한 미디어 타입을 갖는 인접된 샘플들의 세트고, 가변적인 크기의 데이터 단위이다.
GOP는 비디오 코딩에서 사용되는 코딩을 수행하는 기본 단위이며, 적어도 하나의 I-프레임을 포함하는 프레임들의 세트를 나타내는 가변적인 크기의 데이터 단위이다. 본 발명의 일 실시예는 미디어 데이터를 독립적으로 의미 있는 데이터 단위인 딜리버리 오브젝트의 단위로 전송하므로, GOP은 Open GOP 및/또는 Closed GOP를 포함할 수 있다.
Open GOP에서, 하나의 GOP 내에 있는 B-프레임은 인접한 GOP의 I-프레임 또는 P-프레임을 참조할 수 있다. 따라서, Open GOP은 코딩 효율을 상당히 높일 수 있다. Closed GOP에서, B-프레임 또는 P-프레임은 해당 GOP 내에 있는 프레임 만을 참조하고, 해당 GOP외에 있는 프레임들은 참조하지 않는다.
Access Unit은 부호화된 비디오 또는 오디오의 기본 데이터 단위를 의미하고, 하나의 영상 프레임 또는 오디오 프레임을 포함할 수 있다.
NAL Unit은 네트워크 기기와의 통신을 고려하여 압축된 슬라이스에 대한 요약 정보 등이 포함되어 캡슐화된 압축된 비디오 스트림이다. 예를 들어, NAL Unit 슬라이스, 파라미터 세트, 및 SEI 등의 데이터를 바이트 단위로 패킷화한 데이터 단위일 수 있다.
deliveryOrder attribute는 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전달 순서를 지시한다. 예를 들어, deliveryOrder attribute가 0으로 설정된 경우, deliveryOrder attribute는 임의의 순서를 지시한다. deliveryOrder attribute가 1인 경우, deliveryOrder attribute는 순차적(in-order) 전달을 지시한다. deliveryOrder attribute가 2로 설정된 경우, deliveryOrder attribute는 미디어 샘플들이 순차적 전달로 전달되고 무비 프래그먼트 박스 이전에 전달됨을 지시한다.
딜리버리 오브젝트는 헤더 및 페이로드를 포함할 수 있다. 딜리버리 오브젝트의 헤더의 생성 순서 및/또는 소비 순서는 딜리버리 오브젝트의 페이로드의 생성 순서 및/또는 소비 순서와 다를 수 있다. 본 발명의 일 실시예에 따른 수신기는 생성 순서대로 수신된 패킷들을 소비 순서에 맞게 재배열하여 딜리버리 오브젝트를 재생할 수 있다.
deliveryOrder attribute가 0으로 설정된 경우를 구체적으로 설명한다.
방송 송신 장치는 딜리버리 오브젝트의 데이터를 포함하는 패킷을 임의의 순서로 전송할 수 있다. 방송 수신 장치는 임의의 순서로 패킷들을 수신하고, 패킷을 재배열할 수 있다. 그리고 나서, 방송 수신 장치는 딜리버리 오브젝트를 정확하게 복원, 파싱, 및/또는 재생할 수 있다.
deliveryOrder attribute가 1로 설정된 경우를 구체적으로 설명한다.
미디어 데이터가 미리 인코딩되었거나 소스 블록이 미리 생성된 경우에는, 딜리버리 오브젝트의 데이터를 포함하는 패킷의 전송 순서와 파싱 순서가 동일할 수 있다. 예를 들어, 방송 송신 장치는 딜리버리 오브젝트의 헤더에 해당하는 패킷들을 먼저 전송하고, 딜리버리 오브젝트의 패이로드에 해당하는 패킷들을 나중에 전송할 수 있다. 방송 수신 장치는 딜리버리 오브젝트의 헤더에 해당하는 패킷들을 먼저 수신하고, 딜리버리 오브젝트의 패이로드에 해당하는 패킷들을 나중에 수신할 수 있다. 그리고 나서, 방송 수신 장치는 딜리버리 오브젝트를 정확하게 복원, 파싱, 및/또는 재생할 수 있다.
deliveryOrder attribute가 2로 설정된 경우를 구체적으로 설명한다.
본 발명의 일 실시예에 따른 방송 송신 장치는 딜리버리 오브젝트를 생성하기 위해서 딜리버리 오브젝트의 페이로드를 먼저 생성한 이후에 딜리버리 오브젝트의 헤더를 생성할 수 있다. 이때, 방송 송신 장치는 딜리버리 오브젝트의 페이로드 내의 미디어 데이터를 포함하는 소스 블록을 생성할 수 있다. 예를 들어, 미디어 데이터 박스(mdat)에 포함된 미디어 데이터를 포함하는 적어도 하나의 소스 블록은 순차적으로 생성될 수 있다. 그리고 나서, 방송 송신 장치는 딜리버리 오브젝트의 헤더를 포함하는 소스 블록을 생성할 수 있다.
미디어 콘텐츠를 실시간으로 전송하기 위해서, 방송 송신 장치는 소스 블록을 생성 순서와 동일한 순서로 전송할 수 있다. 즉, 방송 송신 장치는 딜리버리 오브젝트의 페이로드를 포함하는 소스 블록(또는, 패킷)들을 먼저 전송하고, 딜리버리 오브젝트의 헤더를 포함하는 소스 블록(또는, 패킷)들을 나중에 전송할 수 있다.
이 경우, 본 발명의 일 실시예에 따른 방송 수신 장치 패킷들을 수신하고, 패킷을 재배열할 수 있다. 그리고 나서, 방송 수신 장치는 딜리버리 오브젝트를 정확하게 복원할 수 있다. 방송 수신 장치는 딜리버리 오브젝트의 헤더를 먼저 파싱한 이후에 딜리버리 오브젝트의 페이로드를 파싱할 수 있다.
sourceFecPayloadID attribute는 Source FEC Payload ID의 포맷을 정의한다. 예를 들어, sourceFecPayloadID attribute가 0으로 설정된 경우, source FEC payload ID는 없으며, 전체 딜리버리 오브젝트가 이 패킷에 포함된다. FECParameters는 존재하지 않게 된다. sourceFecPayloadID attribute가 1로 설정된 경우, source FEC payload ID는 32 비트이며, 오브젝트 내 시작 오프셋을 나타낸다. FECParameters는 존재하지 않게 된다. sourceFecPayloadID attribute가 2로 설정된 경우, FECParameters는 Source FEC Payload ID의 포맷을 정의한다.
sourceFecPayloadID attribute가 ‘1’ 인 경우를 구체적으로 설명한다.
이 경우, Source FEC Payload ID는 딜리버리 오브젝트를 전송하는 패킷의 페이로드의 첫번째 바이트의 위치를 지시할 수 있다. Source FEC Payload ID는 오브젝트 내에서 현재 전송중인 패킷 페이로드의 오프셋(시간적 위치 또는 공간적 위치)을 지시할 수 있다.
방송 수신 장치는 Source FEC Payload ID를 기초로 오브젝트 내에서 현재 전송 중인 딜리버리 오브젝트 및/또는 패킷의 순서를 인식할 수 있다. 방송 수신 장치는 Source FEC Payload ID를 기초로 수신한 패킷들을 순차적으로 정렬하고, 각각의 딜리버리 오브젝트 및/또는 오브젝트를 정확하게 복원, 파싱, 및/또는 디코딩할 수 있다.
FECParamenters 엘리먼트는 FEC 파라미터들을 정의한다. 이는 FEC-encoding-id, instance-id 등을 포함한다. 특히 적용된 Source FEC Payload ID를 알리기 위해 사용된다.
도 7은 본 발명의 일 실시예에 따른 딜리버리 오브젝트의 포맷을 나타낸 도면이다.
ROUTE 프로토콜은 전체 딜리버리 오브젝트의 전달을 가능하게 한다. 수신기가 딜리버리 오브젝트를 복원하여 애플리케이션에 전달하기 때문에 딜리버리 오브젝트는 이 프로토콜의 핵심 컴포넌트가 된다. 딜리버리 오브젝트는 애플리케이션에 대하여 독립적((self-contained)이고, 일반적으로 애플리케이션과 연관된 특정 특성들, 메타데이터 및 타이밍 관련 정보와 연관된다. 경우에 따라 이 특성들은 오브젝트 함께 대역 내에서(in-band) 제공되며, 다른 경우에는 데이터가 정적 또는 동적으로 대역 밖에서(out-of-band) 전달되어야 한다.
딜리버리 오브젝트는 "FDT Instance"에 의해 기술되고 수반되는 완전 하거나 부분적인 파일들을 포함할 수 있다. 또한, 딜리버리 오브젝트는 HTTP Entities (HTTP Entity Header and HTTP Entity Body) 및/또는 딜리버리 오브젝트의 패키지를 포함할 수 있다.
딜리버리 오브젝트가 완전 또는 부분적인 파일 및 HTTP Entities인 경우, 오브젝트가 FDT Instance와 함께 전체 파일 또는 파일의 바이트 범위에 해당하는지 여부에 따라 딜리버리 오브젝트는 더 구별될 수 있다. 또한 딜리버리 오브젝트는 시간 제한(timed) 전달인지 아니면 비시간 제한(non-timed) 전달이지에 따라 더 구별될 수 있다. 시간 제한인 경우, 소정의 실시간 및 버퍼 제약들이 적용되고, 특정한 확장 헤더들이 사용될 수 있다. 또한, 딜리버리 오브젝트는 딜리버리 오브젝트 특성을 기술하는 동적 및/또는 정적 메타데이터의 용도에 의해 더 구별될 수 있다. 또한, 딜리버리 오브젝트는 특정 데이터 구조, 특히 ISO BMFF의 전달에 의해 더 구별될 수 있다. 이 경우, 미디어 인식 패킷화(media-aware packetization) 또는 일반적인 패킷화가 적용될 수 있다.
DeliveryObjectFormatID는 애플리케이션에 정보를 제공하기 위해 어떤 포맷이 사용되는 지를 특정한다. 딜리버리 오브젝트 포맷은 파일 모드, 엔티티(Entity) 모드, 패키지 모드 중 적어도 하나를 포함한다.
파일 모드에서, 딜리버리 오브젝트는 파일 또는 파일의 바이트 범위를 나타낸다.
엔티티 모드에서, 딜리버리 오브젝트는 RFC 2616에서 정의된 엔티티를 나타낸다. 엔티티는 엔티티 헤더(entity-header) 필드와 엔티티 바디(entity-body)로 구성된다. 이 모드는 RFC 6968에저 정의된 FCAST의 주요 개념들을 재사용하지만, 확장 헤더 등을 포함하는 HTTP 엔티티 헤더들의 임의의 타입의 전달을 허용한다. 파일과 함께 전송된 엔티티 헤더 필드는 포함된 완전한 또는 부분적인 파일에 대한 모든 정보를 제공한다. 헤더에 Content-Range 엔티티 헤더가 포함되는 경우에는, 딜리버리 오브젝트sms 전달된 파일의 바이트 범위만 포함한다. 또한, 이 모드는, 엔티티 헤더가 시그널링을 포함하는 경우, 청크식(chunked) 전달을 허용한다.
패키지 모드에서는, 딜리버리 오브젝트가 전달만을 위해 패키지로 이루어진 파일들의 그룹으로 구성된다. 적용시 이 패키징은 전달의 목적으로만 적용되면, 클라이언트는 패키지를 해제하고 각 파일을 독립된 파일로서 애플리케이션에 제공한다. 패키징은, 오브젝트들이 전송을 위한 하나의 문서(document)로 패키징이 이루어지는 Multipart MIME에 의해 지원된다. 패키징된 파일들은 Content-Type이 multipart로 설정된 상태에서 파일 모드를 이용하여 전달된다. 파일이 패키지 모드에서 전달되는 경우, ROUTE 수신기는 데이터의 패키지를 해제해야 하는 반면, 포맷이 레귤러 파일 모드에서 전달되는 경우에는 패키지가 애플리케이션에 전달된다.
도 8은 본 발명의 일 실시예에 따른 파일 모드에서 ROUTE Distribution과 FLUTE Distribution의 비교를 나타낸 도면이다.
도면의 (a)를 참고하면, FLUTE를 이용한 방송 송신 장치(예를 들어, FLUTE sender(C81550-1) 및/또는 방송 수신 장치(예를 들어, FLUTE Receiver(C82550-1)가 도시되어 있다.
FLUTE sender(C81550-1)는 시그널링 정보 및/또는 적어도 하나의 오브젝트를 포함하는 적어도 하나의 LCT 패킷을 전송할 수 있다. 시그널링 정보는 FDT Instance를 포함할 수 있다. LCT 패킷은 헤더(LCT Header) 및/또는 페이로드(LCT Payload)를 포함할 수 있다.
FLUTE에서, FDT instance들은 대역 내에서(in-band) 전달되며, sender에서 오브젝트가 실시간으로 생성되는 경우, 실시간으로 생성하여 전달되어야 한다.
FDT(File Delivery Table)는 파일 전달 세션 내에서 전달될 파일들과 연관된 다양한 속성들을 기술하는 수단을 제공한다. FDT는 세션에서 전달될 파일들에 대한 파일 기술 엔트리(file description entries)의 세트이다. 각 파일 기술 엔트리는 기술하는 파일에 대한 TOI 및 파일을 식별하는 URI를 포함해야 한다.
FDT Instance는 직접 파일(또는 오브젝트)를 복원하기 전에 파일(또는 오브젝트)를 기술한다. 파일 전달 세션 내에서, FDT는 FDT Instance로서 전달된다. FDT Instance는 FDT의 하나 이상의 파일 기술 엔트리를 포함한다. 임의의 FDT Instance는 다른 FDT Instance와 동일하거나, 그 부분세트, 확대세트(superset)이거나, 중복되거나 이를 보완한다. 어떤 FDT Instance는 뒤따르는 (더 높은 FDT Instance ID 번호를 가진) FDT Instance들이 전송된 이후에도 세션 중에 여러 번 반복될 수 있다. 각 FDT Instance는 최소한 단일 파일 기술 엔트리를 포함하고 최대 파일 전달 세션에서 전달되는 파일들의 파일 기술 엔트리의 전체 세트를 포함한다.
FLUTE Receiver(C82550-1)는 시그널링 정보 및/또는 적어도 하나의 오브젝트를 포함하는 적어도 하나의 LCT 패킷을 수신할 수 있다. FLUTE Receiver(C82550-1)는 시그널링 정보를 기초로 적어도 하나의 오브젝트(또는, 파일)를 복원 및/또는 재생할 수 있다.
FLUTE Protocol은 적어도 하나의 오브젝트를 실시간으로 전송 및/또는 수신할 수 없다.
도면의 (b)를 참고하면, ROUTE를 이용한 방송 송신 장치 및/또는 방송 수신 장치가 도시되어 있다.
방송 송신 장치는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 포함하는 적어도 하나의 LCT 패킷을 전송할 수 있다. 시그널링 정보는 EFDT Instance Description을 포함할 수 있다. LCT 패킷은 헤더(LCT Header) 및/또는 페이로드(LCT Payload)를 포함할 수 있다.
방송 송신 장치의 제어부는 signaling information generator(C81540, EFDT Generator) 및/또는 ROUTE Sender(C81550) 중에서 적어도 하나를 포함할 수 있다. signaling information generator(C81540)는 ROUTE Sender(C81550)에 포함될 수도 있고, ROUTE Sender(C81550)와 독립적으로 존재할 수도 있다.
signaling information generator(C81540)는 방송 서비스의 발견 및 서술 정보를 포함하는 시그널링 정보를 생성할 수 있다. signaling information generator(C81540)는 EFDT Generator를 포함할 수 있다.
signaling information generator(C81540)는 EFDT Instance Description을 생성할 수 있다. EFDT Instance Description은 FDT Instance Description을 생성할 수 있는 데이터를 포함하는 extended FDT instance descriptor이다.
ROUTE sender(C81550)은 적어도 하나의 딜리버리 오브젝트를 생성할 수 있다.
방송 수신 장치는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 포함하는 적어도 하나의 LCT 패킷을 수신할 수 있다. 방송 수신 장치는 적어도 하나의 LCT 패킷을 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원 및/또는 재생할 수 있다. 방송 수신 장치는 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원 및/또는 재생할 수 있다.
방송 수신 장치의 제어부는 ROUTE Receiver(C82550)를 포함할 수 있다. ROUTE Receiver(C82550)는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 포함하는 적어도 하나의 패킷을 수신할 수 있다. ROUTE Receiver(C82550)는 적어도 하나의 패킷을 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. ROUTE Receiver(C82550)는 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. 시그널링 정보는 EFDT Instance Description을 포함할 수 있다.
예를 들어, ROUTE Receiver(C82550)는 FDT Instance Generator(C82553) 및/또는 FLUTE Receiver(C82555)를 포함할 수 있다. FDT Instance Generator(C82553)는 EFDT Instance Description 및/또는 LCT Header를 기초로 적어도 하나의 FDT Instance를 생성할 수 있다. FLUTE Receiver(C82555)는 적어도 하나의 LCT 패킷 및/또는 적어도 하나의 FDT Instance를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
파일 모드에서, 딜리버리 오브젝트는 파일 또는 파일의 바이트 범위를 나타낸다. 이 모드는 RFC 6726에서 정의된 FLUTE를 복제하고 있지만, 도시된 바와 같이 정적으로 메타데이터를 전송할 수 있는 능력을 가지고 한다.
RFC 6726 및 TS26.346의 FDT와 비교하여 ROUTE에서는, FDT는 확장된 FDT 및 LCT 헤더 내의 정보를 이용하는 것에 기초하여 그때그때 File 엘리먼트를 생성하는 규칙을 제공하는 능력을 포함하여 몇 가지 기능을 가지고 확장된다.
LCT 패킷 헤더와 함께 확장된 FDT는 딜리버리 오브젝트에 대한 FDT-equivalent description을 생성하기 위해 사용될 수 있다. 이를 통해 실시간 오브젝트에 대해 FDT를 연속적으로 전송해야 하는 필요성을 피하게 된다.
본 도면은 구현형태를 제한하는 것이 아니며, 참조 모델을 제공할 뿐이다.
이하의 방법들 (비전면 방식(non-exhaustive))은 확장된 FDT (참고: ATSC는 이 옵션들의 서브세트를 선택할 수 있다)를 전달하는데 이용될 수 있다.
확장된 FDT는 LSID의 SourceFlow 엘리먼트에 포함된 엘리먼트로서 전달될 수 있다.
또한, 확장된 FDT는 LSID에 의해 참조된 별도의 딜리버리 오브젝트에 전달되어, a) 구성요소 LCT 세션이 EFDT에 의해 기술된 딜리버리 오브젝트를 전송하는 동일 ROUTE 세션; 및/또는 b) ROUTE 세션 또는 the ROUTE 세션과 별개이면서 EFDT에 의해 기술된 딜리버리 오브젝트를 전송하는 구성요소 LCT 세션인 IP 멀티캐스트 스트림; 및/또는 c) 브로드밴드 네트워크로 전송될 수 있다.
또한, 확장된 FDT는 FDT와 일치하는 참조 없이 인밴드로 전달될 수 있다.
본 발명의 일 실시예에 따른 ROUTE Protocol은 오브젝트를 분할하여 딜리버리 오브젝트를 생성할 수 있다. 그 결과, ROUTE Protocol은 적어도 하나의 딜리버리 오브젝트를 실시간으로 전송 및/또는 수신할 수 있다.
도 9는 본 발명의 일 실시예에 따른 EFDT를 나타낸 도면이다.
EFDT는 확장된 FDT instance 디스크립터(모든 FDT 파라미터들도 포함)이다. EFDT는 route:idRef attribute, route:version attribute, route:maxExpiresDelta attribute, route:maxTransportSize attribute, 및/또는 route:FileTemplate 엘리먼트 중 적어도 하나를 포함한다.
route:idRef attribute는 EFDT의 식별자를 지시한다.
route:version attribute는 이 확장된 FDT instance 디스크립터의 버전을 지시한다. 디스크립터가 업데이트 되면 버전은 1만큼 증가한다. 가장 높은 버전 번호를 가지고 수신된 EFDT가 현재 유효한 버전이다.
route:maxExpiresDelta attribute는 오브젝트와 연관된 첫 번째 패킷을 전송한 후 Transport Session 내의 이 오브젝트에 대한 최대 만료 시간을 지시한다.
route:maxTransportSize attribute는 이 EFDT에 의해 기술된 오브젝트의 최대 전송 크기를 지시하는 것으로서 FEC_OTI에 없는 경우 존재하게 된다.
route:FileTemplate 엘리먼트는 바디에서 파일 URL 또는 파일 템플릿(template)을 지정한다.
FileTemplate 엘리먼트가 없는 경우, EFDT는 TS 26.346에 따른 FDT Instance를 따르게 된다. 이는 적어도 하나의 File 엘리먼트가 존재해야 하고, @expires 속성이 존재해야 함을 의미한다.
FileTemplate 엘리먼트가존재하는 경우, sender는 다음 정보를 포함하게 된다. TOI는 Content-Location이 유도될 수 있도록 설정된다. TOI의 첫번째 패킷을 전송 한 후, TOI에 관한 패킷들은 @maxExpiresDelta에 지시된 것보다 늦게 전송되어서는 안된다. 또한, ERT(Expected Residual Time)를 가진 EXT_TIME 헤더는 유용한 것으로 고려되는 경우, 보다 정확한 만료 시간을 전달하기 위해 사용될 수 있다. 만일 @maxExpiresDelta가 존재하지 않는 경우, ERT(Expected Residual Time)를 가진 EXT_TIME 헤더는 @Expires의 값을 시그널링하기 위해 이용된다.
FileTemplate 엘리먼트가 존재하는 경우, 아래에 정의된 과정들에 의해 FDT instance가 생성된다. EFDT에 포함된 데이터는 FDT Instance의 생성에서와 같이 이용될 수 있다. FileTemplate 엘리 먼트 내의 데이터는 특정 TOI 값을 가진 LCT 패킷의 수신과 함께 FDT Instance를 생성하기 위해 사용된다.
이 전송 세션에 대해 새로운 TOI를 가진 LCT 패킷이 수신되는 경우, FDT Instance 는 다음과 같이 새로운 File 엔트리를 가지고 생성된다. TOI는 File@Content-Location를 생성하기 위해 사용된다. EFDT 엘리먼트에 존재하는 다른 파라미터들은 모두 File 속성에 연관된다. EXT_FTI 또는 EXT_TOL 헤더 중 하나는 관련 FEC Transport Information을 추출하여 File 파라미터들에 매핑하는데 사용된다. 주목할 점은 ROUTE에서는, TOL이 (B 플래그로 지시된) 마지막 패킷으로부터 유도될 수 있고 시작 오프셋과 패킷 지속기간의 합을 제공함에 따라 이 헤더가 존재할 필요가 없다는 것이다. 만일 존재하는 경우, @maxExpiresDelta를 사용하여 @Expires 속성 값을 생성하게 된다. 수신기는 이 값을 수신기에서의 현재 시간에 추가하여 @Expires에 대한 값을 얻게 되는 것이다. 존재하지 않는 경우, ERT(Expected Residual Time)를 가진 EXT_TIME 헤더를 사용하여 FDT instance의 만료 시간을 추출하게 된다. 모두 존재하는 경우, 두 값 중 더 작은 값을 @Expires에 대한 값으로 사용하여야 한다.
도 10은 본 발명의 일 실시예에 따른 File templates에 대한 식별자들을 나타낸 도면이다.
FileTemplate 엘리먼트가 존재하는 경우, FileTemplate 엘리먼트의 값은 도면에 나열된 식별자를 포함할 수 있다.
식별자가 존재하지 않는 경우, FileTemplate는 유효한 URL이 되고, URL은 이 전송 세션에서 TOI(transport object identifier) 번호를 가진 오브젝트와 연관된다.
$TOI$가 존재하는 경우, 이 엘리먼트는 TOI와 URL 사이의 일대일 매핑을 생성하기 위해 사용된다.
각 URI에서, 도면의 식별자들은 도면에서 정의된 대입 파라미터에 의해 대체된다. 식별자 매칭은 대소문자를 구별한다. URI에 유효한 식별자를 포함하지 않는 언이스케이프(unescaped) $ 심볼이 포함된 경우, URI 형성 결과는 정의되지 않는다. 식별자의 포맷도 도면에서 지정되어 있다.
각 식별자는 아래 프로토타입 다음에 나오는 인클로징 ‘$’ 문자 내에서 접미사로 올 수 있다.
“%0[width]d”
width 파라미터는 프린트 될 문자들의 최소 개수를 제공하는 무부호 정수이다. 프린트 될 값이 이 수보다 짧으면, 그 결과는 0으로 패딩되게 된다. 그 결과가 더 커도 값은 자르지(truncated) 않는다.
FileTemplate는 작성되어 대체 과정의 애플리케이션이 유효한 URI를 발생시키도록 한다.
식별자 외부의 문자열(string)들은 RFC 3986에 따라 URI 내에서 허용되는 문자들만 포함하게 된다.
도 11은 본 발명의 일 실시예에 따른 ROUTE Packet Format을 나타낸 도면이다.
전체 ROUTE Packet Format은 도면에 도시된 바와 같다. 패킷은 IP 패킷으로서 IPv4 또는 IPv6이며, IP header는 UDP header보다 선행한다. ROUTE Packet Format은 IP 버전 번호에 종속되지 않는다.
ROUTE에 의해 사용되는 Packet Format은 ALC packet format, 즉 UDP header 뒤에 오며, 이 헤더 뒤에는 LCT header와 Source FEC Payload ID가 오고, 그 뒤에는 packet payload가 온다. LCT header는 RFC 5651의 LCT 빌딩 블록에서 정의된다. ROUTE에서의 Source FEC Payload ID는 일반적으로 직접 제공되거나 임의의 FEC 스킴에 의해 제공되는 start_offset이다.
ROUTE Packet은 UDP Header, LCT Header, ROUTE (ALC) Header, 및/또는 Payload Data 중에서 적어도 하나를 포함할 수 있다.
UDP(User Datagram Protocol)는 IP를 사용하는 네트워크 내에서 컴퓨터들 간에 메시지들이 교환될 때 제한된 서비스만을 제공하는 트랜스포트 계층의 통신 프로토콜이다. UDP Header는 Source Port field, Destination Port field, Length field, 및/또는 Checksum field 중에서 적어도 하나를 포함할 수 있다. Source Port field는 송신 측의 포트를 지시할 수 있다. Destination Port field는 수신 측의 포트를 지시할 수 있다. Length field는 패킷 전체의 길이를 지시할 수 있다. Checksum field는 에러 검출을 위한 정보를 포함할 수 있다.
ALC(Asynchronous Layered Coding)는 단일 송신자가 여러 수신자들에게 파일을 전송하는 동안에 여러 채널들을 통해 신뢰성과 혼잡 제어가 가능하도록 표준화한 프로토콜이다. ALC는 에러제어를 위한 FEC Building Block, 혼잡 제어를 위한 WEBRC Building Block, 및/또는 세션 및 채널 관리를 위한 LCT Building Block을 결합한 것으로, 서비스와 필요에 따라서 빌딩 블록을 구성할 수 있도록 되어 있다. 본 발명의 일 실시예에 따른 ROUTE Header는 ALC Header를 포함할 수 있다.
LCT(Layered Coding Transport)는 신뢰성 있는 콘텐츠 전송 및 스트림 전송 프로토콜을 위한 전송레벨의 지원을 제공한다. LCT는 수신자에게 전달할 기본적인 정보의 내용과 특징에 대한 정보를 제공한다. The LCT 패킷 헤더 필드들은 RFC 5651에서 LCT 빌딩 블록에 의해 정의된 바와 같이 사용된다. LCT Header는 LCT version number field(V), Congestion control flag field(C), Reserved field(R), Transport Session Identifier flag field(S), Transport Object Identifier flag field(O), Half-word flag field(H), Sender Current Time present flag field(T), Expected Residual Time present flag field(R), Close Session flag field(A), Close Object flag field(B), LCT header length field(HDR_LEN), Codepoint field(CP), Congestion Control Information field(CCI), Transport Session Identifier field(TSI), Transport Object Identifier field(TOI), Header Extensions field, 및/또는 FEC Payload ID field 중에서 적어도 하나를 포함할 수 있다.
LCT version number field(V)는 프로토콜 버전 번호를 지시한다. 예를 들어, 이 필드는 LCT 버전 번호를 지시한다. LCT header의 버전 번호 필드는 ROUTE 버전 번호 필드로 해석되어야 한다. ROUTE의 이 버전은 RFC 5651에서 정의된 LCT building block의 버전 1을 암시적으로 이용한다. 예를 들어 버전 번호는 ‘0001b’이다.
Congestion control flag field(C)는 Congestion Control Information 필드의 길이를 지시한다.
Reserved field(R) reserved for future use. 예를 들어, Reserved field(R)는 Protocol-Specific Indication field(PSI)일 수 있다. Protocol-Specific Indication field(PSI)는 LCT 상위 프로토콜에서 특정 목적의 지시자로 사용될 수 있다. PSI 필드는 현재 패키지 소스 패킷인지 아니면 FEC 리페어 패킷인지를 지시한다. ROUTE 소스 프로토콜은 소스 패킷만을 전달하므로 이 필드는 ‘10b’로 설정된다.
Transport Session Identifier flag field(S)는 Transport Session Identifier 필드의 길이를 지시한다.
Transport Object Identifier flag field(O)는 Transport Object Identifier 필드의 길이를 지시한다. 예를 들어, TOI는 딜리버리 오브젝트의 식별정보일 수 있다.
Half-word flag field(H)는 TSI 및 TOI 필드의 길이에 half-word(16 bits)를 추가할지 여부를 지시한다.
Sender Current Time present flag field(T)는 SCT(Sender Current Time) 필드가 존재하는지 여부를 지시한다. T = 0은 SCT(Sender Current Time) 필드가 존재하지 않음을 지시한다. T = 1은 SCT 필드가 존재하을 지시한다. SCT는 세션이 얼마나 오래 진행되었는지를 수신기에 지시하기 위해 송신기에 의해 삽입된다.
Expected Residual Time present flag field(R) ERT(Expected Residual Time) 필드의 존재유무를 지시한다. R = 0은 ERT(Expected Residual Time) 필드가 존재하지 않음을 지시한다. R = 1은 ERT 필드가 존재함을 지시한다. ERT는 세션/오브젝트 전송이 얼마나 더 오래 지속되는지를 수신기에 지시하기 위해 송신기에 의해 삽입된다.
Close Session flag field(A)는 세션이 종료 또는 종료가 임박했음을 지시한다.
Close Object flag field(B)는 전송 중인 딜리버리 오브젝트가 종료 또는 종료가 임박했음을 지시한다.
LCT header length field(HDR_LEN): LCT header의 총길이를 32 비트 워드 단위로 지시한다.
Codepoint field(CP)는 이 패킷에 의해 전송되는 페이로드의 종류를 지시한다. 페이로드의 종류에 따라, 추가적인 페이로드 헤더가 추가되어 페이로드 데이터 앞에 붙을 수 있다.
Congestion Control Information field(CCI)는 layer numbers, logical channel numbers, sequence numbers 등의 Congestion Control 정보 전송에 사용된다. LCT header 내의 Congestion Control Information field는 요구되는 정체 제어 정보(Congestion Control Information)를 포함한다.
Transport Session Identifier field(TSI)는 세션의 고유 식별자이다. TSI는 특정 송신기로부터의 모든 세션 중에서 해당 세션을 고유하게 식별한다. 이 필드는 ROUTE 내의 Transport Session를 식별한다. Transport Session의 컨텍스트는 LSID(LCT Session Instance description)에 의해 제공된다.
Transport Object Identifier field(TOI)는 오브젝트 및/또는 딜리버리 오브젝트의 고유 식별자이다. TOI는 해당 패킷이 세션 내의 어느 오브젝트에 관한 것인지를 지시한다. 이 필드는 현재 패킷의 페이로드가 이 세션 내의 어느 오브젝트에 속하는지를 지시한다. TOI 필드의 오브젝트로의 매핑은 Extended FDT에 의해 제공된다. Extended FDT는 파일 전달 데이터의 세부사항을 지정한다. 이는 확장된 FDT instance이다. 세션에서 하나 이상의 오브젝트가 전송되는 경우, LCT header 내의 TOI(Transmission Object ID) 사용하여 패킷 페이로드 데이터가 어느 오브젝트로부터 생성되는지를 식별해야 한다.
Header Extensions field는 추가 정보 전송을 위한 LCT 헤더 확장 부분으로 사용된다. Header Extensions은 항상 이용되는 것은 아니거나 가변적인 크기를 가지는 선택적 헤더 필드들을 LCT에서 수용하기 위해 사용된다. 예를 들어, EXT_TIME extension은 여러가지 종류의 타이밍 정보를 전송하기 위해 사용된다. 이는 범용 타이밍 정보, 즉 이 문서에서 설명하는 Sender Current Time(SCT), Expected Residual Time(ERT) 및 Sender Last Change (SLC) time extensions를 포함한다. 또한 (예들 들어, 단일 프로토콜 예시화를 위해 정의된) 더 좁은 적용성을 가진 타이밍 정보를 위해 사용될 수 있다. 이 경우 별도의 문서에서 기술하게 된다.
FEC Payload ID field는 Transmission Block 또는 encoding symbol의 식별 정보를 포함할 수 있다. FEC Payload ID는 상기 파일이 FEC 인코딩된 경우의 식별자를 나타낼 수 있다.
Payload Data는 적어도 하나의 Transmission Block 및/또는 encoding symbol의 데이터를 포함할 수 있다. 패킷 페이로드는 오브젝트에서 생성된 바이트들을 포함한다. 세션에서 하나 이상의 오브젝트가 전송되는 경우, LCT header 내의 Transmission Object ID(TOI)를 사용하여 패킷 페이로드 데이터가 어느 오브젝트에서 생성 되는지를 식별해야 한다.
ROUTE 소스 프로토콜은 아래의 세부사항들과 함께 RFC 5775에서 정의된 ALC를 기초로 한다.
먼저, RFC 5775에서 정의된 Layered Coding Transport (LCT) Building Block은 다음과 같은 제한 조건들을 가지고 사용된다. LCT header 내의 Congestion Control Information (CCI) 필드는 0으로 설정 될 수 있다. LCT header 내의 TSI는 LCT 전송 세션에 따라 설정 되게 된다; 해당 패킷은 LSID에서 정의된 바와 같이 적용된다. LCT header 내의 Code Point을 사용하여 LSID에서 정의된 바와 같이 적용된 포맷을 시그널링하게 된다. PSI의 첫번 째 비트는 소스 패킷을 지시하기 위해 1로 설정된다.
ALC에 따르면, 딜리버리 오브젝트의 옥텟 단위의 시작 주소를 지정하는 source FEC Payload ID가 사용된다. 이 정보는 새로운 단순 FEC 스킴, 기존의 FEC 스킴, 및/또는 LSID 중 적어도 하나를 포함하는여러 가지 방식으로 전송 될 수 있다.
새로운 단순 FEC 스킴은, source FEC Payload ID가 크기 0으로 설정된 방식을 가능하게 한다. 이 경우 패킷은 전체 오브젝트를 포함하게 된다. 또한, source FEC Payload ID는 32비트를 사용하여 직접적인 주소(시작 오프셋)을 지시할 수 있다.
기존의 FEC 스킴은 RFC 5445에서 정의된 Compact No-Code를 이용하여 넓게 배치되어 있다. 또한, 기존의 FEC 스킴은, SBN 및 ESI가 심볼 크기 T와 함께 시작 오프셋을 정의하는 RFC 6330와 호환가능하게 넓게 배치되어 있다.
LSID는 @sourceFecPayloadID 속성 및 FECParameters 엘리먼트를 이용하여 상기 모드들 중 임의의 모드를 알리기 위해 적절한 적절한 시그널링을 제공한다.
둘째, RFC 5651에서 정의된 LCT Header EXT_TIME extension이 송신기에 의해 다음과 같은 방식으로 사용될 수 있다. 애플리케이션에 따른 송신기의 현재 시간을 이따금씩 또는 자주 알리기 위해 Sender Current Time을 사용할 수 있다. 이는 송신기와 수신기의 클럭을 동기화 시키거나 지터 및 딜리버리 레이턴시를 측정하기 위해 사용될 수 있다. Expected Residual Time (ERT)는 현재 오브젝트에 대해 예상되는 잔여 시간을 지시하기 위해 사용될 수 있다. SLC flag는 일반적으로 사용하지 않으나, 세그먼트의 추가/제거를 지시하기 위해 사용할 수 있다.
셋째, 추가적인 확장 헤더들을 이용하여 실시간 전달을 지원할 수 있다. 이러한 확장 헤더들은 아래에서 정의한다.
넷째, LCT Session description 정보는 LCT Session Instance Description (LSID)를 통해 전달된다.
다섯째, ROUTE session description은 외부의 수단을 통해 전달된다.
ROUTE가 LCT building block의 사용에 도입하는 주요 변경 내용은 다음과 같다. ROUTE는 LCT building block의 사용을 세션당 단일 채널로 제한한다. 따라서, ROUTE에서 정체 제어는 송신기가 주도하는 것이다. 수신기가 주도하는 계층적 멀티캐스트(layered multicast)의 기능은 애플리케이션에 의해 여전히 제공되어, 수신기 애플리케이션이 해당 세션의 대역폭 요건을 기초로 적절한 전달 세션을 선택하는 것을 가능하게 할 수 있다.
일부 특수한 경우, ROUTE 송신기는 페이로드를 포함하지 않는 ROUTE 패킷을 생성해야 할 필요가 있을 수 있다. 이는 예를 들어, 종류를 알리거나 정체지역 정보를 전달하기 위해 필요 할 수 있다. 이러한 데이터가 없는 패킷은 ROUTE Header 또는 Payload Data을 포함하지 않고 LCT header 필드만 포함한다. 외부의 프로토콜 헤더(예를 들어, IP 또는 UDP header)에 의해 전달된 총 데이터그램 길이는, 수신기가 ROUTE (ALC) header 및 페이로드의 부재를 검출하는 것을 가능하게 한다.
도 12는 본 발명의 일 실시예에 따른 EXT_PRESENTATION_TIME Header를 나타낸 도면이다.
서로 다른 환경에서의 프로토콜의 적절한 동작을 위해, 서로 다른 목적을 위한 ROUTE 프로토콜의 동작을 지원하는 LCT extension 헤더들이 정의된다. 이 헤더들은 RFC 5651의 Section 9에 따라 IANA에 등록되어야 한다.
LCT extension header는 EXT_PRESENTATION_TIME Header 및/또는 EXT_TIME Header 중 적어도 하나를 포함할 수 있다.
EXT_PRESENTATION_TIME Header는 패킷에 포함된 오브젝트가 벽 시간(wall-clock time)으로 표시될 예정인 시간을 나타낸다. EXT_PRESENTATION_TIME Header은 LCT 패킷에 추가될 수 있다. 고정된 길이의 헤더가 등록되게 된다.
이는 존재할 경우, 64비트 타임스탬프(timestamp)의 셋째, 넷째 및 다섯째 옥텟을 나타낸다. 그 값은 항상 SCT(Sender Current Time)보다 커야 한다. 또는 도시된 바와 같이 64-비트 NTP(Network Time Protocol) 타임스탬프 값은 나타낸다.
도면에서는 본 발명의 일 실시예에 따른 EXT_PRESENTATION_TIME Header를 도시하고 있다.
EXT_PRESENTATION_TIME Header는 Header Extension Type(HET) 필드, Header Extension Length(HEL) 필드, reserved 필드, 및/또는 NTP timestamp 중 적어도 하나를 포함할 수 있다.
HET 필드는 해당 Header Extension 타입을 지시한다. HET field는 8비트 정수일 수 있다. 0에서 127까지의 HET 값들(TBD(To Be Determined))은 가변길이의 Header Extension들에 사용된다. 128에서 255까지의 HET 값들은 고정 길이의 32 비트 Header Extension들에 사용된다.
HEL 필드는 복수의 32비트 워드로 나타낸 Header Extension 필드의 전체 길이를 지시할 수 있다. HEL 필드는 8비트 정수일 수 있다. 이 필드는 가변 길이의 extension들(0과 127 사이의 HET)에 대해서는 존재해야 하고, 고정 길이의 extension들(128과 255 사이의 HET)에 대해서는 존재해서는 안된다.
NTP timestamp는 패킷에 포함된 오브젝트가 벽 시간으로 표시될 예정인 시간을 나타낼 수 있다. NTP timestamp는 두 개의 32 비트 부분들 사이에 암시적인 소수점(fraction point)을 갖진 64 비트 바이너리 값이다. NTP timestamp는 136년까지 나타내는 32 비트의 무부호 초단위(seconds) 필드(최상위 워드)와 232 피코세컨드까지 나타내는 32 비트 소수(fraction) 필드(최하위 워드)를 포함할 수 있다.
또한, RFC 5651에서 정의된 EXT_TIME headers를 사용하여 SCT-high 및 SCT-low flag를 설정할 수 있다. EXT_TIME Header는 여러 가지 종류의 타이밍 정보를 전송하기 위해 사용된다. 이 헤더는 HET 필드, HEL 필드, Use 필드, 및/또는 적어도 하나의 범용 타이밍 정보를 포함한다.
Use 필드는 뒤따르는 32 비트 시간 값의 시맨틱을 지시한다. Use 필드는 SCT-high flag, SCT-low flag, ERT flag, 및/또는 SLC flag 중 적어도 하나를 포함할 수 있다. Use 필드에서 지정한 EXT_TIME Header Extension에는 여러 "시간 값(time value)" 필드들이 존재할 수 있다.
범용 타이밍 정보는 Sender Current Time (SCT), Expected Residual Time (ERT) 및/또는 Sender Last Change (SLC) time extensions 중 적어도 하나를 포함할 수 있다.
SCT는 해당 패킷이 전송된 때의 송신기에서의 ?대 시간을 나타낸다. 애플리케이션에 따른 송신기의 현재 시간을 이따금씩 또는 자주 알리기 위해 SCT를 사용할 수 있다. 이는 송신기와 수신기의 클럭을 동기화 시키거나 지터 및 딜리버리 레이턴시를 측정하기 위해 사용될 수 있다.
ERT는 현재 오브젝트의 전송을 위해 예상되는 전송기 잔여 전송 시간을 나타낸다. ERT는 현재 오브젝트에 대해 예상되는 잔여 시간을 지시하기 위해 사용될 수 있다.
SLC time은 초 단위의 서버 벽 시간으로서, 세션 데이터에 마지막 변경이 발생한 시각이다. SLC flag는 일반적으로 사용하지 않으나, 세그먼트의 추가/제거를 지시하기 위해 사용할 수 있다.
도 13은 본 발명의 일 실시예에 따른 방송 송신 장치의 흐름도를 나타낸 도면이다.
방송 송신 장치는, Encoder & DASHer를 이용하여, 방송 서비스를 인코딩할 수 있다. 예를 들어, 방송 서비스는 Signaling data, ESG data, NRT Content data, 및/또는 실시간 콘텐트 데이터 중에서 적어도 하나를 포함할 수 있다. NRT Content data 및/또는 실시간 콘텐트 데이터는 미디어 데이터를 포함할 수 있다. 미디어 데이터는 Video data, Audio data, 및/또는 Closed Caption data 중에서 적어도 하나를 포함할 수 있다.
인코딩된 방송 서비스는 MPEG-DASH의 적어도 하나의 Segment로 encapsulation될 수 있다. MPEG-DASH의 Segment의 파일 형식은 ISO BMFF일 수 있다. 예를 들어, Video data, Audio data, 및/또는 Closed Caption data는 MPEG-DASH의 적어도 하나의 Segment로 encapsulation될 수 있다.
방송 송신 장치는, ROUTE Sender 및/또는 딜리버리 오브젝트 제너레이터를 이용하여, 서비스의 적어도 하나의 콘텐트 컴포넌트에 포함되며, 독립적으로 복원되는(recovered individually) 적어도 하나의 딜리버리 오브젝트를 생성할 수 있다(CS13100).
딜리버리 오브젝트는 파일, 파일의 일부(a part of the file), 파일의 그룹(a group of the file), Hyper Text Transfer Protocol(HTTP) Entity, 및 HTTP Entity의 그룹 중에서 하나일 수 있다.
딜리버리 오브젝트는 object-based media data를 포함할 수 있다. 예를 들어, 딜리버리 오브젝트는 MPEG-DASH Media Segment file 및/또는 MPEG-DASH Media Segment file의 일부를 포함할 수 있다.
딜리버리 오브젝트는 Segment와 관련된 데이터를 포함할 수 있다.
기본 동작으로, 딜리버리 오브젝트가 ROUTE sender에 완전히 이용 가능한 것으로 가정한다. 또한, T > 0는 바이트 단위의 오브젝트의 전송 길이(Transfer-Length)인 것으로 가정한다. 첫번째 데이터 패킷의 최대 전송 단위는 Y인 것으로 알려져 있다. 전송 단위는 기본적인 전송 블록 크기에 대한 지식이나 다른 제한조건들에 의해 결정된다.
Y가 T 이상인 경우, 이는 딜리버리 오브젝트를 위한 유일한 패킷이다. 따라서, Codepoint field(CP)는 0의 패킷 헤더 크기를 지시하도록 설정될 수 있다. 그 다음 전체 딜리버리 오브젝트는 패킷의 페이로드로서 전송 된다.
Y이 T 보다 작으면, 패킷의 페이로드에서 전송되는 데이터는 오브젝트의 연속된 부분으로 구성된다. 이때, X + Y이 최대 T인 임의의 X와 임의의 Y > 0에 대해, ROUTE 패킷이 생성될 수 있다. 이 경우, 패킷의 페이로드에서 전송되는 데이터는 X 바이트의 시작부분에서 시작하여 X + Y 바이트의 시작부분까지 오브젝트의 연속된 부부으로 구성되게 된다. 또한, ROUTE 패킷 헤더 내의 시작 오프셋은 X로 설정되고, 페이로드 데이터는 전송할 패킷에 추가된다. X + Y가 T와 동일한 경우, 페이로드 헤더 플래그 B(즉, Close Object flag 필드(B))는 "1"로 설정되게 되며, 그 외에는 페이로드 헤더 플래그 B가 "0"으로 설정되게 된다.
방송 송신 장치는 signaling information generator를 이용하여, 서비스 및 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 생성할 수 있다(CS13200).
시그널링 정보는 서비스의 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션을 서술하는 제1 정보를 포함할 수 있다. 예를 들어, 제1 정보는 Service Layer Signaling(SLS), LCT Session Instance Description(LSID), 및/또는 Service-based Transport Session Instance Description(S-TSID)를 포함할 수 있다.
시그널링 정보는 ROUTE Session Description, LCT Transport Session Description(또는, LCT Session Description), 및/또는 딜리버리 오브젝트 메타데이터(또는, Object metadata)를 포함할 수 있다. ROUTE Session Description은 ROUTE Session과 관련된 시그널링 정보를 포함할 수 있다. LCT Transport Session Description은 LCT Transport Session과 관련된 시그널링 정보를 포함할 수 있다. 딜리버리 오브젝트 메타데이터는 딜리버리 오브젝트와 관련된 시그널링 정보를 포함할 수 있다.
시그널링 정보는(예를 들어, 서비스 시그널링)은 서비스 발견 및 디스트립션 정보를 제공할 수 있다. 시그널링 정보는 부트스트래핑 시그널링 정보(Fast Information Table, FIT) 및/또는 서비스 레이어 시그널링 정보(Service Layer Signaling, SLS)을 포함할 수 있다. 이러한, 시그널링 정보는 적어도 하나의 사용자 서비스를 발견하거나 획득하기 위해서 필요한 정보를 포함할 수 있다.
FIT는 수신기가 기본적인 서비스 리스트를 만들고(build), 각각의 서비스를 위한 서비스 레이어 시그널링의 발견(discovery)을 부트스트랩(bootstrap)할 수 있도록 한다. 실시예에 따라, FIT는 SLT(Service List Table)로 표현할 수도 있다. FIT(또는, SLT)는 링크 레이어 시그널링을 통해서 전송될 수 있다. 또한, FIT(또는, SLT)는 신속한 획득을 위해서 각각의 물리적 레이어 프레임 내에서 전송될 수 있다. 실시예에 따라, FIT(또는, SLT)는 Physical Layer Frame, signaling을 전송하는 PLP, 및/또는 방송국마다 할당된 PLP 중에서 적어도 하나를 통해서 전송될 수 있다.
SLS는 수신기가 적어도 하나의 서비스 및/또는 적어도 하나의 콘텐트 컴포넌트를 발견(discovery)하고 엑세스(access)할 수 있도록 한다. 브로드캐스트를 통해서 전송되는 경우, SLS는 ROUTE/UDP/IP에 의해서 ROUTE 세션에 포함되는 적어도 하나의 LCT 전송 세션 내에서 전송될 수 있다. 이때, SLS는 빠른 채널 조인 및 스위칭을 지원하는 적절한 캐러셀 레이트(suitable carousel rate)로 전송될 수 있다. 브로드밴드를 통해서 전송되는 경우, SLS는 HTTP(S)/TCP/IP에 의해서 전송될 수 있다.
LSID는 ROUTE session을 통해서 전송되는 모든 전송 세션(transport session)들을 서술할 수 있다. LSID는 LCT transport session들을 포함하는 ROUTE session과 동일한 ROUTE session을 통해서 전송되거나 ROUTE session외의 수단에 의해서 전송될 수 있다. 예를 들어, LSID는 유니캐스트(unicast) 또는 다른 ROUTE session을 통해서 전송될 수 있다.
S-TSID는 적어도 하나의 ROUTE session, ROUTE에 포함된 적어도 하나의 LCT session, 및/또는 적어도 하나의 MMTP session에 대한 전체적인 전송 세션 디스크립션 정보(overall transport session description information)를 포함하는 SLS metadata fragment이다. ROUTE session 및/또는 MMTP session을 통해서 서비스에 포함된 적어도 하나의 미디어 콘텐트 컴포넌트가 전송될 수 있다. 또한, S-TSID는 서비스에 포함되는 적어도 하나의 LCT session에서 전송되는 딜리버리 오브젝트(Delivery Object) 및/또는 오브젝트 플로우에 대한 file metadata 및/또는 디스크립션(description)을 포함할 수 있다. 또한, S-TSID는 페이로드 포맷들 및/또는 적어도 하나의 LCT session에서 전송되는 적어도 하나의 콘텐트 컴포넌트에 대한 부가 정보를 포함할 수 있다.
제1 정보는 상기 전송 세션을 통해 전송되는 소스 데이터를 서술하는 제2 정보를 포함할 수 있다. 예를 들어, 제2 정보는 The SourceFlow 엘리먼트 를 포함할 수 있다. SourceFlow 엘리먼트는 세션 내의 소스 플로우를 정의할 수 있다.
제2 정보는 파일 딜리버리 데이터의 세부사항들을 명시하는 EFDT element, EFDT element를 식별하는 idRef attribute, 딜리버리 오브젝트가 실시간으로 전송되는지 여부를 지시하는 realtime attribute, 수신기에 저장되기 위해서 필요한 데이터의 최대 양(maximum amount of data)을 정의하는 minBufferSize attribute, 어플리케이션에 매핑될 수 있는 정보를 제공하는 ApplicationIdentifier element, 및/또는 딜리버리 오브젝트를 전송하는 패킷의 페이로드 포맷을 정의하는 PayloadFormat element 중에서 적어도 하나를 포함할 수 있다.
PayloadFormat element는 페이로드를 위하여 무슨 CodePoint 값이 사용되는지 정의하는 codePoint attribute, 딜리버리 오브젝트의 페이로드 포맷을 명시하는 deliveryObjectFormat attribute, 딜리버리 오브젝트의 단위를 지시하는 fragmentation attribute, 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전송 순서를 지시하는 deliveryOrder attribute, Source FEC Payload ID 의 포맷을 정의하는 sourceFecPayloadID attribute, 및/또는 FEC parameter들을 정의하는 FECParamenters element 중에서 적어도 하나를 포함할 수 있다.
EFDT element 는 EFDT element 를 식별하는 idRef attribute, EFDT element의 버전을 지시하는 version attribute, 전송 세션에 있는 오브젝트에 대한 최대 만료 시간을 지시하는 maxExpiresDelta attribute, EFDT element에 의해서 서술되는 오브젝트의 최대 전송 크기를 지시하는 maxTransportSize attribute, 및/또는 파일의 Uniform Resource Locator(URL)을 명시하는 FileTemplate element 중에서 적어도 하나를 포함할 수 있다.
방송 송신 장치는, 전송부를 이용하여, 적어도 하나의 딜리버리 오브젝트 및 시그널링 정보를 단방향 채널(unidirectional channel)을 통해서 전송할 수 있다(CS13300).
예를 들어, 방송 송신 장치는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 LCT 패킷을 이용하여 전송할 수 있다.
패킷의 전달 순서는 임의적이나, 다른 제한 조건이 없는 경우 시작 오프셋 번호가 증가하는 순으로 전달하는 것이 권장된다. 어떤 애플리케이션들은 시작 오프셋 번호가 증가하는 순으로의 엄격한 전송 순서를 요구할 수 있다.
다른 경우에는, 데이터의 빠른 부분들을 전송 하기 전에는 전송 길이가 알려지지 않을 수 있으며, 최대 전송 길이만 EFDT 파라미터인 @route:maxTransportSize에서 시그널링되는 바와 같이 알려진다. 이 경우, T는 나중에 결정될 수 있다. 그러나 이는 상기 전송 과정에 영향을 주지 않는다. 추가적인 패킷들은 앞서의 규칙들을 따라 전송 될 수 있다. 이 경우, B flag는 오브젝트의 마지막 부분을 포함하는 페이로드에 대해 오직 ‘1’로 설정되게 된다.
따라서, 방송 송신 장치는 object-based media data를 방송망을 통하여 실시간 전송할 수 있다.
도 14는 본 발명의 일 실시예에 따른 방송 수신 장치를 나타낸 도면이다.
방송 수신 장치의 제어부(C14250)는 ROUTE Receiver(C142530) 및/또는 DASH Client(C142550; Application/DASH player) 중에서 적어도 하나를 포함할 수 있다.
ROUTE Receiver(C142530)는 방송 서비스를 수신하고, 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. ROUTE Receiver(C142530)는 방송 서비스를 포함하는 패킷을 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. ROUTE Receiver(C142530)는 Packet Receiver(미도시), 시그널링 파서(C142532; LSID), 딜리버리 오브젝트 프로세서(C142533; Object Recovery 또는 Delivery Object Recovery), 및/또는 Delivery Object Cache(C142537; Delivery Object Processing) 중에서 적어도 하나를 포함할 수 있다.
Packet Receiver는 방송 서비스를 포함하는 적어도 하나의 패킷을 수신할 수 있다. 예를 들어, 패킷은 LCT 패킷을 포함할 수 있다.
시그널링 파서(C142532)는 서비스의 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출할 수 있다.
시그널링 정보는 서비스의 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션을 서술하는 제1 정보를 포함할 수 있다. 예를 들어, 제1 정보는 Service Layer Signaling(SLS), LCT Session Instance Description(LSID), 및/또는 Service-based Transport Session Instance Description(S-TSID)를 포함할 수 있다. 제1 정보는 상기 전송 세션을 통해 전송되는 소스 데이터를 서술하는 제2 정보를 포함할 수 있다. 예를 들어, 제2 정보는 The SourceFlow 엘리먼트 를 포함할 수 있다. SourceFlow 엘리먼트는 세션 내의 소스 플로우를 정의할 수 있다.
딜리버리 오브젝트 프로세서(C142533)는 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. 딜리버리 오브젝트 프로세서(C142533)는, Delivery Object Recovery를 이용하여, 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 소스 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
도면에서는 기본적인 수신기 동작을 개관하는 도면이다. 수신기는 패킷을 수신하고, 그에 따라 이 패킷들을 필터링한다. 수신기는 ROUTE 세션 및 포함된 각 LCT 전송 세션으로부터, 적절한 핸들러에 넘겨지는 딜리버리 오브젝트를 재생하여, 데이터를 처리하도록 한다.
기본적인 수신기 정보가 아래 제공되어 있다. 또한, 수신된 상이한 오브젝트들의 경우의 처리는 본장의 나머지 부분에서 다룬다.
LCT Session Instance Description (LSID)는 전송된 오브젝트 플로우를 기술하는 정보를 포함한다. 각 페이로드를 수신하면, 신기는 나열된 순서의 다음 단계로 진행한다.
먼저, ROUTE receiver는 LCT 및 ROUTE (ALC) 헤더를 파싱하고, 유효한 헤더인지 확인한다. 유효하지 않은 경우, 페이로드는 더 이상의 처리 없이 버려지게 된다.
둘째, ROUTE receiver는, TSI 및 CodePoint가 LSID에서 유효한 동작 포인트들을 제공함을, 즉 LSID가 패킷 헤더에서 제공되는 TSI 값에 대한 엔트리와, LCT header에서 PayloadFormat@codePoint가CodePoint 필드의 값으로 설정되 엔트리를 포함하는 이 TSI에 대한 엔트리도 포함함을 확인하게 된다.
셋째, ROUTE receiver는 다른 페이로드 헤더 필드들을 적절하게 해석하는 것과, (시작 오프셋을 유도하기 위한) source FEC Payload ID 및 페이로드 데이터를 이용하여 다음과 같이 해당 오브젝트를 재구성 하는 것을 포함하여 페이로드의 나머지 부분을 처리해야 한다.
a. ROUTE receiver는 LSID를 통해 수신된 ROUTE 패킷 페이로드 및 LCT header에서 전송된 TOI와 연관된 오브젝트를 결정할 수 있다.
b. 오브젝트에 대한 첫 번째 ROUTE 페이로드를 수신하면, ROUTE receiver는 EFDT의 maxTransportSize 속성을 사용하여 오브젝트의 최대 길이 T'를 결정한다
c. ROUTE receiver는 오브젝트가 차지할 수 있는T' 바이트를 위한 버퍼 공간을 할당한다.
d. The ROUTE receiver는 또한 수신된 페이로드에 총길이에서 페이로드 헤더 길이를 빼서 페이로드의 길이 Y를 연산한다.
e. ROUTE receiver는, 수신된 오브젝트 심볼들을 추적하도록 모든 T 엔트리가 false로 초기화된 불 어레이(Boolean array) RECEIVED[0..T'-1]를 할당한다. ROUTE receiver는, RECEIVED에서 false로 설정된 적어도 하나의 엔트리가 있는 한, 또는 오브젝트가 만료될 때가지, 또는 애플리케이션이 오브젝트를 포기하기로 결정 할 때까지 계속 오브젝트 블록에 대한 페이로드를 수신 한다. 보다 상세한 내용은 아래에서 설명한다.
f. (첫번째 페이로드를 포함한) 오브젝트에 대해 수신된 각 ROUTE 페이로드에 대해, 오브젝트의 복원을 돕기 위해 수행할 단계들은 다음과 같다. i) X를 ROUTE 패킷 헤더에 있는 start_offset 필드의 값으로 하고, Y를 페이로드에 길이로 하고, 수신된 패킷의 전체 길이에서 LCT header 크기와 ROUTE (ALC) header 크기를 빼서 Y를 연산한다. ii) ROUTE receiver는 오브젝트를 위해 예비된 공간 내의 적절한 자리에 데이터를 복사하고 RECEIVED[X ... X+Y-1] = true으로 설정한다. iii) RECEIVED의 모든 T 엔트리가 true이면, receiver는 전체 오브젝트를 복원한 것이다.
g. B flag가 1로 설정된 ROUTE 패킷을 수신하면, ROUTE receiver는 오브젝트의 전송 길이 T를 해당 ROUTE 페이로드의 X+Y로 결정하고 불 어레이 RECEIVED[0..T'-1]를 RECEIVED[0..T-1]로 조정할 수 있다.
완전한 TOI가 복원되면, 딜리버리 오브젝트를 위한 메타데이터가 복원되고, 오브젝트는 애플리케이션에 전달된다.
메타데이터의 복원은 적용된 전달 모드에 달려 있다.
딜리버리 오브젝트가 수신되는 경우, 이는 애플리케이션에서 수신된 딜리버리 오브젝트를 이용할 수 있다는 것과 관련이 있다. 일반적으로, 딜리버리 오브젝트는 완전하고 그대로인 경우에만 애플리케이션에 전달된다.
그러나 어떤 환경에서는 애플리케이션 API에서 허용하거나 충분한 메타데이터가 이용가능하여 이러한 핸들링을 할 수 있을 경우에는 부분적으로 수신된 오브젝트가 전달될 수 있다. 이를 위해 정의된 한 가지 메커니즘이 3GPP TR 26.946에 기술되어 있다. 파일 모드에서 오브젝트가 수신되는 경우에는, 확장된 FDT를 이용하여 모든 메타데이터를 복원한다. 엔티티 모드에서 오브젝트가 수신되는 경우에는, RFC 2616에 따라 엔티티 헤더와 엔티티 바디가 처리된다. 패키지 모드에서 딜리버리 오브젝트가 수신되는 경우에는, receiver에서 파일들을 애플리케이션에 전달하기 전에 파일의 패키지를 해제하여 패키지에 포함된 메타데이터를 제공한다.
Delivery Object Cache(C142537)는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 저장하고, 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 DASH Client(C142550)로 전달할 수 있다. Delivery Object Cache(C142537)는 타이밍 정보를 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 DASH Client(C142550)로 전달할 수 있다.
DASH Client(C142550)는 방송 서비스를 디코딩할 수 있다. DASH Client(C142550)는 애플리케이션을 이용하여 적어도 하나의 딜리버리 오브젝트를 디코딩할 수 있다. 애플리케이션은 적어도 하나의 딜리버리 오브젝트를 소비할 수 있다. 예를 들어, 애플리케이션은 DASH Media Presentation을 포함할 수 있다.
도 15는 본 발명의 일 실시예에 따른 방송 수신 장치의 흐름도를 나타낸 도면이다.
방송 수신 장치는 방송망(예를 들어, 브로드캐스트) 및/또는 인터넷망(예를 들어, 브로드밴드) 중에서 적어도 하나를 이용하여 방송 서비스를 수신하고, 방송 서비스를 디코딩할 수 있다. 방송 수신 장치는 브로드캐스트 인터페이스, 브로드밴드 인터페이스, 및/또는 제어부 중에서 적어도 하나를 포함할 수 있다. 방송 수신 장치의 제어부는 ROUTE Receiver 및/또는 DASH Client 중에서 적어도 하나를 포함할 수 있다. ROUTE Receiver는 Packet Receiver, 시그널링 파서, 딜리버리 오브젝트 프로세서, 및/또는 Delivery Object Cache 중에서 적어도 하나를 포함할 수 있다. 방송 수신 장치의 구체적인 내용은 전술한 바와 동일하다.
방송 수신 장치는 브로드캐스트 인터페이스 및/또는 브로드밴드 인터페이스 중에서 적어도 하나를 이용하여 방송 서비스를 포함하는 방송 신호를 수신할 수 있다. 예를 들어, 방송 수신 장치는 서비스를 포함하는 방송 신호를 단방향 채널(unidirectional channel)을 통해서 수신할 수 있다(CS15100).
방송 수신 장치는 제어부를 이용하여 서비스의 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출할 수 있다(CS15200).
시그널링 정보는 서비스의 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션을 서술하는 제1 정보를 포함할 수 있다. 예를 들어, 제1 정보는 Service Layer Signaling(SLS), LCT Session Instance Description(LSID), 및/또는 Service-based Transport Session Instance Description(S-TSID)를 포함할 수 있다. 또는, 시그널링 정보는 ROUTE Session Description, LCT Transport Session Description(또는, LCT Session Description), 및/또는 딜리버리 오브젝트 메타데이터(또는, Object metadata)를 포함할 수 있다.
제1 정보는 상기 전송 세션을 통해 전송되는 소스 데이터를 서술하는 제2 정보를 포함할 수 있다. 예를 들어, 제2 정보는 The SourceFlow 엘리먼트 를 포함할 수 있다. SourceFlow 엘리먼트는 세션 내의 소스 플로우를 정의할 수 있다.
제2 정보는 파일 딜리버리 데이터의 세부사항들을 명시하는 EFDT element, EFDT element를 식별하는 idRef attribute, 딜리버리 오브젝트가 실시간으로 전송되는지 여부를 지시하는 realtime attribute, 수신기에 저장되기 위해서 필요한 데이터의 최대 양(maximum amount of data)을 정의하는 minBufferSize attribute, 어플리케이션에 매핑될 수 있는 정보를 제공하는 ApplicationIdentifier element, 및/또는 딜리버리 오브젝트를 전송하는 패킷의 페이로드 포맷을 정의하는 PayloadFormat element 중에서 적어도 하나를 포함할 수 있다.
PayloadFormat element는 페이로드를 위하여 무슨 CodePoint 값이 사용되는지 정의하는 codePoint attribute, 딜리버리 오브젝트의 페이로드 포맷을 명시하는 deliveryObjectFormat attribute, 딜리버리 오브젝트의 단위를 지시하는 fragmentation attribute, 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전송 순서를 지시하는 deliveryOrder attribute, Source FEC Payload ID 의 포맷을 정의하는 sourceFecPayloadID attribute, 및/또는 FEC parameter들을 정의하는 FECParamenters element 중에서 적어도 하나를 포함할 수 있다.
EFDT element 는 EFDT element 를 식별하는 idRef attribute, EFDT element의 버전을 지시하는 version attribute, 전송 세션에 있는 오브젝트에 대한 최대 만료 시간을 지시하는 maxExpiresDelta attribute, EFDT element에 의해서 서술되는 오브젝트의 최대 전송 크기를 지시하는 maxTransportSize attribute, 및/또는 파일의 Uniform Resource Locator(URL)을 명시하는 FileTemplate element 중에서 적어도 하나를 포함할 수 있다.
방송 수신 장치는 제어부를 이용하여 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다(CS15300).
방송 수신 장치는 제어부를 이용하여 방송 서비스 및/또는 적어도 하나의 딜리버리 오브젝트를 디코딩할 수 있다.
도 16은 본 발명의 일 실시예에 따른 방송 수신 장치의 FEC 패킷 생성을 나타낸 도면이다.
상기의 프로토콜로 전달되는 딜리버리 오브젝트 및 딜리버리 오브젝트들의 묶음들은 FEC로 보호될 수 있다. 베이스 프로토콜은 임의의 FEC 특정적 시그널링을 포함하는 것을 피한다.
소스 프로토콜을 사용할 때 개개의 딜리버리 오브젝트 또는 딜리버리 오브젝트 묶음에 대한 FEC 보호를 가능하게 하는 FEC framework가 정의된다. FEC framework는 기존의 FLUTE/ALC/LCT 사양(specifications)에서 채택된 RFC 5052의 FEC building block뿐만 아니라 RFC 6363에서 정의된 FECFRAME work의 개념을 사용한다.
FEC 설계는 다음의 원칙들을 준수한다. FEC 관련 정보는 필요한 곳에만 제공된다. 이러한 프레임워크가 불가능한 수신기들은 리페어 패킷을 무시할 수 있다. FEC는 보호되는 리페어 플로우당 고정된 심볼 크기로 심볼을 기초로 한다. ALC 프로토콜 및 기존의 FEC 스킴들을 재사용한다. FEC 리페어 플로우는 하나 이상의 소스 플로우로부터의 딜리버리 오브젝트의 보호를 제공한다. FEC framework의 FEC 특정 컴포넌트들은 FEC 리페어 플로우 선언, FEC transport object, FEC super object, FEC 프로토콜, 및/또는 packet structure이다. FEC 리페어 플로우 선언은 모든 FEC 특정 정보를 포함한다. FEC transport object는 데이더의 심볼 정렬 청크(symbol-aligned chunk) 형성을 위한 딜리버리 오브젝트, 패딩 옥텟 및 크기 정보의 연결(concatenation)이다. FEC super object는 FEC 보호를 위해 FEC transport object들을 번들링하기 위한 하나 이상의 FEC transport object를 연결한 것이다.
수신기는 이용가능한 FEC 정보를 기초로 리페어 패킷으로부터 딜리버리 오브젝트를 복원할 수 있어야 한다.
FEC Protocol specifies FEC Framework를 위한 프로토콜 엘리먼트들을 특정한다. 이 프로토콜의 컴포넌트 다섯 개를 정의하고 설명한다. 이 컴포넌트들은 1) FEC transport object 구성, 2) FEC transport object들의 연결인 FEC 수퍼 오브젝트(super-object) 구성, 3) TOI 매핑, 및/또는 4) 리페어 패킷 생성이다.
FEC Framework의 동작은 Repair Flow 정의에 의해 좌우된다.
도면에서는 두 개의 딜리버리 오브젝트에 기초한 FEC 패킷 생성을 도시한다.
FEC transport object 구성
Repair 프로토콜의 컨텍스트에서 딜리버리 오브제그를 식별하기 위해서, 다음과 같은 정보가 필요하다. 이 정보는 딜리버리 오브젝트의 TSI와 TOI이다. 또한, 이 정보는 딜리버리 오브젝트의 옥텟 범위, 즉 딜리버리 오브젝트 내의 시작 오프셋과 FEC object를 구성하는 딜리버리 오브젝트의 뒤이어 연속된 옥텟(즉, 소스 오브젝트의 FEC 보호를 받는 부분)의 개수이다..
일반적으로, 첫번째 매핑이 적용된다. 즉 딜리버리 오브젝트는 FEC Object이다.
각 딜리버리 오브젝트에 대해, 연관된 FEC transport object는 딜리버리 오브젝트, 패딩 옥텟(P) 및 옥텟 단위의 FEC object 크기(F)의 연결로 구성되며, 여기서 F는 4-octet 필드에서 전송된다. 심볼 단위로 된 FEC transport object 크기 S는 심볼 크기 T의 정수배가 된다.
S는 세션 정보 및/또는 리페어 패킷 헤더로부터 결정된다. F는 FEC transport object의 마지막 4 옥텟에서 전송된다.
구체적으로, F를 옥텟 단위의 딜리버리 오브젝트의 크기라고 하자. F를 딜리버리 오브젝트의 데이터의 F 옥텟이라고 하자. f는 네트워크 옥텟 순서(상위 옥텟 우선) 상 F의 값을 나르는 데이터의 네 개의 옥텟을 나타내는 것으로 한다. S be the size of the S=ceil((F+4)/T인 FEC transport object의 크기로 한다. P는 데이터의 S*T-4-F 제로 옥텟, 즉 딜리버리 오브젝트와 FEC transport object의 끝에 있는 F의 값 사이에 놓인 패딩이라고 하자. O는 F, P 및 f의 연결이라고 하자. 이때 O는 S*T 옥텟 크기의 FEC transport object를 구성한다. 여기서 유의할 점은, 패딩 옥텟과 오브젝트 크기 F는 딜리버리 오브젝트의 소스 패킷으로 전송되는 것이 아니라, 단지 FEC 오브젝트를 추출하기 위해 FEC 디코딩으로 복원하는 FEC transport object의 일부분으로서, 따라서 FEC 오브젝트를 구성하는 딜리버리 오브젝트 또는 딜리버리 오브젝트의 일부분이라는 점이다. 이러한 맥락에서, 심볼 단위의 FEC transport object 크기는 S이다.
FEC가 인에블링된 수신기에 전달되는 FEC transport object에 대한 일반적인 정보는 소스 TSI, 소스 TOI 및 연관된 FEC 오브젝트를 포함하는 딜리버리 오브젝트 내의 연관된 옥텟 범위이다. 그러나 FEC 오브젝트의 옥텟 크기는 FEC transport object 내의 appended 필드에서 제공됨에 따라, 나머지 정보는 FEC transport object와 연관된 FEC 오브젝트를 생성시키는 딜리버리 오브젝트의 TSI 및 TOI로서 전달될 수 있다. 그리고 나머지 정보는 연관된 FEC 오브젝트에 대한 딜리버리 오브젝트 내의 시작 옥텟으로 전달될 수 있다. 또한, 나머지 정보는 FEC transport object의 심볼 크기로 전달될 수 있다.
딜리버리 오브젝트를 위한 수퍼 오브젝트 및 FEC 리페어
FEC 리페어 플로우 선언으로부터 하나 이상의 FEC transport object의 연결인 FEC 수퍼 오브젝트의 구성을 결정할 수 있다. FEC 수퍼 오브젝트는 앞 절에서 설명한 FEC transport object에 대한 일반적인 정보와 FEC 수퍼 오브젝트 내 FEC transport object들의 순서를 포함한다. N은 FEC 수퍼 오브젝트 구성을 위한 FEC transport object의 총 개수라고 하자. 그리고 i = 0,…,N-1에 대해, S[i]는 FEC transport object i의 심볼 크기라고 하자. B는 K = sum (i=0) (N-1) S[i] 소스 심볼로 구성되고 순서대로 연결된 FEC transport object들인 FEC 수퍼 오브젝트라고 하자.
각각의 FEC 수퍼 오브젝트에 대해, FEC 수퍼 오브젝트를 구성하는 FEC transport object에서 이미 전성된 것 이 외에 FEC가 인에블링된 수신기에 전달되어야 할 나머지 일반 정보는 FEC transport object의 총 개수 N이다. 또한, And, 각각의 FEC 수퍼 오브젝트에 대해, FEC가 인에블링된 수신기에 전달되어야 할 나머지 일반 정보는 FEC transport object와 연관된 FEC 오브젝트를 생성시키는 딜리버리 오브젝트의 TSI 및 TOI, 연관된 FEC 오브젝트에 대한 딜리버리 오브젝트 내의 시작 옥텟, FEC transport object의 심볼 크기이다.
이 정보의 전송에 대해서는 아래에서 논의한다.
리페어 패킷 구조
리페어 프로토콜은 RFC 5775에서 정의된 Asynchronous Layered Coding (ALC)와 RFC 5651에서 정의된 LCT Layered Coding Transport (LCT) Building Block을 기초로 하며, 그 구체적인 내용은 다음과 같다.
RFC 5651에서 정의된 LCT Layered Coding Transport (LCT) Building Block은 Asynchronous Layered Coding (ALC)에서 정의된 대로 사용된다. 또한, 다음과 같은 제한조건들이 적용된다. LCT header 내의 TSI는 @tsi attribute에서 정의되는 바와 같이 해당 패킷이 적용되는 리페어 플로우를 식별하게 된다, SPI의 첫번째 비트는 0으로 설정 된다. 즉, 리페어 패킷을 지시한다. FEC 구성 정보는 LCT extension header에서 전송될 수 있다.
FEC building block은 RFC 5053 및 RFC 6330에 따라 사용되지만, 리페어 패킷만 전달되어야 한다. (LCT header 내의 TSI 필드에 의해 지시된) 리페어 플로우의 범위 내의 각 리페어 패킷은 적절한 리페어 TOI를 전송하게 된다. 리페어 TOI는 TSI의 범위 내에서 생성된 각 FEC 수퍼 오브젝트에 대해 고유하다.
FEC 정보 요약
(Repair Flow 내의 고유 TOI에 의해 식별되고 LCT header 내의 TSI 에 의해 Repair Flow에 연관되는) 생성된 각 수퍼 오브젝트에 대해, 다음과 같은 정보들이 수신기에 전달되어야 한다. 예를 들어, FEC 인코딩ID, FEC OTI, 및/또는 추가적인 FEC 정보를 포함하는 FEC 구성. 또한, FEC 수퍼 오브젝트에 포함된 FEC 오브젝트의 총 개수. 또한, 각 FEC transport object에 대해, FEC transport object와 연관된 FEC 오브젝트를 생성하기 위해 사용된 딜리버리 오브젝트 TSI 및 TOI, 적용 가능한 경우 연관된 FEC 오브젝트의 딜리버리 오브젝트 내의 시작 옥텟, 및/또는 FEC transport object의 심볼 크기.
이러한 정보는 RepairFlow declaration에서 정적으로 전달되고, 및/또는 dynamically in an LCT extension header에서 동적으로 전달되고, 및/또는 상기의 조합 등으로 전달될 수 있다.
도 17은 본 발명의 일 실시예에 따른 FEC Transport Object를 나타낸 도면이다.
도면에서는 FEC Transport Object 구성(S = 3인 예)를 도시한다
도 18은 본 발명의 일 실시예에 따른 EXT_TOL Header를 나타낸 도면이다.
EXT_FTI 또는 EXT_TOL header 중의 하나는 임의의 관련 FEC Transport Information를 추출하기 위해 사용된다.
도면에서는 EXT_TOL24 및 EXT_TOL56 Header를 도시한다. transport object length의 분산을 가능하게 하는 것은 확장 헤더이다. Transfer Length의 크기는 24 비트 또는 56 비트일 수 있다.
도 19는 본 발명의 일 실시예에 따른 RepairFlow Element를 나타낸 도면이다.
ATSC 서비스이 전달에 있어, 리페어 플로우 선언은 번들 디스크립션(bundle description) 또는 사용 서비스 디스크립션(use service description)의 일부로서 포함될 수 있다.
@tsi attribute 내의 리페어 플로우에 대해 리페어 플로우 선언의 일부인 리페어 플로우 식별자가 제공되며, 모든 리페어 플로우는 RepairFlow 타입으로 선언된다. IP 주소, 포트 및 리페어 플로우 식별자의 조합으로 사용자 서비스 내의 모든 플루우 중에서 고유 식별자를 제공한다. 주목할 점은 IP/포트 조합은 소스 데이터뿐만 아니라 상일한 FEC 리페어 데이터도 전송할 수 있다는 것이다. 이 경우, 데이터는 LCT header 내의 상이한 TSI 값들에 의해 구별된다.
리페어 플로우 선언은 리페어 플로우에 의해 보호될 소스 플로우로부터의 딜리버리 오브젝트의 패턴(또는 딜리버리 오브젝트의 옥텟 범위)를 지시한다.
도면에서는 리페어 플로우의 시맨틱을 도시하고 있다.
RepairFlow 엘리먼트는 세션 내의 리페어 플로우를 정의한다. RepairFlow 엘리먼트는 FECParameters 엘리먼트를 포함한다. FECParameters 엘리먼트는 FEC parameter들(필요에 따라 더 나은 구조화가 적절할 수 있다)을 정의한다. FECParameters 엘리먼트는 fecEncodingId attribute, maximumDelay attribute, overhead attribute, minBufferSize attribute, FECOTI 엘리먼트, 및/또는 ProtectedObject 엘리먼트 중 적어도 하나를 포함할 수 있다.
fecEncodingId attribute는 적용되는 FEC 스킴을 지정한다.
maximumDelay attribute는 소스 플로우 내의 임의의 소스 패킷과 리페어 플로우 사이의 최대 전달 지연을 지정한다.
overhead attribute는 퍼센트 오버헤드를 지정한다.
minBufferSize attribute는 요구되는 버퍼 크기를 지정한다. 이 속성은 존재하는 경우, 수퍼 오브젝트에 할당된 모든 연관된 오브젝트를 다루기 위해 요구되는 최소 버퍼 크기를 정의한다.
The FECOTI 엘리먼트는 RFC 5052에서 정의된 FEC Object Transmission Information (FEC OTI)를 지정한다. FEC OTI는 해당 선언 내에 포함되는 오브젝트의 인코딩 심볼들과 연관된 FEC 정보뿐만 아니라 오브젝트와 연과된 FEC 관련 정보에도 대응하며, 리페어 플로우를 가진 모든 리페어 패킷에 적용된다.
ProtectedObject 엘리먼트는, 이 리페어 플로우에 의해 보호되는 소스 플로우 및 보호가 어떻게 이루어지는 지에 대한 세부 사항을 지정한다.
도 20은 본 발명의 일 실시예에 따른 ProtectedObject Element를 나타낸 도면이다.
ProtectedObject Element는 오브젝트 모음 중 소정의 딜리버리 오브젝트들이 리페어 플로우 내에 어떻게 포함되는 지를 정의한다. ProtectedObject Element는 sessionDescription attribute, tsi attribute, sourceTOI attribute 및/또는 fecTransportObjectSize attribute 중 적어도 하나를 포함한다.
The sessionDescription attribute는 소스 플로우를 포함하는 세션 디스크립션을 참조한다. 존재하지 않는 경우, 소스 플로우는 리페어 플로우와 동일한 세션에 포함된다.
tsi attribute는 보호될 소스 플로우에 대한 전송 세션 식별자를 지정한다.
sourceTOI attribute는 리페어 플로우에 포함된 TOI에 대응하는 딜리버리 오브젝트의 TOI를 지정한다. 만일 존재하지 않는 경우, 소스 TOI는 리페어 TOI와 동일하다.
fecTransportObjectSize attribute는 심볼 단위로 각 FEC transport object의 기본 크기(default size)를 지정한다. 만일 존재하지 않는 경우, 이 값들은 EXT_TOL header를 이용하여 리페어 패킷에서 제공하게 된다. 만일 존재하는 경우, EXT_TOL header는 존재하지 않게 된다.
TOI 매핑
리페어 플로우 선언에 ProtectedObject가 포함된 경우, @sourceTOI attribute는 리페어 패킷에 포함된 리페어 TOI 값을 리페어 패킷이 보호하는 딜리버리 오브젝트의 소스 TOI에 매핑하는 것을 지정한다.
이 매핑은 C 언어 형식의 수식을 통해 기술되는데, 리페어 플로우의 TOI 필드는 변수 TOI로 지정되고, 수식의 결과는 소스 TOI를 결정한다. 이 속성의 값은 최대 한 개의 변수 TOI를 가지고 ";" 기호가 추가되지 않은 적절한 C 수식이 된다. ProtectedObject에서 @sourceTOI attribute가 제공되지 않는 경우, 기본 수식으로 sourceTOI="TOI"가 적용되어 리페어 TOI로부터 소스 TOI 를 유도하게 된다.
도 21은 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도면에서, TSI 값 10과 TOI 20을 가진 리페어 패킷은 TSI 1을 가진 소스 플로우로부터 TOI 20을 가진 딜리버리 오브젝트를 보호한다. FEC transport object 크기가 정의되며, 892개의 심볼이다. 이하에서 리페어 플로우 선언을 설명한다.
도 22는 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도면에서는, ProtectedObject에 @sourceTOI attribute가 제공되어 있지 않으므로, 기본 수식으로 sourceTOI="TOI"를 사용하여 TOI로부터 소스 TOI를 유도한다. 그래서 TSI 11 및 TOI 20을 가진 리페어 패킷에 의해 보호되는 수퍼 오브젝트는 TSI 2 및 TOI 20을 가진 딜리버리 오브젝트에 대한 FEC transport object와 with and the for the TSI 3 및 TOI 20을 가진 딜리버리 오브젝트에 대한 FEC transport object를 연결한 것이 된다. 두 경우에 있어 FEC transport object의 크기가 정의되고, FEC 수퍼 오브젝트는 총 2232 개의 심볼의 크기를 가진다.
세 개의 플로우는 모두 동일한 세션에서 전달된다.
도 23은 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도면에서, TSI 12와 TOI 20을 가진 리페어 패킷에 의해 보호되는 FEC 수퍼 오브젝트는 TSI 4와 TOI 40을 가진 딜리버리 오브젝트에 대한 FEC transport object, TSI 5와 TOI 20을 가진 딜리버리 오브젝트에 대한 FEC transport object 및 TSI 4와 TOI 41을 가진 딜리버리 오브젝트에 대한 FEC transport object를 연결한 것(concatenation)이다. 본 예에서, 딜리버리 오브젝트들의 FEC transport object 크기는 리페어 플로우 선언에 포함되지 않는다.
여기서, RepairFlow 선언 내의 ProtectedObject 선언들의 시퀀스는 수퍼 오브젝트 내 딜리버리 오브젝트들에 대한 FEC transport object들의 순서를 결정한다.
도 24는 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도면에서, TSI 13과 TOI 20을 가진 리페어 패킷은 TSI 6과 TOI 21을 가진 딜리버리 오브젝트를 보호한다.
도 25는 본 발명의 일 실시예에 따른 RepairFlow Declaration을 나타낸 도면이다.
도면에서, TSI 14와 TOI 10을 가진 리페어 패킷은 두 개의 딜리버리 오브젝트, 즉 TSI 7과 TOI 20을 가진 딜리버리 오브젝트와 TSI 7과 TOI 21을 가진 딜리버리 오브젝트에 대한 FEC transport object들의 연결을 보호한다. TSI 14를 가진 아래와 같은 리페어 플로우 선언은 정적 FDD를 제공한다.
FEC 수퍼 오브젝트 내의 FEC transport object들의 순서는 RepairFlow 선언에서 ProtectedObject 선언들이 이루어지는 순서와 동일하다. 따라서, 예시 5에서, TSI 14와 TOI 10을 가진 리페어 패킷에 대응하는 FEC 수퍼 오브젝트 TSI 7과 TOI 20을 가진 딜리버리 오브젝트에 대한 FEC transport object와 TSI 7과 TOI 21을 가진 딜리버리 오브젝트에 대한 FEC transport object를 연결한 것이다.
도 26는 본 발명의 일 실시예에 따른 방송 수신 장치를 나타낸 도면이다.
방송 수신 장치의 제어부(C26250)는 ROUTE Receiver(C262530) 및/또는 DASH Client(C262550; Application/DASH player) 중에서 적어도 하나를 포함할 수 있다.
ROUTE Receiver(C262530)는 방송 서비스를 수신하고, 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. ROUTE Receiver(C262530)는 방송 서비스를 포함하는 패킷을 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. ROUTE Receiver(C262530)는 Packet Receiver(미도시), 시그널링 파서(C262532; LSID), 딜리버리 오브젝트 프로세서(C262535; Delivery Object Recovery and FEC), 및/또는 Delivery Object Cache(C262537; Delivery Object Processing) 중에서 적어도 하나를 포함할 수 있다. 딜리버리 오브젝트 프로세서(C262535)는 Object Recovery 및/또는 FEC decoder 중에서 적어도 하나를 포함할 수 있다.
Packet Receiver는 방송 서비스를 포함하는 적어도 하나의 패킷을 수신할 수 있다. 예를 들어, 패킷은 LCT 패킷을 포함할 수 있다.
시그널링 파서(C142532)는 서비스의 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출할 수 있다.
시그널링 정보는 서비스의 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션을 서술하는 제1 정보를 포함할 수 있다. 예를 들어, 제1 정보는 Service Layer Signaling(SLS), LCT Session Instance Description(LSID), 및/또는 Service-based Transport Session Instance Description(S-TSID)를 포함할 수 있다. 제1 정보는 상기 전송 세션을 통해 전송되는 소스 데이터를 서술하는 제2 정보를 포함할 수 있다. 예를 들어, 제2 정보는 SourceFlow 엘리먼트 및/또는 RepairFlow element를 포함할 수 있다. SourceFlow 엘리먼트는 세션 내의 소스 플로우를 정의할 수 있다. RepairFlow element 는 세션 내의 리페어 플로우를 정의할 수 있다.
딜리버리 오브젝트 프로세서(C262535)는, Object Recovery를 이용하여, 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. Object Recovery는 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 소스 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
딜리버리 오브젝트 프로세서(C262535)는, FEC Decoder를 이용하여, 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 리페어 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. 예를 들어, FEC Decoder는 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 리페어 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
강인한(robust) 수신의 경우, FEC가 적용될 수 있다. 이 경우, 소스 패킷 스트림과 함께 하나 또는 복수의 리페어 플로우들이 전송된다. 리페어 플로우들은 RepairFlow 디스크립션에 기술된다.
ROUTE 환경에서의 관련된 양태는 착신 LCT 패킷 및 리페어 패킷 플로우를 포함할 수 있는 LSID에서 제공되는 추가적인 정보에 기초하여 딜리버리 오브젝트를 복원하는 것이다. 서로 다른 선택사항들이 있다. 예를 들어, FEC는 전혀 제공되지 않으면서 소스 패킷으로부터 패킷이 복원된다. 각 딜리버리 오브젝트에 대해 FEC가 개별적으로 제공된다. 다수의 딜리버리 오브젝트 상으로 하나의 FEC가 제공된다. 상이한 딜리버리 오브젝트 세트 상으로 다수의 FEC 스트림이 제공된다.
또한, FEC 스트림 중 어느 것도 사용하지 않거나 하나 또는 복수의 스트림을 사용하기로 결정하는 것은 수신기에 달려 있다. 따라서, 각 플로우는 일반적으로 개별적인 복원 특성을 할당받으며, 이 특서은 하나 또는 다른 것이 선택되는 경우 지연 및 요구되는 메모리와 같은 형태들을 정의한다. 수신기는 동작 모드에 따라 하나 또는 복수의 리페어 플로우를 선택할 수 있다. 고려 사항들 중 다음과 같은 고려 사항들을 기초로 수신기는 리페어 플로우를 선택하거나 선택하지 않기고 결정할 수 있다.
첫번 째 고려 사항은 원하는 스타트업(start-up) 및 단대단(end-to-end) 레이턴시이다. 리페어 플로우가 효과를 내기 위해 상당한 양의 버퍼링 시간을 요구하는 경우, 그러한 리페어 플로우는 타임 쉬프트(time-shift) 동작이나 더 열악한 상황에서만 사용될 수 있이지, 단대단(end-to-end) 레이턴시를 희생하게 된다.
두번 째 고려 사항은 FEC 능력(capabilities)으로서, 즉 수신기는 지원하는 FEC 알고리즘만 선택이 가능할 수 있다.
세번 째 고려 사항은 포함되는 보호받는 소스 플로우로서, 예를 들어 리페어 플로우가 수신기에 의해 선택되지 않는 소스 플로우를 보호하는 경우, 리페어 플로우를 선택하지 않을 수 있다.
기타 고려 사항으로는 버퍼의 크기, 수신 조건 등이 있다.
수신기가 어떤 리페어 플로우에 가입하는 경우, 리페어 플로우에 의해 보호되는 모든 소스 플로우에 가입하고, 관련 패킷을 수집해야 한다.
리페어 플로우에 의해 보호된 딜리버리 오브젝트를 복원할 수 있으려면, 수신기에서 이 Repair Flow에 의해 다루어지는 해당 딜리버리 오브젝트들의 모음을 기술하는 요구되는 RepairFlow 프래그먼트를 얻어야 한다. 리페어 플로우는 보호되는 해당 소스 플로우 및 고유한 TSI 번호와 더불어 LCT 세션의 조합에 의해 정의된다.
수신기가 리페어 플로우에 가입하는 경우, 보호되는 모든 Transport Session들의 모든 패킷을 수집하게 된다.
각 패킷, 소스 또는 리페어 패킷을 수신하면, 수신기는 나열된 순서 상의 다음 단계로 진행한다.
먼저, 수신기는 패킷 헤더 헤더를 파싱하고, 유효한 헤더인지 확인한다. 유효하지 않은 경우, 패킷은 더 이상의 처리없이 버려지게 된다.
둘째, 수신기는 코드 TSI를 파싱하고, TSI가 Repair Flow 또는 연관된 Protected 소스 플로우에 연관되어 있는지를 확인한다. 유효하지 않은 경우, 패킷은 더 이상의 처리없이 버려지게 된다.
셋째, 수신기는 다른 헤더 필드들을 적절하게 해석하는 것과, 페이로드 데이터와 더불어 (소스 오브젝트에 대한 시작 바이트를 결정하는) FEC Payload ID 및 Repair FEC Payload ID를 이용하여 다음과 같이 수퍼 오브젝트에 해당하는 디코딩 블록을 재구성하는 것을 포함하여 패킷의 나머지 부분을 처리한다.
a) 소스 패킷의 경우, 수신기는 수신된 패킷이 어떤 딜리버리 오브젝트로부터 페이로드 헤더에서 전송된 TOI 및 세션 정보에 의해 생성되었는 지를 결정한다. 리페어 오브젝트의 경우, 수신기는 수신된 패킷이 어떤 수퍼 오브젝트를 위해 페이로드 헤더에서 전송된 TOI 및 세션 정보에 의해 생성되었는 지를 결정한다.
b) 소스 패킷의 경우, 수신기는 각 수퍼 오브젝트에 대한 데이터를 수집하여 수퍼 오브젝트를 복원한다. 그 다음, 수신된 수퍼 오브젝트는 소스 블록에 매핑되고, 해당 인코딩 심볼들이 생성된다.
c) 리페어 패킷이 수신되면 수퍼 오브젝트를 복원할 수 있다.
d) 수퍼 오브젝트가 복원되면, 각각의 딜리버리 오브젝트를 추출할 수 있다.
Delivery Object Cache(C262537)는 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 저장하고, 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 DASH Client(C262550)로 전달할 수 있다. Delivery Object Cache(C262537)는 타이밍 정보를 기초로 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 DASH Client(C262550)로 전달할 수 있다.
DASH Client(C262550)는 방송 서비스를 디코딩할 수 있다. DASH Client(C262550)는 애플리케이션을 이용하여 적어도 하나의 딜리버리 오브젝트를 디코딩할 수 있다. 애플리케이션은 적어도 하나의 딜리버리 오브젝트를 소비할 수 있다. 예를 들어, 애플리케이션은 DASH Media Presentation을 포함할 수 있다.
도 27는 본 발명의 일 실시예에 따른 MPD를 나타낸 도면이다.
MPEG-DASH 콘텐트의 전달은 단방향 전송을 통한 실시간 미디어의 전달을 가능하게 한다. MPEG-DASH 콘텐트는 레귤러 오브젝트로 간주될 수 있지만, 전달은 최적화되어 제어된 레이턴시, 제어된 결합 시간(joining time) 및 추가적인 최적화를 지원하도록 할 수 있다.
본 절에서는 라이브 서비스를 위한 적절한 MPEG-DASH 형식의 콘텐트, 소스 콘텐트의 전달을 위한 ROUTE의 사용, 적절한 패킷 스케줄링 및/또는 최적화된 수신기 동작을 살펴본다.
선형 TV 서비스에 적절한 MPEG-DASH 형식의 콘텐트
Baseline Technologies에 따르면, 인코딩된 비트스트림은 MPEG DASH ISO BMFF 라이프 프로파일에 따라 분할되고 패키화된다. 이는 Segment Template이 세그먼트들의 URL 어드레싱에 사용되는지와 각 세그먼트가 타입 1 또는 2의 스트림 액세스 포인트로 시작하는 지를 포함하지만, 이에 제한되는 것은 아니다.
또한, 비-멀티플렉싱된 Representation을 포함하여 (HEVC를 포함한) DASH-IF Interoperability Point의 설정을 적용하는 것이 권장된다. 다른 최적화들은 앞서 논의하였다.
기본적인 설정에 대해 살펴본다.
세그먼트 내의 미디어 데이터의 지속기간(세그먼트 지속기간)은 일반적으로 @duration attribute에 의해 일정하게 시그널링된다. 세그먼트 지속기간의 최대 허용 오차는 일반적으로 ±50%를 초과하지 않으며, 다수의 세그먼트 상의 최대 누적 편차는 시그널링 된 세그먼트 지속기간의 ±50%이다. 실제 세그먼트 지속기간의 이러한 변동은, 예를 들어 광고 교체(ad replacement) 또는 특정 IDR 프레임 배치에 의해 발생할 수 있다
비디오의 경우, 폭, 높이 및 프레임 레이트(frame rate)의 시그널링이 추가된다.
오디오의 경우, 언어에 대한 시그널링이 추가된다.
서브타이틀 또는 캡션의 경우, 서브타이틀 또는 캡션의 역할에 대한 시크널ㄹ이이 추가된다. 또한, 오디오의 언어와 다른 경우 언어에 대한 시그널링이 추가된다.
For providing a basic linear media streaming service based on DASH에 기초하여 기본적인 선형 미디어 스트리밍 서비스를 제공하기 위해, 다음과 같은 파라미터 설정이 적절하다.
첫째, MPD@type는 dynamic으로 설정된다.
둘째, MPD@availabilityStartTime는 Media Presentation의 시작 시간을 나타내는 임의의 적절한 값으로 설정되어, 세그먼트 이용가능성(Segment availabilities)들이 산출될 수 있도록 한다.
셋째, MPD@minimumUpdatePeriod가 존재하는 것으로 예상된다. MPD@minimumUpdatePeriod가 제공되는 경우는, Media Presentation의 정확한 종료 시각이 알려지지 않은 경우이다, 최소 업데이트 주기 값의 설정은 우선 두가지 주요 서비스 제공자 측면에 영향을 미친다. 즉, 짧은 최소 업데이트 주기는 더 짧은 통지로 MPD 내의 새로운 콘텐트를 변경 및 알릴 수 있는 능력을 발생시킨다. 그러나 작은 최소 업데이트 주기로 MPD를 제공함으로써, 클라이언트는 더 자주 MPD의 업데이트를 확인하게 된다. 그러나, 작은 값은 MPD를 업데이트할 필요가 없음을 의미하는 것은 아니라, 단지 가능한 MPD 업데이트 구간을 정의한다. 따라서 ROUTE를 통한 DASH 전달에 있어, MPD@minimumUpdatePeriod는 가능한 0에 가깝도록 가장 적절하게 설정될 수 있고, 이 경우, 클라이언트는 본래 서버에서 MPD가 생성되어 발표된 경우 벽 시간(wall-clock time)을 지정하는 MPD@publishTime 값을 확인한다. @publishTime가 빠른 MPD는 @publishTime의 값이 더 늦은 MPD로 업데이트 될 수 있다.
넷째, Segment Duration (SDURATION). 세그먼트 지속기간은 일반적으로 단대단 레이턴시에 영향을 미칠 뿐만 아니라, 스위치 포인트로도 사용될 수 있는 스트림 액세스 포인트로부터 각 세그먼트가 시작되는 기본 프로파일에서와 같은 스위칭 및 랜덤 액세스 단위(granularity)에도 영향을 미친다. 브로드캐스트 DASH 전달에 있어서, 즉 동적 비트레이트 적응성(dynamic bitrate adaptivity)이 이용되지 않는 경우, 스위칭은 관련성이 낮다. 콘텐트가 예를 들어 유니캐스트 분배를 위해서도 제공되는 경우, 서비스 제공자는 원하는 단대단 레이턴시, 원하는 압축 효율, 스타트업 레이턴시 및/또는 원하는 스위칭 단위(granularity) 중 적어도 하나를 고려하여 이 값을 설정한다. 세그먼트 지속기간의 타당한 값은 1초에서 10초 사이이다.
다섯째, MPD@minBufferTime (MBT) 및 Representation@bandwidth (BW). 최소 버퍼 시간의 값은 클라이언트에게 얼마나 많은 데이터를 버퍼링해야 하는지에 대한 지시를 제공하지 않는다. 이 값은 이상적인 네트워크 조건 하에서 클라이언트가 얼마나 많은 버퍼를 가지게 될지를 기술한다. 이와 같이, MBT는 네트워크 내의 간헐성(burstiness) 또는 지터(jitter)를 기술하는 것이 아니라, 콘텐트 인코딩에서의 간헐성 또는 지터를 기술한다. 이는 BW 값과 함께 콘텐트의 특성이다. "리키 버킷(leaky bucket)" 모델을 이용하면, 이는 @minBufferTime와 @bandwidth의 곱이 최악의 경우의 콘텐트 인코딩의 간헐성/지터를 나타내도록 하는 버킷의 크기가 된다. 최소 버퍼 시간은 각 스트림 액세스 포인트(Stream Access Point)에 대한 정보 (및 각 미디어 세그먼트(Media Segment)가 SAP로 시작하는 일반적인 경우에는, 이는 각 미디어 세그먼트의 시작에 대해 적용된다), 즉 스트림의 특성을 제공한다. (임의의 세그먼트에서 시작하는) Representation이 BW 속성의 값과 동일한 비트레이트로 일정한 비트레이트 채널을 통해 전달되는 경우, 프리젠테이션 타임 PT를 가진 각 세그먼트는 최대 PT + MBT의 지연을 가지고 가장 최근의 시각에 클라이언트에게 이용가능하다. MBT은 일반적으로 예를 들어 콘텐트의 코딩된 비디오 시퀀스 크기로 설정 될 수 있다.
여섯째, MPD@timeShiftBufferDepth (TSB). 콘텐트가 라이브 에지(edge)에서 소비되는 경우, TSB는 짧게 설정된다. 그러나 더 어려운 네트워크 조건에서 클라이언트가 어떤 예비 버퍼링을 하도록 하기 위해, TSB는 4*SDURATION 및 6초의 미디어 시간의 추천 값보다 작지 않도록 하는 것이 권장된다. timeShiftBufferDepth가 짧을수록 클라이언트와 분할기(segmenter) 사이의 시간 동기화가 더 좋다. 콘텐트의 접근성에 대한 제한이 없는 경우, TSB는 미디어 프리젠테이션 지속기간을 초과하는 큰 값으로 설정할 수 있다. 그러나 TSB는 클라이언트의 능력(capabilities)을 초과할 수 없다. 결합 시에 MBMS 클라이언트는 MPD 내의 해당 값을 애플리케이션에 포워딩하기 전에 이 값을 변경하여, 클라이언트가 아직 수신되지 않은 데이터를 요청하는 것을 피하도록 할 수 있다.
일곱째, MPD@suggestedPresentationDelay (SPD). 동일한 규칙을 따르는 다른 장치들과의 동기화된 재생이 요구되고, 및/또는 서비스 제공자가 프로그램의 대표적인 라이브 에지를 정의하기를 원하는 경우에, 이 값이 제공된다. 서비스 제공자는 단대단 레이턴시, 예를 들어 네트워크 상태를 기초로 한 클라이언트에서의 대표적으로 요구되는 버퍼링, 세그먼트 지속기간(SDURATION) 및/또는 타임 쉬프트 버퍼 깊이(TSB) 중 적어도 하나를 고려하여 이 값을 설정한다. 일반적으로, 타당한 값은 세그먼트 지속기간(SDURATION)의 2 내지 4배일 수 있으나, 클라이언트가 충분한 버퍼를 구축할 수 있도록 하기 위해 시간은 4초 보다 작지 않도록 하는 것이 가이드라인으로서 권장된다. 그러나, MBMS를 통한 DASH의 경우, 이 값은 전달로 지터의 최소화를 보장하는 만큼 작아질 수 있다.
DASH Optimizations(Shorter Open-GOP Segments)을 보면, 앞서 논의한 기본 프로파일에서 문제는, 세그먼트가 짧아야 하는 경우 가능한 빨리, 예를 들어 1초 이하의 범위에서 각 세그먼트는 IDR와 같은 SAP 타입으로 시작해야 한다는 것이다. 이는 불필요하게 코딩 효율을 제한한다.
따라서, s proposed to adopt a profile for which 전체 램덤 액세스 SAP들 (타입 1 또는 2)이 덜 빈번하게 위치하는 프로파일을 채택하는 것을 제안하지만, SAP 타입 3(Open GOP)도 가능해진다. 이는 각 세그먼트가 시작할 때 Open GOP에서의 빠른 튜닝(tune-in)을 가능하게 한다.
라이브 서비스를 위한 ROUTE의 사용
ROUTE 통한 DASH 스트리밍을 지원하기 위해, 서비스를 위한 MPD는 오브젝트 또는 메타데이터 프래그먼트로 전달될 수 있다. 다음과 같은 매핑이 적용된다.
첫째, ROUTE 세션는 MPD에 의해 참조되는 모든 오브젝트, MPD의 모든 업데이트, MPD의 임의의 업데이트에 의해 참조되는 오브젝트들을 전달한다.
둘째, 세그먼트가 ROUTE 오브젝트로서 전달되는 경우에는, 다음의 모든 사항이 성립한다. a) LCT 세션은, 전달된 오브젝트의 마지막 패킷이 MPD에서 알려진 세그먼트 이용가능성 시작 시간보다 늦지 않게 수신기에서 이용가능하도록 세그먼트를 전달한다. b) 전달된 오브젝트에 대한 FDT 내의 (또는 EFDT에 의해 유도된) Content-Location 엘리먼트는 MPD 내의 Segment URL에 매칭된다.
셋째, MPD 업데이트가 전달되는 경우, 다음의 모든 사항이 성립한다. a) 업데이트된 MPD가 FLUTE 오브젝트로서 전달되는 경우, 전달된 오브젝트에 대한 FDT 내의 (또는 EFDT에 의해 유도된) Content-Location 엘리먼트는 참조된 적절한 MPD의 URI에 매칭된다. b) MPD 업데이트는 이전에 전달된 MPD에 대한 유효한 업데이트이다.
넷째, MPD 내의 기타 다른 자원이 전달되는 경우 (예들 들어, xlinked 자원, metrics 등), a) 전달된 오브젝트에 대한 FDT 내의 (또는 EFDT에 의해 유도된) Content-Location 엘리먼트는 MPD 내의 오브젝트의 URI에 매칭된다. b) ROUTE 세션은, 전달된 MPD 시퀀스 상에서 작동하는 DASH 클라이언트가 자원을 요청하기 전에는 전달된 오브젝트의 마지막 패킷이 수신기에서 이용가능한 가장 최근의 시간이 발생하지 않도록, 오브젝트를 전달한다.
MPD는 랜덤 액세스 포인트에서 수신기에 이용가능하도록 전달되어야 한다. MPD는 대역 밖에서 또는 대역 내에서 전달될 수 있다. MPD가 자주 전달되지 않는 경우, EFDT 의 ApplicationIdentifier 차일드(child) 엘리먼트, 즉 LSID.SourceFlow.EFDT.ApplicationIdentifier는 DASH-특정적 메타데이터, 즉 언어, 레이팅 등과 같은 어댑테이션 세트(Adaptation Set)/레프리젠테이션 파라미터(Representation Parameters)를 전송한다.
초기화 세그먼트(Initialization Segment)는 랜덤 액세스 포인트에서 수신기에 이용가능하도록 전달된다.
Sender Operation을 보면, DASH 전달을 최적화하기 위해, 가장 작은 전달 및 소비 단위가 세그먼트인 것으로 가정하고 다음과 같은 패킷 생성이 적용된다. 세그먼트는 낮은 레이턴시와 낮은 튜닝(tune-in) 횟수를 다루기 위해 작을 수 있다. 세그먼트들은 순서대로, 즉 start_offset이 항상 증가하는 순서로 전달된다. start_offset이 0으로 설정된 패킷 또는 임의의 스트림 액세스 포인트를 포함하는 패킷은, 재생의 동기를 맞추기 위해 가장 빠른 프리젠테이션 시간을 벽 시간에 매핑하는 EXT_PRESENTATION_TIME 헤더를 포함한다. 패킷의 시작은 세그먼트 내 샘플의 시작과 정렬되어야 한다. 그와 같은 정렬은, 우선순위 중요도가 IP 패킷 마킹에 매핑될 수 있도록 이루어진다. 패킷은, 세그먼트가 패킷을 처리하여 시그널링된 프리젠테이션 시간에 표시되도록 패킷을 디코딩하기에 충분한 시간이 있도록 전달되어야 한다.
Receiver Operation의 MPD 기반 Reception을 보면, 정기적(regular) 수신 모드에서, ROUTE receiver는 다음과 같은 순서로 오브젝트를 수집한다. 즉, Transport 세션에서 전달되는 MPD, 선택된 Representation의 Initialization Segment, 및/또는 Media Segment의 순서로 수집한다.
이러한 정보와 MPD 내의 정보를 기반으로, 레귤러 DASH 클라이언트는 미디어를 재생하기 시작한다.
ROUTE receiver는 완전한 오브젝트만 수신기에 전달한다. 오브젝트를 상실한 경우, 데이터는 전달되지 않는다.
Receiver Operation의 Error-resilient Reception을 보면, 오브젝트에서 패킷 손실을 겪는 경우, receiver는 해당 오브젝트를 버린다. 또 달리, ROUTE receiver는 부분적으로 수신된 오브젝트를 전달할 수 있다. 이 경우, 애플리케이션은 그와 같은 부분 오브젝트를 처리하거나 버리기로 결정 할 수 있다.
Receiver Operation의 Quick Join을 보면, LSID에 각 Transport 세션을 위한 Adaptation Set/Representation parameters가 포함되고, 스트림 액세스 포인트의 수신이 있는 경우, 클라이언트는 프리젠테이션이 프리젠테이션 타임 헤더에 따라 스케줄링 된 수신된 미디어 컴포넌트의 재생을 즉시 시작할 수 있다. 재생을 초기화 한 후, 나머지 컴포넌트들이 수집되고, 추가적인 대안들을 제공하기 위해 풍부한(rich) MPD가 사용될 수 있다.
계층적 코딩(Layered Coding)
계층적 코딩의 경우, MPD는 계층화(layering)를 알린다. 일 예가 SVC를 이용하여 Annex G.5, ISO/IEC 23009-1에서 복사한 예시적 MPD에 도시되어 있다. 이는 단지 예시이며, S-HEVC 기타 다른 계층적 코덱에 동일하게 적용된다. 이 경우, 모든 Representation들은 하나의 Adaptation Set에 포함된다. 종속성들은 @dependencyId에 의해 표현된다. 전달의 관점에서, 각 계층은 별도의 LCT transport 세션 상에서 또는 별도의 ROUTE 세션에서 전달되는 것이 바람직할 수 있다. 바람직하게는 Representation 정보를 이용하여 LSID의 ApplicationIdentifier에서 적절한 시그널링을 제공함으로써, 계층화가 적절하게 표현될 수 있다.
또한 서로 다른 소스 플로우에 서로 다른 리페어 플로우를 적용함으로써 계층화가 더욱 지원될 수 있다. 적절한 구성을 통해, 베이스 계층에서만 이루어지는 빠른 참여, 더 강인한 베이스 계층 등과 같은 상이한 유스 케이스(use case)들이 지원될 수 있다.
도 28는 본 발명의 일 실시예에 따른 URI Form을 나타낸 도면이다.
전체 파일의 부분세트를 딜리버리 오브젝트로 전달 하기 위해서, EFDT 내의 Content-Location는 특정 프래그먼트 식별자를 이용하여 부분세트를 알릴 수 있다. 이러한 맥락에서 두개의 URL 프래그먼트 식별자, 즉 바이트 범위, 프래그먼트ISO BMFF 포맷의 프래그먼트 및/또는 DASH Representation의 서브세그먼트가 도입된다. 보다 상세한 내용에 대해서는 http://www.w3.org/TR/media-frags/ 및http://www.w3.org/TR/2011/WD-media-frags-recipes-20111201/를 참조할 수 있다.
Byte Range의 Query Parameter를 보면, 레귤러 파일의 URL은 쿼리 파라미터 &range=$first$-$last$"에 의해 확장 될 수 있다. 여기서, $first$와 $last$은 아래의 값으로 대체된다..
“$first$”은 범위 내의 첫번째 바이트의 바이트 오프셋에 의해 대체되는 식별자로, 해당 요청이 partial GET request에 의해 실행되는 경우, RFC 2616의 14.35.1에서 'byte-range-spec' 의 'first-byte-pos'의 값과 동일하게 되는 식별자이다.
“$last$“은 범위 내의 마지막 바이트의 바이트 오프셋에 의해 대체되는 식별자이다. 즉, 지정된 바이트 위치가 포함된다. 이 식별자는 해당 요청이 partial GET request에 의해 실행되면 RFC 2616의 14.35.1에서 'byte-range-spec'의 'last-byte-pos' 의 값과 동일하게 된다.
이와 같은 Content-Location가 제공되면, 딜리버리 오브젝트가 URL에 의해 제공된 오브젝트의 $first$와 $last$ 사이의 바이트 범위임을 지시한다.
도 29는 본 발명의 일 실시예에 따른 URI Form을 나타낸 도면이다.
도면에서는 URL들을 도시하고 있다. URL to full object를 보면, 이는 “http://cdn.example.com/movies/134532/audio/en/aac64.mp4”로 표시되어 있다. Byte Range of delivery object를 보면, 1876-23456”로 표시되어 있다. URL to delivery object를 보면,“http://cdn.example.com/movies/134532/audio/en/aac64.mp4?range=1876-23456”로 표시되어 있다.
도 30은 본 발명의 일 실시예에 따른 Parameters for MP4 Fragment identifiers을 나타낸 도면이다.
MIME 타입 비디오/mp4 또는 오디오/mp4를 가진 자원에 대한 URI은 URI 프래그먼트 신택스를 사용하여 movie 파일의 일부분, 구체적으로 무비 프래그먼트만 알릴 수 있다. 본 절에서는 분할된 ISO BMFF 파일의 하나의 프래그먼트를 표현하기 위해 프래그먼트 식별자를 정의한다.
URI 프래그먼트는 ‘#’ 문자로 시작하며, URI를 끝내는 문자열(string)이다. MP4 프래그먼트는, 도면에서 정의된 키(key)와 값(value) 파라미터들의 신택스와 시맨틱을 가진 key=value 쌍들을 콤마로 분리한 목록이 된다.
fragment 파라미터는 ISO BMFF에서의 무비 프래그먼트의 값(무비 프래그먼트 번호)를 지시한다. 0이면, 무비 헤더를 가리킨다.
subsegment 파라미터는 ISO BMFF/DASH Representation에서의 서브세그먼트의 값을 지시한다. 0이면, 무비 헤더와 세그먼트 인덱스를 가리킨다.
Examples을 보면, ISO BMFF 파일에서 27번째 무비 프래그먼트는 “http://www.example.com/mymovie.mp4#fragment=27”로 표현된다.
ISO BMFF 파일에서 27번째부터 31번째까지의 무비 프래그먼트는 “http://www.example.com/mymovie.mp4#fragment=27,31”로 표현된다.
ISO BMFF 파일에서 무비 헤더는 “http://www.example.com/mymovie.mp4#fragment=0”로 표현된다.
ISO BMFF 파일에서 무비 헤더와 첫번 째 무비 프래그먼트는 “http://www.example.com/mymovie.mp4#fragment=0,1”로 표현된다.
ISO BMFF 파일에서 27번째 Subsegment는 “http://www.example.com/mymovie.mp4#subsegment=27”로 표현된다.
ISO BMFF 파일에서 27번째부터 31번째까지의 Subsegment는 “http://www.example.com/mymovie.mp4#subsegment=27,31”로 표현된다.
ISO BMFF 파일에서 무비 헤더와 Segment 인텍스는 “http://www.example.com/mymovie.mp4# subsegment=0”로 표현된다.
ISO BMFF 파일에서 무비 헤더, Segment 인텍스는 및 첫 번째 Subsegment는 “http://www.example.com/mymovie.mp4# subsegment=0,1”로 표현된다.
Usage in ROUTE를 보면, EFDT가 이와 같은 프래그먼트 및 Subsegment 식별자로써 Content-Location을 명시적으로 포함하거나 유도한 경우, 딜리버리 오브젝트는 정확하게 무비 프래그먼트, Subsegment 또는 무비 프래그먼트/Subsegment의 시퀀스를 나타내는 바이트 범위가 된다.
도 31은 본 발명의 일 실시예에 따른 수신기의 동작을 나타낸 도면이다.
방송 수신 장치는 방송망(예를 들어, 브로드캐스트) 및/또는 인터넷망(예를 들어, 브로드밴드) 중에서 적어도 하나를 이용하여 방송 서비스를 수신하고, 방송 서비스를 디코딩할 수 있다. 방송 수신 장치는 브로드캐스트 인터페이스, 브로드밴드 인터페이스, 및/또는 제어부 중에서 적어도 하나를 포함할 수 있다. 방송 수신 장치의 제어부는 ROUTE Receiver 및/또는 DASH Client 중에서 적어도 하나를 포함할 수 있다. ROUTE Receiver는 Packet Receiver, 시그널링 파서, 딜리버리 오브젝트 프로세서, 및/또는 Delivery Object Cache 중에서 적어도 하나를 포함할 수 있다. 딜리버리 오브젝트 프로세서는 Object Recovery 및/또는 FEC decoder 중에서 적어도 하나를 포함할 수 있다. 방송 수신 장치의 구체적인 내용은 전술한 바와 동일하다.
방송 수신 장치는, 브로드캐스트 인터페이스 및/또는 브로드밴드 인터페이스 중에서 적어도 하나를 이용하여, 방송 서비스를 포함하는 방송 신호를 수신할 수 있다. 예를 들어, 방송 수신 장치는 서비스를 포함하는 방송 신호를 단방향 채널(unidirectional channel)을 통해서 수신할 수 있다(CS31100).
방송 수신 장치는, 제어부를 이용하여, 서비스의 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출할 수 있다(CS31200).
예를 들어, 방송 수신 장치는, 시그널링 파서를 이용하여, 서비스의 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출할 수 있다.
시그널링 정보는 서비스의 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션을 서술하는 제1 정보를 포함할 수 있다. 예를 들어, 제1 정보는 Service Layer Signaling(SLS), LCT Session Instance Description(LSID), 및/또는 Service-based Transport Session Instance Description(S-TSID)를 포함할 수 있다. 또는, 시그널링 정보는 ROUTE Session Description, LCT Transport Session Description(또는, LCT Session Description), 및/또는 딜리버리 오브젝트 메타데이터(또는, Object metadata)를 포함할 수 있다.
제1 정보는 상기 전송 세션을 통해 전송되는 소스 데이터를 서술하는 제2 정보를 포함할 수 있다. 예를 들어, 제2 정보는 SourceFlow 엘리먼트 및/또는 RepairFlow element를 포함할 수 있다. SourceFlow 엘리먼트는 세션 내의 소스 플로우를 정의할 수 있다. RepairFlow element 는 세션 내의 리페어 플로우를 정의할 수 있다.
방송 수신 장치는, 제어부를 이용하여, 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다(CS31300).
예를 들어, 방송 수신 장치는, Object Recovery를 이용하여, 시그널링 정보를 기초로 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다. Object Recovery는 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 소스 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
예를 들어, 방송 수신 장치는, FEC Decoder를 이용하여, 방송 서비스를 포함하는 적어도 하나의 패킷을 기초로 리페어 프로토콜과 관련된 시그널링 정보 및/또는 적어도 하나의 딜리버리 오브젝트를 복원할 수 있다.
방송 수신 장치는, 제어부를 이용하여, 방송 서비스 및/또는 적어도 하나의 딜리버리 오브젝트를 디코딩할 수 있다.
모듈, 처리부, 디바이스 또는 유닛은 메모리(또는 저장 유닛)에 저장된 연속된 수행과정들을 실행하는 프로세서들일 수 있다. 전술한 실시예에 기술된 각 단계들은 하드웨어/프로세서들에 의해 수행될 수 있다. 전술한 실시예에 기술된 각 모듈/블록/유닛들은 하드웨어/프로세서로서 동작할 수 있다. 또한, 본 발명이 제시하는 방법들은 코드로서 실행될 수 있다. 이 코드는 프로세서가 읽을 수 있는 저장매체에 쓰여질 수 있고, 따라서 장치(apparatus)가 제공하는 프로세서에 의해 읽혀질 수 있다.
본 발명에 따른 방법 발명은 모두 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다.
상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상과 같이 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다. 그러므로, 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 아니되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (14)

  1. 서비스의 콘텐트 컴포넌트에 포함되고 독립적으로 복원되는(recovered individually) 적어도 하나의 딜리버리 오브젝트(Delivery Object)를 생성하는 딜리버리 오브젝트 제너레이터 (delivery object generator);
    상기 서비스 및 상기 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 생성하는 시그널링 정보 제너레이터(signaling information generator); 및
    상기 적어도 하나의 딜리버리 오브젝트 및 상기 시그널링 정보를 단방향 채널(unidirectional channel)을 통해서 전송하는 트랜스미터(transmitter)를 포함하는 방송 송신 장치.
  2. 제1항에 있어서,
    상기 딜리버리 오브젝트는, 파일, 상기 파일의 일부분, 상기 파일의 그룹, HTTP (Hyper Text Transfer Protocol) 엔티티(Entity) 및 상기 HTTP 엔티티 중 하나인, 방송 송신 장치.
  3. 제1항에 있어서,
    상기 시그널링 정보는 상기 서비스의 상기 콘텐트 컴포넌트를 전송하는 전송 세션(transport session)을 기술하는 제 1 정보를 포함하는, 방송 송신 장치.
  4. 제3항에 있어서,
    상기 제 1 정보는 상기 전송 세션에서 전송된 소스 데이터를 기술하는 제 2 정보를 포함하는, 방송 송신 장치.
  5. 제4항에 있어서,
    상기 제 2 정보, 상기 파일 전달 데이터의 세부 내용을 지정하는 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성(attribute), 상기 딜리버리 오브젝트가 실시간으로 전달되는 지를 지시하는 realtime 속성, 리시버(receiver)에 저장될 필요가 있는 데이터의 최대 양을 정의하는 minBufferSize, 애플리케이션에 매핑될 수 있는 정보를 제공하는 ApplicationIdentifier 엘리먼트, 및/또는 상기 딜리버리 오브젝트를 나르는 패킷의 페이로드 포팻(payload format)을 정의하는 PayloadFormat 엘리먼트 중 적어도 하나를 포함하는, 방송 송신 장치.
  6. 제5항에 있어서,
    상기 PayloadFormat 엘리먼트는, CodePoint 값이 페이로드를 위해 사용되는 것을 정의하는 codePoint 속성, 딜리버리 오브젝트의 상기 페이로드 포맷을 지정하는 deliveryObjectFormat 속성, 상기 딜리버리 오브젝트의 단위를 지시하는 fragmentation 속성, 상기 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전달 순서를 지시하는 deliveryOrder 속성, Source FEC Payload ID의 포맷을 정의하는 sourceFecPayloadID 속성 및 FEC 파라미터들을 정의하는 FECParamenters 엘리먼트 중 적어도 하나를 포함하는, 방송 송신 장치.
  7. 제6항에 있어서,
    상기 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성, 상기 EFDT 엘리먼트의 버전을 식별하는 version 속성, 상기 전송 세션 내의 오브젝트에 대한 최대 만료 시간을 지시하는 maxExpiresDelta 속성, 상기 EFDT 엘리먼트에 의해 기술되는 오브젝트의 최대 전송 크기(maximum transport size)를 지시하는 maxTransportSize 속성 및 파일 URL을 지정하는 FileTemplate 엘리먼트 중 적어도 하나를 포함하는, 방송 송신 장치.
  8. 서비스를 포함하는 방송 신호를 단방향 채널(unidirectional channel)을 통해서 수신하는 브로드캐스트 인터페이스(broadcast interface);
    상기 서비스 및 상기 서비스의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출하는 시그널링 파서(signaling parser); 및
    상기 시그널링 정보에 기초하여 적어도 하나의 딜리버리 오브젝트(Delivery Object)를 복원하는 딜리버리 오브젝트 프로세서를 포함하는 방송 수신 장치.
  9. 제8항에 있어서,
    상기 딜리버리 오브젝트는, 파일, 상기 파일의 일부분, 상기 파일의 그룹, HTTP (Hyper Text Transfer Protocol) 엔티티(Entity) 및 상기 HTTP 엔티티 중 하나인, 방송 수신 장치.
  10. 제8항에 있어서,
    상기 시그널링 정보는 상기 서비스의 상기 콘텐트 컴포넌트를 전송하는 전송 세션(transport session)을 기술하는 제 1 정보를 포함하는, 방송 수신 장치.
  11. 제10항에 있어서,
    상기 제 1 정보는 상기 전송 세션에서 전송된 소스 데이터를 기술하는 제 2 정보를 포함하는, 방송 수신 장치.
  12. 제11항에 있어서,
    상기 제 2 정보, 상기 파일 전달 데이터의 세부 내용을 지정하는 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성(attribute), 상기 딜리버리 오브젝트가 실시간으로 전달되는 지를 지시하는 realtime 속성, 리시버(receiver)에 저장될 필요가 있는 데이터의 최대 양을 정의하는 minBufferSize, 애플리케이션에 매핑될 수 있는 정보를 제공하는 ApplicationIdentifier 엘리먼트, 및/또는 상기 딜리버리 오브젝트를 나르는 패킷의 페이로드 포팻(payload format)을 정의하는 PayloadFormat 엘리먼트 중 적어도 하나를 포함하는, 방송 수신 장치.
  13. 제12항에 있어서,
    상기 PayloadFormat 엘리먼트는, CodePoint 값이 페이로드를 위해 사용되는 것을 정의하는 codePoint 속성, 딜리버리 오브젝트의 상기 페이로드 포맷을 지정하는 deliveryObjectFormat 속성, 상기 딜리버리 오브젝트의 단위를 지시하는 fragmentation 속성, 상기 딜리버리 오브젝트의 데이터를 포함하는 패킷들의 전달 순서를 지시하는 deliveryOrder 속성, Source FEC Payload ID의 포맷을 정의하는 sourceFecPayloadID 속성 및 FEC 파라미터들을 정의하는 FECParamenters 엘리먼트 중 적어도 하나를 포함하는, 방송 수신 장치.
  14. 제13항에 있어서,
    상기 EFDT 엘리먼트, 상기 EFDT 엘리먼트를 식별하는 idRef 속성, 상기 EFDT 엘리먼트의 버전을 식별하는 version 속성, 상기 전송 세션 내의 오브젝트에 대한 최대 만료 시간을 지시하는 maxExpiresDelta 속성, 상기 EFDT 엘리먼트에 의해 기술되는 오브젝트의 최대 전송 크기(maximum transport size)를 지시하는 maxTransportSize 속성 및 파일 URL을 지정하는 FileTemplate 엘리먼트 중 적어도 하나를 포함하는, 방송 수신 장치.
KR1020167002411A 2014-07-31 2015-07-28 방송 신호 송/수신 처리 방법 및 장치 KR101757306B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462031857P 2014-07-31 2014-07-31
US62/031,857 2014-07-31
PCT/KR2015/007871 WO2016018042A1 (en) 2014-07-31 2015-07-28 Apparatus and method for transmitting/receiving processes of a broadcast signal

Publications (2)

Publication Number Publication Date
KR20160025603A true KR20160025603A (ko) 2016-03-08
KR101757306B1 KR101757306B1 (ko) 2017-07-12

Family

ID=55217843

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020167002411A KR101757306B1 (ko) 2014-07-31 2015-07-28 방송 신호 송/수신 처리 방법 및 장치

Country Status (5)

Country Link
US (3) US9936233B2 (ko)
EP (1) EP3175624A4 (ko)
KR (1) KR101757306B1 (ko)
CN (1) CN105594219B (ko)
WO (1) WO2016018042A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200098537A (ko) * 2019-02-07 2020-08-20 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015105391A1 (en) * 2014-01-13 2015-07-16 Lg Electronics Inc. Apparatuses and methods for transmitting or receiving a broadcast content via one or more networks
JP2015136059A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
US10476693B2 (en) * 2014-02-24 2019-11-12 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
EP3175624A4 (en) * 2014-07-31 2018-02-28 LG Electronics Inc. Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2016111563A1 (ko) * 2015-01-07 2016-07-14 삼성전자 주식회사 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
CN106105240B (zh) * 2015-01-21 2019-11-08 Lg电子株式会社 发送广播信号的装置以及发送广播信号的方法
US10298647B2 (en) * 2015-02-26 2019-05-21 Qualcomm Incorporated Delay compensation for broadcast adaptive bitrate streaming
US10454985B2 (en) 2015-03-04 2019-10-22 Qualcomm Incorporated File format based streaming with dash formats based on LCT
CA3082203C (en) * 2015-10-23 2022-11-08 Sharp Kabushiki Kaisha Signaling method, receiving method signaling device, and receiving device
WO2018164355A1 (ko) * 2017-03-10 2018-09-13 엘지전자 주식회사 멀티캐스트 신호 송수신 방법 및 장치
US11606528B2 (en) 2018-01-03 2023-03-14 Saturn Licensing Llc Advanced television systems committee (ATSC) 3.0 latency-free display of content attribute
CN108667808A (zh) * 2018-04-12 2018-10-16 上海交通大学 支持专用回传链路的atsc3.0底层信令的通信方法
CN110968744B (zh) 2018-09-30 2023-09-05 中国移动通信有限公司研究院 一种资源查询方法及装置、设备、存储介质
CN109379602B (zh) * 2018-10-26 2021-02-26 上海麦克风文化传媒有限公司 基于云存储的数据存取方法及其系统
US11706465B2 (en) 2019-01-15 2023-07-18 Sony Group Corporation ATSC 3.0 advertising notification using event streams
US11425187B2 (en) * 2019-09-30 2022-08-23 Tencent America Llc. Session-based information for dynamic adaptive streaming over HTTP
WO2021116839A1 (en) * 2019-12-11 2021-06-17 Sony Group Corporation Advanced television systems committee (atsc) 3.0 latency-free display of content attribute
US11818189B2 (en) * 2021-01-06 2023-11-14 Tencent America LLC Method and apparatus for media streaming
US11895172B2 (en) * 2021-04-21 2024-02-06 Tencent America LLC Session-based description URL customization using the session-based DASH operations
US11539961B1 (en) * 2021-11-24 2022-12-27 Amazon Technologies, Inc. Smoothing bit rate variations in the distribution of media content

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2740636B1 (fr) * 1995-10-31 1997-11-28 Thomson Multimedia Sa Procede permettant la mise en cascade de modules d'acces conditionnel detachables, circuit d'insertion d'une sequence predefinie et circuit de detection de ladite sequence pour la mise en oeuvre du procede
JP3907860B2 (ja) * 1999-02-16 2007-04-18 三菱電機株式会社 動画像復号装置及び動画像復号方法
US6357028B1 (en) * 1999-03-19 2002-03-12 Picturetel Corporation Error correction and concealment during data transmission
WO2000064156A1 (fr) * 1999-04-16 2000-10-26 Sony Corporation Procede de transmission de donnees et emetteur de donnees
US7617509B1 (en) * 2000-06-23 2009-11-10 International Business Machines Corporation Method and system for automated monitoring of quality of service of digital video material distribution and play-out
JP3699910B2 (ja) * 2000-10-31 2005-09-28 株式会社東芝 データ伝送装置、データ伝送方法及びプログラム
JP3815597B2 (ja) * 2001-06-11 2006-08-30 ソニー株式会社 信号処理装置
EP1298926B1 (en) * 2001-09-10 2007-02-28 Telefonaktiebolaget LM Ericsson (publ) Information presentation device and method
JP4116470B2 (ja) * 2002-03-06 2008-07-09 ヒューレット・パッカード・カンパニー メディア・ストリーミング配信システム
US6983323B2 (en) * 2002-08-12 2006-01-03 Tippingpoint Technologies, Inc. Multi-level packet screening with dynamically selected filtering criteria
US6996394B2 (en) * 2002-08-30 2006-02-07 Qualcomm Incorporated Server processing in providing messages for a wireless device connecting to a server
US7693058B2 (en) * 2002-12-03 2010-04-06 Hewlett-Packard Development Company, L.P. Method for enhancing transmission quality of streaming media
KR100516586B1 (ko) * 2002-12-10 2005-09-22 삼성전자주식회사 부호 분할 다중 접속 이동 통신 시스템의 오류 정정 장치및 방법
KR100489685B1 (ko) * 2003-02-20 2005-05-17 삼성전자주식회사 패킷 제어기와 네트워크 프로세서간의 패킷 전송을 위한패킷 송수신 장치와 그 방법
FI20031260A (fi) * 2003-09-04 2005-03-05 Nokia Corp Median suoratoisto palvelimelta asiakaslaitteelle
US7016409B2 (en) * 2003-11-12 2006-03-21 Sony Corporation Apparatus and method for use in providing dynamic bit rate encoding
US20050262529A1 (en) * 2004-05-20 2005-11-24 Raja Neogi Method, apparatus and system for remote real-time access of multimedia content
US8102877B1 (en) * 2004-09-10 2012-01-24 Verizon Laboratories Inc. Systems and methods for policy-based intelligent provisioning of optical transport bandwidth
US7760826B2 (en) * 2005-06-06 2010-07-20 Mediatek Incorporation Apparatus for suppressing burst noise and method thereof
EP1763173A2 (en) * 2005-09-08 2007-03-14 Acterna, LLC Transmission quality monitoring for multimedia streams
US8839065B2 (en) * 2011-07-29 2014-09-16 Blackfire Research Corporation Packet loss anticipation and pre emptive retransmission for low latency media applications
WO2008038261A2 (en) * 2006-09-26 2008-04-03 Liveu Ltd. Remote transmission system
US8279884B1 (en) * 2006-11-21 2012-10-02 Pico Mobile Networks, Inc. Integrated adaptive jitter buffer
US8839325B2 (en) * 2007-02-14 2014-09-16 At&T Intellectual Property I, L.P. System and method of managing video content quality
JP2008271253A (ja) * 2007-04-20 2008-11-06 Toshiba Corp ストリーム再生装置
CN101296246B (zh) * 2007-04-24 2012-06-27 华为技术有限公司 通过单向文件传输协议传输、接收通知消息的方法及装置
US8365235B2 (en) * 2007-12-18 2013-01-29 Netflix, Inc. Trick play of streaming media
US8549575B2 (en) * 2008-04-30 2013-10-01 At&T Intellectual Property I, L.P. Dynamic synchronization of media streams within a social network
WO2009151265A2 (ko) * 2008-06-09 2009-12-17 엘지전자(주) 방송 신호 수신 방법 및 수신 시스템
CN102165782A (zh) * 2008-09-26 2011-08-24 泰景系统公司 具有错误检测和/或隐藏电路系统及技术的数字视频和/或音频接收和/或输出的装置和方法
US20100091888A1 (en) * 2008-10-13 2010-04-15 General Instrument Corporation Multi-Rate Encoder with GOP Alignment
US8537683B2 (en) * 2008-11-13 2013-09-17 Telecom Italia S.P.A. Method for estimating the quality of experience of a user in respect of audio and/or video contents distributed through telecommunications networks
US8156237B2 (en) 2008-12-09 2012-04-10 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
US8284259B2 (en) * 2009-09-23 2012-10-09 Avaya Inc. Policy-based video quality assessment
EP2604031B1 (en) * 2010-08-10 2017-03-08 Google Technology Holdings LLC Method and apparatus for streaming media content using variable duration media segments
US10511887B2 (en) * 2010-08-30 2019-12-17 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system
US8311817B2 (en) * 2010-11-04 2012-11-13 Audience, Inc. Systems and methods for enhancing voice quality in mobile device
CN103249660B (zh) * 2010-12-17 2016-09-07 3M创新有限公司 开放间隙膜卷芯
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US8744010B2 (en) 2011-05-12 2014-06-03 Nokia Corporation Providing signaling information in an electronic service guide
US9590814B2 (en) 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
US8855197B2 (en) * 2011-08-15 2014-10-07 Rgb Networks, Inc. Method and apparatus for aligning IDR frames in transcoded multi-bitrate video streams
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US8780907B2 (en) 2011-10-03 2014-07-15 Verizon Patent And Licensing Inc. Optimized file repair architecture for mobile broadcast multicast system (MBMS)
US9888244B2 (en) * 2011-10-05 2018-02-06 Texas Instruments Incorporated Methods and systems for encoding of multimedia pictures
EP2805463A1 (en) * 2012-01-17 2014-11-26 Telefonaktiebolaget L M Ericsson (publ) Method for sending respectively receiving a media stream
US9848217B2 (en) * 2012-01-20 2017-12-19 Korea Electronics Technology Institute Method for transmitting and receiving program configuration information for scalable ultra high definition video service in hybrid transmission environment, and method and apparatus for effectively transmitting scalar layer information
US9191696B2 (en) * 2012-06-15 2015-11-17 Samsung Electronics Co., Ltd. Reception device and program for reception device
US20140013342A1 (en) * 2012-07-05 2014-01-09 Comcast Cable Communications, Llc Media Content Redirection
US20140098745A1 (en) * 2012-10-04 2014-04-10 Qualcomm Incorporated Method and system for compressing data packets in lte evolved multicast broadcast multimedia service
US20140282792A1 (en) * 2013-03-15 2014-09-18 Cygnus Broadband, Inc. Video streaming with buffer occupancy prediction based quality adaptation
US9900166B2 (en) * 2013-04-12 2018-02-20 Qualcomm Incorporated Methods for delivery of flows of objects over broadcast/multicast enabled networks
US9326041B2 (en) * 2013-09-17 2016-04-26 International Business Machines Corporation Managing quality of experience for media transmissions
US9819953B2 (en) * 2013-12-31 2017-11-14 International Business Machines Corporation Decoding media streams within thresholds
EP3175624A4 (en) * 2014-07-31 2018-02-28 LG Electronics Inc. Apparatus and method for transmitting/receiving processes of a broadcast signal

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200098537A (ko) * 2019-02-07 2020-08-20 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치

Also Published As

Publication number Publication date
US20210176506A1 (en) 2021-06-10
CN105594219A (zh) 2016-05-18
CN105594219B (zh) 2019-08-20
KR101757306B1 (ko) 2017-07-12
US20180184136A1 (en) 2018-06-28
US10939149B2 (en) 2021-03-02
WO2016018042A1 (en) 2016-02-04
EP3175624A1 (en) 2017-06-07
US11805286B2 (en) 2023-10-31
EP3175624A4 (en) 2018-02-28
US9936233B2 (en) 2018-04-03
US20160261893A1 (en) 2016-09-08

Similar Documents

Publication Publication Date Title
KR101757306B1 (ko) 방송 신호 송/수신 처리 방법 및 장치
JP6441521B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
KR102202143B1 (ko) 유연한 ｍｍｔ 애셋 송수신 방법 및 그 장치
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
US11317138B2 (en) Method and apparatus for transmitting or receiving service signaling for broadcasting service
KR101838083B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US11895357B2 (en) Broadcasting signal transmission device, broadcasting signal reception device, broadcasting signal transmission method, and broadcasting signal reception method
KR102340240B1 (ko) 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
US20150172348A1 (en) Method for sending respectively receiving a media stream
US10560866B2 (en) Method of handling packet losses in transmissions based on DASH standard and FLUTE protocol
TW201725911A (zh) 決定用於媒體傳輸的媒體傳遞事件位置
KR20150140783A (ko) 브로드캐스트/멀티캐스트 인에이블드 네트워크들을 통해 오브젝트들의 플로우들을 전달하기 위한 방법들
KR20170089863A (ko) 멀티미디어 및 파일 전송을 위한 전송 인터페이스
Lim MMT, new alternative to MPEG-2 TS and RTP
KR20220075367A (ko) Ｄａｓｈ／ｈｌｓ 하이브리드 멀티미디어 스트림을 브로드캐스팅하기 위한 방법

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant