KR102125162B1 - 미디어 캡슐화 및 캡슐 해제 기법 - Google Patents
미디어 캡슐화 및 캡슐 해제 기법 Download PDFInfo
- Publication number
- KR102125162B1 KR102125162B1 KR1020187026684A KR20187026684A KR102125162B1 KR 102125162 B1 KR102125162 B1 KR 102125162B1 KR 1020187026684 A KR1020187026684 A KR 1020187026684A KR 20187026684 A KR20187026684 A KR 20187026684A KR 102125162 B1 KR102125162 B1 KR 102125162B1
- Authority
- KR
- South Korea
- Prior art keywords
- box
- file
- media
- media data
- delete delete
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 77
- 238000005538 encapsulation Methods 0.000 title abstract description 10
- 230000008520 organization Effects 0.000 claims description 5
- 238000013479 data entry Methods 0.000 claims 8
- 238000004590 computer program Methods 0.000 abstract description 21
- 239000012634 fragment Substances 0.000 description 99
- 230000015654 memory Effects 0.000 description 33
- 238000003860 storage Methods 0.000 description 31
- 238000004891 communication Methods 0.000 description 30
- 230000004044 response Effects 0.000 description 25
- 230000005540 biological transmission Effects 0.000 description 24
- AWSBQWZZLBPUQH-UHFFFAOYSA-N mdat Chemical compound C1=C2CC(N)CCC2=CC2=C1OCO2 AWSBQWZZLBPUQH-UHFFFAOYSA-N 0.000 description 23
- 230000008569 process Effects 0.000 description 14
- 238000010276 construction Methods 0.000 description 13
- 238000013461 design Methods 0.000 description 11
- 238000012545 processing Methods 0.000 description 10
- 238000009877 rendering Methods 0.000 description 10
- 239000003795 chemical substances by application Substances 0.000 description 9
- 230000006870 function Effects 0.000 description 9
- 230000006978 adaptation Effects 0.000 description 8
- 238000012546 transfer Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 7
- 230000036961 partial effect Effects 0.000 description 7
- 230000000670 limiting effect Effects 0.000 description 6
- 239000004065 semiconductor Substances 0.000 description 6
- 230000003068 static effect Effects 0.000 description 6
- 230000003044 adaptive effect Effects 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 230000003139 buffering effect Effects 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 238000002360 preparation method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000001934 delay Effects 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 239000012092 media component Substances 0.000 description 3
- 230000000750 progressive effect Effects 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 239000000872 buffer Substances 0.000 description 2
- 238000009795 derivation Methods 0.000 description 2
- 230000007613 environmental effect Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 240000002791 Brassica napus Species 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 210000001072 colon Anatomy 0.000 description 1
- 239000004020 conductor Substances 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
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/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/23605—Creation or processing of packetized elementary streams [PES]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/762—Media network packet handling at the source
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/764—Media network packet handling at the destination
-
- 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/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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
- H04N21/4343—Extraction or processing of packetized elementary streams [PES]
-
- 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
미디어 캡슐화 및 캡슐 해제를 위한 다양한 방법, 장치 및 컴퓨터 프로그램 제품이 개시되어 있다. 미디어 데이터를 캡슐화하기 위한 예시적 방법에서는, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일이 형성된다. 오프셋은 컨테이너 파일 내의 미디어 데이터 구조의 위치에 관련된다고 판정될 수 있는데, 미디어 데이터 유닛 내의 미디어 데이터 구조의 위치에 대한 참조로서 오프셋 데이터가 형성된다. 오프셋 데이터가 미디어 데이터 구조의 위치에 관련된다는 표시가 포함된다. 미디어 데이터를 캡슐 해제하기 위한 예시적인 방법에서는, 미디어 데이터 구조 내의 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일 및 오프셋 데이터가 수신된다. 오프셋 데이터는 컨테이너 파일 내의 미디어 데이터 구조의 위치에 관련된다고 판정될 수 있으며, 오프셋 데이터는 미디어 데이터 유닛을 획득하기 위해 미디어 데이터 구조의 위치에 대한 참조로서 사용된다.
Description
본 발명은 일반적으로 미디어 파일 포맷의 사용에 관한 것이다. 구체적으로, 본 발명은 미디어 데이터 신호를 파일로 캡슐화(encapsulating)하는 방법 및 파일로부터 미디어 데이터를 캡슐 해제(decapsulating)하는 방법에 관한 것이다. 본 발명은 또한 미디어 데이터를 파일로 캡슐화하는 장치 및 컴퓨터 프로그램 제품, 및 파일로부터 미디어 데이터를 캡슐 해제하기 위한 장치 및 컴퓨터 프로그램 제품에 관한 것이다.
이 섹션은 청구범위에 기재된 본 발명에 대한 배경 또는 맥락을 제공하기 위한 것이다. 여기서의 설명은 추구될 수 있는 개념을 포함할 수 있지만 반드시 이전에 고안되거나 추구된 개념은 아니다. 따라서, 여기에서 달리 표시되지 않는 한, 이 섹션에 설명된 것은 본 출원의 설명 및 청구범위에 대한 선행 기술이 아니며, 이 섹션에의 포함에 의해 선행 기술로 인정되는 것은 아니다.
미디어 컨테이너 파일 포맷은 미디어 콘텐츠 제작, 조작, 전송 및 소비의 사슬 내의 한 요소이다. 이러한 맥락에서, 코딩 포맷(즉, 기본 스트림 포맷)은 콘텐츠 정보를 비트스트림으로 코딩하는 특정 코딩 알고리즘의 작용에 관련된다. 컨테이너 파일 포맷은, 다양한 저장 및 전송 아키텍처를 전적으로 활용하여, 로컬 디코딩 및 재생, 파일로서의 전송 또는 스트리밍을 위해 액세스될 수 있는 방식으로 생성된 비트스트림을 체계화하기 위한 메커니즘을 포함한다. 컨테이너 파일 포맷은 또한 수신된 실시간 스트림을 파일에 기록하는 것뿐만 아니라 미디어의 상호 교환 및 편집을 용이하게 한다. 따라서, 코딩 포맷과 컨테이너 파일 포맷 간에는 상당한 차이가 있을 수 있다.
다양한 실시예는 매체 캡슐화 및 캡슐화 해제를 위한 시스템 및 방법을 제공한다.
본 발명의 예의 다양한 양태가 상세한 설명에 제공된다.
제 1 양태에 따르면, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하는 단계와,
오프셋 데이터를 수신하는 단계와,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하는 단계와,
상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하는 단계를 포함하는
방법이 제공된다.
제 2 양태에 따르면, 적어도 하나의 프로세서 및 적어도 하나의 메모리를 포함하는 장치로서,
상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하는 것과,
오프셋 데이터를 수신하는 것과,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하는 것과,
상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하는 것
을 수행하게 하는 코드가 저장되어 있는
장치가 제공된다.
제 3 양태에 따르면, 컴퓨터 프로그램 코드를 포함하는 비일시적 컴퓨터 판독가능 매체 상에서 구현된 컴퓨터 프로그램 제품으로서,
상기 프로그램 코드는 적어도 하나의 프로세서 상에서 실행될 때 장치 또는 시스템으로 하여금,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하게 하고,
오프셋 데이터를 수신하게 하고,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하게 하고,
상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하게 하도록 구성되는
컴퓨터 프로그램 제품이 제공된다.
제 4 양태에 따르면, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하는 단계와,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하는 단계와,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키는 단계를 포함하는
방법.
제 5 양태에 따르면, 적어도 하나의 프로세서 및 적어도 하나의 메모리를 포함하는 장치로서,
상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하는 것과,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하는 것과,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키는 것
을 수행하게 하는 코드가 저장되어 있는
장치가 제공된다.
제 6 양태에 따르면, 컴퓨터 프로그램 코드를 포함하는 비일시적 컴퓨터 판독가능 매체 상에서 구현된 컴퓨터 프로그램 제품으로서,
상기 프로그램 코드는 적어도 하나의 프로세서 상에서 실행될 때 장치 또는 시스템으로 하여금,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하게 하고,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하게 하고,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키게 하도록 구성되는
컴퓨터 프로그램 제품이 제공된다.
제 7 양태에 따르면, 제 1 양태의 방법을 수행하도록 구성된 장치가 제공된다.
제 8 양태에 따르면, 제 4 양태의 방법을 수행하도록 구성된 장치가 제공된다.
제 9 양태에 따르면, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하는 수단과,
오프셋 데이터를 수신하는 수단과,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하는 수단과,
상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하는 수단을 포함하는
장치가 제공된다.
제 10 양태에 따르면, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하는 수단과,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하는 수단과,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키는 수단을 포함하는
장치가 제공된다.
제 11 양태에 따르면, 제 1 요청에 의해 파일의 일부를 요청하는 단계를 포함하되, 상기 제 1 요청은 데이터 구조의 식별을 포함하고, 상기 식별은 유형 및 식별자를 포함하고, 상기 식별자는 동일 유형의 몇 개의 데이터 구조 중에서 상기 데이터 구조를 식별하는
방법이 제공된다.
제 12 양태에 따르면, 파일의 일부를 요청하는 제 1 요청을 수신하는 단계 － 상기 제 1 요청은 데이터 구조의 식별을 포함하고, 상기 식별은 유형 및 식별자를 포함하고, 상기 식별자는 동일 유형의 몇 개의 데이터 구조 중에서 상기 데이터 구조를 식별함 － 와,
상기 파일의 일부를 결정(concluding)하는 단계 － 상기 결정은 상기 유형 및 상기 식별자에 기초한 상기 데이터 구조의 식별을 포함함 － 와,
상기 파일의 일부를 송신함으로써 상기 제 1 요청에 응답하는 단계를 포함하는
방법이 제공된다.
따라서 본 발명의 몇몇 실시예를 일반적인 용어로 설명하였지만, 이제 반드시 축척대로 그려진 것은 아닌 첨부 도면에 대한 참조가 이루어질 것이다.
도 1은 국제 표준화기구(International Organization for Standardization) 기본 미디어 파일 포맷 박스 구조의 예시적 포함 계층(containment hierarchy)을 도시한다.
도 2는 ISO 기본 미디어 파일 포맷에 따른 단순화된 파일 구조를 도시한다.
도 3a는 미디어 파일을 구성하기에 적합한 장치의 예를 도시한다.
도 3b는 컨테이너 파일을 분해하기에 적합한 장치의 예를 도시한다.
도 4a는 일 실시예에 따른, 미디어 파일을 구성하는 방법의 흐름도를 도시한다.
도 4b는 일 실시예에 따른, 미디어 파일을 분해하는 방법의 흐름도를 도시한다.
도 5는 HTTP 스트리밍 시스템에 포함된 몇몇 기능 블록, 포맷 및 인터페이스의 예시를 도시한다.
도 6a는 HTTP 스트리밍 서버로서 동작하는 정규 웹 서버의 예를 도시한다.
도 6b는 동적 스트리밍 서버에 접속된 정규 웹 서버의 예를 도시한다.
도 7은 본 발명의 몇몇 실시예를 사용하는 전자 디바이스를 개략적으로 도시한다.
도 8은 본 발명의 몇몇 실시예를 사용하기에 적합한 사용자 장비를 개략적으로 도시한다.
도 9는 무선 및/또는 유선 네트워크 접속을 사용하여 접속된 본 발명의 실시예를 사용하는 전자 디바이스를 개략적으로 도시한다.
도 10은 다양한 실시예가 구현될 수 있는 일반적 미디어 통신 시스템의 일 예의 그래픽 표현이다.
도 1은 국제 표준화기구(International Organization for Standardization) 기본 미디어 파일 포맷 박스 구조의 예시적 포함 계층(containment hierarchy)을 도시한다.
도 2는 ISO 기본 미디어 파일 포맷에 따른 단순화된 파일 구조를 도시한다.
도 3a는 미디어 파일을 구성하기에 적합한 장치의 예를 도시한다.
도 3b는 컨테이너 파일을 분해하기에 적합한 장치의 예를 도시한다.
도 4a는 일 실시예에 따른, 미디어 파일을 구성하는 방법의 흐름도를 도시한다.
도 4b는 일 실시예에 따른, 미디어 파일을 분해하는 방법의 흐름도를 도시한다.
도 5는 HTTP 스트리밍 시스템에 포함된 몇몇 기능 블록, 포맷 및 인터페이스의 예시를 도시한다.
도 6a는 HTTP 스트리밍 서버로서 동작하는 정규 웹 서버의 예를 도시한다.
도 6b는 동적 스트리밍 서버에 접속된 정규 웹 서버의 예를 도시한다.
도 7은 본 발명의 몇몇 실시예를 사용하는 전자 디바이스를 개략적으로 도시한다.
도 8은 본 발명의 몇몇 실시예를 사용하기에 적합한 사용자 장비를 개략적으로 도시한다.
도 9는 무선 및/또는 유선 네트워크 접속을 사용하여 접속된 본 발명의 실시예를 사용하는 전자 디바이스를 개략적으로 도시한다.
도 10은 다양한 실시예가 구현될 수 있는 일반적 미디어 통신 시스템의 일 예의 그래픽 표현이다.
이하, 첨부된 도면을 참조하여 본 발명의 실시예가 더 상세히 설명되는데, 첨부된 도면에서는 본 발명의 모든 실시예가 아닌 일부 실시예가 도시된다. 실제로, 본 발명의 다양한 실시예는 많은 상이한 형태로 구현될 수 있으며, 여기에 제시된 실시예들에 한정되는 것으로 해석되어서는 안되며, 오히려, 이들 실시예는 본 개시가 적용 가능한 법적 요건을 만족시키도록 제공된다. 전반적으로, 동일한 도면 부호는 동일한 요소를 지칭한다. 여기에서 사용될 때, "데이터", "콘텐츠", "정보"라는 용어 및 유사한 용어는 본 발명의 몇몇 실시예에 따라 전송, 수신 및/또는 저장될 수 있는 데이터를 지칭하기 위해 상호 교환가능하게 사용될 수 있다. 따라서, 이러한 용어의 사용은 본 발명의 실시예의 정신 및 범위를 제한하는 것으로 간주되어서는 안된다.
또한, 여기에서 사용될 때, '회로'라는 용어는 (a) 하드웨어 전용 회로 구현(예를 들어, 아날로그 회로 및/또는 디지털 회로 내의 구현), (b) 장치로 하여금 본 명세서에서 설명된 하나 이상의 기능을 수행하도록 함께 동작하는 하나 이상의 컴퓨터 판독가능 메모리 상에 저장된 소프트웨어 및/또는 펌웨어 명령어를 포함하는 컴퓨터 프로그램 제품(들)과 회로의 조합, (c) 소프트웨어 또는 펌웨어가 물리적으로 존재하지 않더라도 동작을 위해 소프트웨어 또는 펌웨어를 필요로 하는, 예를 들어 마이크로프로세서(들) 또는 마이크로프로세서(들)의 일부와 같은 회로를 지칭한다. 이러한 '회로'의 정의는 임의의 청구항을 포함하여 여기에서 이 용어의 모든 사용에 적용된다. 다른 예로서, 본 명세서에서 사용될 때, "회로"라는 용어는 하나 이상의 프로세서 및/또는 그 부분(들) 및 수반하는 소프트웨어 및/또는 펌웨어를 포함하는 구현을 또한 포함한다. 또 다른 예로서, 본 명세서에서 사용되는 '회로'라는 용어는, 예를 들어, 이동 전화용 기저대역 집적 회로 또는 애플리케이션 프로세서 집적 회로, 또는 서버, 셀룰러 네트워크 디바이스, 다른 네트워크 디바이스 및/또는 다른 컴퓨팅 디바이스 내의 유사한 집적 회로를 포함한다.
본 명세서에 정의될 때, 비일시적 물리적 저장 매체(예를 들어, 휘발성 또는 비휘발성 메모리 디바이스)를 지칭하는 "컴퓨터 판독가능 저장 매체"는, 전자기 신호를 지칭하는 "컴퓨터 판독가능 전송 매체"와 구별될 수 있다.
이 명세서에서 사용되는 몇몇 추가 정의는 다음과 같이 설명될 수 있다. 코딩 포맷(미디어 압축 포맷이라고도 지칭될 수 있음)은 콘텐츠 정보를 비트스트림으로 코딩하는 특정 코딩 알고리즘의 작용에 관련될 수 있다. 미디어 데이터는 멀티미디어의 코딩된 표현, 예를 들어, 화상의 코딩된 표현, 이미지 또는 이미지들의 코딩된 표현, 오디오 또는 스피치의 코딩된 표현, 그래픽의 코딩된 표현을 형성하는 비트 시퀀스로서 정의될 수 있다. 멀티미디어의 코딩된 표현은 일반적으로 H.264/AVC, H.265/HEVC, AMR 등과 같은 코딩 포맷을 따른다. 컨테이너 파일 포맷은, 가능하다면 다양한 저장 및 전송 아키텍처를 전적으로 활용하여, 디코딩 및 재생을 위해 액세스되거나, 파일로서 전송되거나, 스트리밍될 수 있는 방식으로 생성된 비트스트림을 체계화하는 수단을 포함할 수 있다. 또한, 컨테이너 파일 포맷은 수신된 실시간 스트림을 파일에 기록하는 것뿐만 아니라 미디어의 교환 및 편집을 용이하게할 수 있다. 메타데이터는 미디어 데이터에 대한 구조적 또는 설명적 정보를 포함하는 것으로 이해될 수 있다.
미디어 데이터가 컨테이너 파일 포맷을 사용하여 저장되는 경우, 메타데이터의 적어도 일부는 컨테이너 파일 포맷의 파일 포맷 구조에 의해 표현될 수 있다. 그러나, 메타데이터의 일부는 컨테이너 파일 포맷과 구별되는 메타데이터 포맷을 사용하여 표현될 수도 있다. 예를 들어, 메타데이터 포맷 및 컨테이너 파일 포맷은 상이한 사양들로 특정될 수 있고/있거나 이들은 상이한 기본 유닛들 또는 요소들을 사용할 수도 있다. 예를 들어, 컨테이너 파일 포맷은 키-길이-값 트리플릿을 포함하는 요소에 기초할 수 있는데, 여기서 키는 정보의 유형을 나타내고, 길이는 정보의 크기를 나타내고, 값은 정보 자체를 포함한다. ISO 기본 미디어 파일 포맷에서 사용된 박스 구조는 키-길이-값 트리플릿을 포함하는 컨테이너 파일 요소의 예로서 간주될 수 있다. 같은 예를 계속하면, 메타데이터 포맷은 XML(Extensible Markup Language) 스킴(scheme)에 기초할 수 있다.
몇몇 미디어 파일 포맷 표준은, ISO 기본 미디어 파일 포맷(ISO/IEC 14496-12, ISOBMFF로 축약될 수 있음), MPEG-4 파일 포맷(ISO/IEC 14496-14, MP4 포맷으로도 공지됨), ISO/IEC 14496-15(H.264/AVC 및/또는 H.265/HEVC에 사용될 수 있는 "ISO 기본 미디어 파일 포맷의 NAL(Network Abstraction Layer) 유닛 구조화된 비디오의 운반), 고효율 이미지 파일 포맷(ISO/IEC 23008-12, HEIF로 축약될 수 있음) 및 3GPP(3rd Generation Partnership Project) 파일 포맷(3GPP TS 26.244, 3GP 포맷으로도 공지됨)을 포함할 수 있다. H.265/HEVC의 다중 계층 확장(MV-HEVC, SHVC, 3D-HEVC) 뿐만 아니라 H.264/AVC의 확장 가능 비디오 코딩(scalable video coding: SVC) 및 다중 뷰 비디오 코딩(multiview video coding: MVC) 확장에 대한 파일 포맷은 ISO/IEC 14496-15의 일부로서 특정된다. ISO 파일 포맷은 ISO 파일 포맷 자체를 제외하고 위에서 언급한 모든 파일 포맷의 파생을 위한 기초이다.
ISOBMFF의 몇몇 개념, 구조 및 사양은 실시예가 구현될 수 있는 기초가 되는 컨테이너 파일 포맷의 예로서 아래에서 설명된다. 본 발명의 양태는 ISOBMFF에 한정되지 않고, 오히려 설명은 그 위에서 본 발명이 부분적으로 또는 완전히 실현될 수 있게 하는 하나의 가능한 기초를 위해 제공된다.
ISO 기본 미디어 파일 포맷의 한 빌딩 블록을 박스(box)라고 한다. 예를 들어, MovieBox 또는 MovieFragmentBox로부터 언급된 코딩된 샘플 데이터는 항상 MediaDataBox에 존재할 수 있다. 각 박스는 헤더와 페이로드를 가질 수 있다. 박스 헤더는 박스 유형과 박스 크기를 바이트 단위로 나타낸다. 모든 미디어 데이터 및 관련 메타데이터는 박스로 캡슐화될 수 있다. 박스는 다른 박스들을 동봉(enclose)할 수 있으며, ISO 파일 포맷은 특정 유형의 박스 내에서 허용되는 박스 유형을 특정한다. 또한, 몇몇 박스의 존재는 각 파일에서 필수적일 수 있지만 다른 박스의 존재는 선택사항일 수 있다. 또한, 몇몇 박스 유형의 경우, 파일에 둘 이상의 박스가 존재하는 것을 허용할 수 있다. 따라서, ISO 기본 미디어 파일 포맷은 박스의 계층 구조를 특정하는 것으로 간주될 수 있다. ISO 기본 미디어 파일의 각 박스는 4 문자 코드(4CC, fourCC)로 식별될 수 있다. 4 문자 코드는, (문자를 8 비트 값, 특정 비트 엔디언(endianness) 및 특정 바이트 엔디언으로 변환하는 것을 가정함으로써) 32 비트의 부호 없는 정수에 의해 상호 교환 가능하게 표현될 수 있다. 헤더는 박스의 유형 및 크기에 대한 정보를 제공할 수 있다. ISOBMFF 박스 구조의 예시적 포함 계층(containment hierarchy)이 도 1에 도시되어 있다.
ISOBMFF는 다양한 사용 사례를 고려하여 설계되는데, 그러한 사용 사례는 (a) 콘텐츠 생성 (b) 교환 (c) 통신 및 (d) 로컬 및 스트리밍 프레젠테이션을 포함할 수 있다. DASH(Dynamic Adaptive Streaming over HTTP)는 그 목적을 위해 ISOBMFF를 사용하는 통신 포맷의 예이다. DASH는 원래 HTTP(Hypertext Transfer Protocol)를 통해 전송되는 포맷으로 의도되었지만, MBMS(multimedia broadcast/multicast service) 및 DVB(Digital Video Broadcasting) 기반 IP(Internet Protocl) 방송과 같은 3 GPP 기반 프로토콜에서도 사용되었다. 이러한 전송 프로토콜 중 일부는 양방향이지만 일부는 단방향이다. 또한, 이러한 전송 프로토콜 중 일부는 손실되기 쉬운 환경에서 작용한다.
ISOBMFF에 따르면, 파일(file)은 별도의 박스에 동봉(enclose)될 수 있는 미디어 데이터와 메타데이터를 포함할 수 있다. 미디어 데이터는 미디어 데이터(mdat) 박스에 제공될 수 있고, 무비(moov) 박스는 메타데이터를 동봉하기 위해 사용될 수 있다. 몇몇 경우에, 파일을 실행하기 위해서는 mdat 및 moov 박스가 모두 있어야 한다. 무비(moov) 박스는 하나 이상의 트랙을 포함할 수 있으며, 각 트랙은 하나의 대응하는 트랙 박스에 존재할 수 있다. 트랙은 예를 들어, 다음과 같은 메타데이터 유형, 즉, 미디어, 힌트, 시한부(timed) 메타데이터 중 하나일 수 있다. 미디어 트랙은 미디어 압축 포맷(및 ISO 기본 미디어 파일 포맷에 대한 캡슐화)에 따라 포맷된 샘플(미디어 샘플이라고도 지칭될 수 있음)을 지칭한다. 힌트 트랙은, 표시된 통신 프로토콜을 통한 전송을 위해 패킷을 구성하기 위한 쿡북 명령어(cookbook instructions)을 포함하는 힌트 샘플을 지칭한다. 쿡북 명령어는 패킷 헤더 구성에 대한 가이던스를 포함할 수 있으며 패킷 페이로드 구성을 포함할 수 있다. 패킷 페이로드 구성에서는 다른 트랙이나 아이템에 존재하는 데이터가 참조될 수 있다. 이와 같이, 예를 들어, 다른 트랙 또는 아이템에 존재하는 데이터는 패킷 구축 프로세스 동안 특정 트랙 또는 아이템 내의 어떤 데이터가 패킷으로 복사되도록 지시되는지에 대해 참조에 의해 표시될 수 있다. 시한부 메타데이터 트랙은 언급된 미디어 및/또는 힌트 샘플을 설명하는 샘플을 지칭할 수 있다. 하나의 미디어 유형의 프레젠테이션을 위해, 하나의 미디어 트랙이 선택될 수 있다. 트랙의 샘플은 샘플의 표시된 디코딩 순서에서 예컨대 1씩 증가될 수 있는 샘플 번호와 내재적으로 연관될 수 있다. 트랙의 제 1 샘플은 샘플 번호 1과 연관될 수 있다.
'트랙(trak)' 박스는 샘플 테이블(Sample Table) 박스를 포함한다. 샘플 테이블 박스는 예컨대, 트랙에서 미디어 샘플을 인덱싱하는 시간과 데이터를 모두 포함한다. 샘플 테이블 박스는 샘플 설명(Sample Description) 박스를 포함해야 한다. 샘플 설명 박스는 박스에 포함된 샘플 엔트리의 수를 특정하는 엔트리 카운트 필드를 포함한다. 샘플 설명 박스는 적어도 하나의 샘플 엔트리를 포함해야 한다. 샘플 엔트리 포맷은 트랙에 대한 핸들러 유형에 의존한다. 샘플 엔트리는 사용된 코딩 유형 및 해당 코딩에 필요한 임의의 초기화 정보에 대한 상세 정보를 제공한다.
도 2는 ISO 기본 미디어 파일 포맷에 따른 단순화된 파일 구조의 예를 도시한다. 도 2에 도시된 바와 같이, 파일(90)은 moov 박스(92) 및 mdat 박스(94)를 포함할 수 있고, moov 박스(92)는 각각 비디오 및 오디오에 대응하는 트랙들(트랙(96) 및 트랙(98))을 포함할 수 있다.
ISO 기본 미디어 파일 포맷은 프레젠테이션이 하나의 파일에 포함되도록 제한하지 않는다. 따라서, 프레젠테이션은 여러 파일에 포함될 수 있다. 예를 들어, 하나의 파일은 전체 프레젠테이션에 대한 메타데이터를 포함할 수 있으며, 이에 따라 프레젠테이션 자체가 포함되도록 모든 미디어 데이터를 포함할 수 있다. 다른 파일들은, 사용되는 경우, ISO 기본 미디어 파일 포맷으로 포맷될 필요가 없고, 미디어 데이터를 포함하도록 사용될 수 있으며, 사용되지 않은 미디어 데이터 또는 기타 정보를 포함할 수도 있다. ISO 기본 미디어 파일 포맷은 프레젠테이션 파일의 구조에만 관련된다. 미디어 파일의 미디어 데이터가 ISO 기본 미디어 파일 포맷 또는 그 파생 포맷으로 특정된 포맷으로 특정되는 바와 같이 포맷된다는 점에서 미디어 데이터 파일의 포맷은 ISO 기본 미디어 파일 포맷 또는 파생 포맷에 의해서만 제한될 수 있다.
외부 파일을 참조하는 능력은 데이터 참조를 통해 실현될 수 있다. 몇몇 예에서 각 트랙에 포함된 샘플 설명 박스는 샘플 엔트리의 리스트를 제공할 수 있는데, 각각의 샘플 엔트리는 사용된 코딩 유형에 대한 상세 정보와 해당 코딩에 필요한 임의의 초기화 정보를 제공한다. 청크의 모든 샘플과 트랙 프래그먼트의 모든 샘플은 동일한 샘플 엔트리를 사용할 수 있다. 청크는 하나의 트랙에 대한 연속적인 샘플 세트로 정의될 수 있다. 각 트랙에 포함될 수도 있는 데이터 참조(dref) 박스는, URL(uniform resource locator), URN(uniform resource name) 및/또는 메타데이터를 포함하는 파일에 대한 자체 참조의 인덱싱된 리스트를 정의할 수 있다. 샘플 엔트리는 데이터 참조 박스(신택스에서 DataReferenceBox로 지칭될 수 있음)의 하나의 인덱스를 가리킬 수 있으며, 따라서 각 청크 또는 트랙 프래그먼트의 샘플을 포함하는 파일을 나타낸다.
DataReferenceBox는 파일에 의해 참조된 미디어 데이터의 잠재적 위치(들)를 선언하는 박스의 리스트를 포함한다. DataReferenceBox는 DataInformationBox에 포함되고, DataInformationBox는 차례로 MediaInformationBox 또는 MetaBox에 포함된다. MediaInformationBox에 포함된 경우, 트랙의 각 샘플 엔트리는 DataReferenceBox 내의 박스(들)의 리스트의 리스트 엔트리를 참조하는 데이터 참조 인덱스를 포함한다. MetaBox에 포함된 경우, ItemLocationBox는, 각 아이템에 대해, DataReferenceBox 내의 박스(들)의 리스트의 리스트 엔트리를 참조하는 데이터 참조 인덱스를 제공한다. DataReferenceBox 내의 박스(들)는 FullBox로부터 확장되는데, 즉, 박스 헤더 내에 버전 및 플래그 필드를 포함한다. DataReferenceBox에는 두 가지 박스 유형이 포함되도록 특정되었는데, DataEntryUrlBox 및 DataEntryUrnBox는 각각 URL 및 URN 데이터 참조를 제공한다. DataEntryUrlBox 또는 DataEntryUrnBox의 플래그 필드의 최하위 비트가 1일 경우, 각각의 데이터 참조는 포함 파일(containing file) 자체를 참조하고, DataEntryUrlBox 또는 DataEntryUrnBox 내에는 어떠한 URL 또는 URN 스트링도 제공되지 않는다.
무비 프래그먼트 기능은 무비 박스에 존재할 수도 있는 메타데이터를 다수의 프래그먼트로 분할하는 것을 가능하게 할 수 있다. 각 프래그먼트는 트랙의 특정 시구간에 대응할 수 있다. 즉, 무비 프래그먼트 기능은 파일 메타데이터 및 미디어 데이터를 인터리빙할 수 있다. 결과적으로, 무비 박스의 크기가 제한되고 위에 언급된 사용 사례가 실현될 수 있다.
몇몇 예에서, 무비 프래그먼트에 대한 미디어 샘플은, 이들이 moov 박스와 동일한 파일에 있는 경우, mdat 박스에 존재할 수 있다. 그러나 무비 프래그먼트의 메타데이터의 경우, moof 박스가 제공될 수 있다. moof 박스는 이전에 moov 박스에 있던 특정 재생 시간에 대한 정보를 포함할 수 있다. moov 박스는 단독으로 여전히 유효한 무비를 나타낼 수 있지만, 그에 더하여, 무비 프래그먼트들이 동일한 파일 내에서 이어질 것임을 나타내는 mvex 박스를 포함할 수 있다. 무비 프래그먼트는 시간적으로 moov 박스와 연관되는 프레젠테이션을 확장할 수 있다.
무비 프래그먼트 내에는 트랙당 대략 0부터 복수개까지를 포함하는 트랙 프래그먼트 세트가 존재할 수 있다. 트랙 프래그먼트는 차례로 대략 0부터 복수개까지의 트랙 런을 포함할 수 있으며, 문서의 각각은 그 트랙에 대한 샘플들의 연속적인 런이다. 이러한 구조 내에서, 많은 필드는 선택사항이며 디폴트로 설정될 수 있다. moof 박스에 포함될 수 있는 메타데이터는 moov 박스에 포함될 수 있는 메타데이터의 서브세트로 제한될 수 있으며, 몇몇 경우에 다르게 코딩될 수 있다. moof 박스에 포함될 수 있는 박스와 관련된 세부사항은 ISO 기본 미디어 파일 포맷 사양에서 찾을 수 있다. 자체 포함된 무비 프래그먼트는 파일 순서대로 연속되는 moof 박스와 mdat 박스로 구성될 수 있으며, mdat 박스는 (moof 박스가 메타데이터를 제공하는) 그 무비 프래그먼트의 샘플을 포함하며 임의의 다른 무비 프래그먼트(즉, 임의의 다른 moof 박스)의 샘플을 포함하지 않는다.
ISO 기본 미디어 파일 포맷은 특정 샘플과 연관될 수 있는 시한부 메타데이터에 대한 세 가지 메커니즘, 즉, 샘플 그룹, 시한부 메타데이터 트랙 및 샘플 보조 정보를 포함한다. 파생된 사양은 이러한 세 가지 메커니즘 중 하나 이상과 유사한 기능을 제공할 수 있다.
ISO 기본 미디어 파일 포맷의 샘플 그룹화는 그룹화 기준에 기초하여 하나의 샘플 그룹의 멤버가 되도록 트랙 내에 각 샘플을 할당하는 것으로 정의될 수 있다. 샘플 그룹화의 샘플 그룹은 인접한 샘플로 제한되지 않으며 인접하지 않은 샘플을 포함할 수도 있다. 트랙 내의 샘플에 대해 2개 이상의 샘플 그룹화가 존재할 수 있으므로, 각 샘플 그룹화는 그룹화 유형을 나타내는 유형 필드를 가질 수 있다. 샘플 그룹화는 두 개의 링크된 데이터 구조에 의해 표현될 수 있는데, (1) SampleToGroup 박스(sbgp 박스)는 샘플 그룹에 대한 샘플 할당을 나타내고, (2) SampleGroupDescription 박스(sgpd 박스)는 그룹의 속성을 설명하는 각 샘플 그룹에 대한 샘플 그룹 엔트리를 포함한다. 상이한 그룹화 기준에 기초하여 SampleToGroup 및 SampleGroupDescription 박스의 다수의 인스턴스가 존재할 수 있다. 이들은 그룹화 유형을 표시하기 위해 사용되는 유형 필드에 의해 구별될 수 있다. 'sbgp'및 'sgpd' 박스는, 그룹화 유형의 값을 사용하고 박스의 몇몇 버전에서는 그룹화 유형 파라미터의 값을 또한 사용하여 링크될 수 있다. 'sbgp'박스는 특정 샘플이 속하는 샘플 그룹 설명 엔트리의 인덱스를 나타낸다.
ISOBMFF를 준수하는 파일은 메타 박스(4 문자 코드: 'meta') 내에 아이템, 메타 아이템 또는 메타데이터 아이템으로 지칭되는 임의의 비시한부 객체를 포함할 수 있다. 메타 박스의 명칭은 메타데이터를 지칭하지만, 아이템은 일반적으로 메타데이터 또는 미디어 데이터를 포함할 수 있다. 메타 박스는 파일의 최상위 레벨에서, 무비 박스(4 문자 코드: 'moov') 내에, 그리고 트랙 박스(4 문자 코드: 'trak') 내에 있을 수 있지만, 파일 레벨, 무비 레벨 또는 트랙 레벨 각각에서 기껏해야 하나의 메타 박스가 발생할 수 있다. 메타 박스는 'meta' 박스 콘텐츠의 구조 또는 포맷을 나타내는 'hdlr' 박스를 포함해야 할 수도 있다. 메타 박스는 참조될 수 있는 임의 개수의 아이템을 나열하고 특성화할 수 있으며, 각각의 아이템은 파일명과 연관될 수 있고 정수 값인 아이템 식별자(item_id)에 의해 파일과 고유하게 식별된다. 메타데이터 아이템은 예를 들어 메타 박스의 'idat' 박스 또는 'mdat' 박스에 저장되거나 별도의 파일에 존재할 수 있다. 메타데이터가 파일 외부에 있는 경우, 그 위치는 DataInformationBox(4 문자 코드: 'dinf')에 의해 선언될 수 있다. 메타데이터가 XML 신택스를 사용하여 포맷화되고 MetaBox에 직접 저장되어야하는 특정 경우에, 메타데이터는 XMLBox(4 문자 코드: 'xml') 또는 BinaryXMLBox(4 문자 코드: 'bxml')로 캡슐화될 수 있다. 아이템은 인접한 바이트 범위로 저장되거나 각각 인접한 바이트 범위인 여러 익스텐트(extent)에 저장될 수 있다. 즉, 아이템은, 예컨대 인터리빙을 가능하게 하기 위해, 익스텐트들로 프래그먼트화되어 저장될 수 있다. 익스텐트는 리소스의 바이트의 연속적 서브세트이고, 익스텐트를 연결함으로써 리소스가 형성될 수 있다.
계층(파일, 무비 또는 트랙)의 임의의 레벨에서 둘 이상의 메타 박스를 지원하기 위해, 메타 박스 컨테이너 박스('meco')는 하나의 ISO 기본 미디어 파일 포맷으로 사용될 수 있다. 메타 박스 컨테이너 박스는 계층의 임의의 레벨(파일, 무비 또는 트랙)에서 임의 개수의 추가 메타 박스를 운반할 수 있다. 이는 예컨대 동일한 메타데이터가 두 개의 서로 다른 대안적 메타데이터 시스템에 제시되는 것을 허용할 수 있다. 메타 박스 관계 박스('mere')는 서로 다른 메타 박스가 서로 어떻게 관련되는지, 예컨대, 이들이 정확하게 동일한 메타데이터를 포함(그러나, 상이한 스킴으로 설명됨)하고 있는지 여부 또는 하나가 다른 하나의 수퍼세트를 나타내는지 여부를 설명하는 것을 가능하게 한다.
고효율 이미지 파일 포맷(High Efficiency Image File Format: HEIF)은 이미지 및 이미지 시퀀스를 저장하기 위해 MPEG(Moving Picture Experts Group)에 의해 개발된 표준이다. 이 표준은 고효율 비디오 코딩(High Efficiency Video Coding: HEVC) 표준에 따라 코딩된 데이터의 파일 캡슐화를 용이하게 한다. HEIF는 사용 된 ISO 기본 미디어 파일 포맷(ISOBMFF)의 상부에 구축되는 풍부한 기능 세트를 포함한다.
HEIF는 스틸 화상 캡처, 저장 및 공유에서부터 이미지 버스트의 공유 또는 컴퓨터 사진술(computational photography)에 의한 처리를 위한 이미지 세트 저장과 같은 다수의 이미지 사용 사례에 이르기까지 다양한 광범위한 사용 사례를 가능하게 한다. 컴퓨터 사진술은 HEIF로부터 혜택을 누릴 수 있는 새로운 범주의 사용 사례를 형성한다. 관련 이미지의 세트는 서로 다른 화상들 간의 관계를 나타내는 연관된 메타데이터와 함께 단일 파일에 저장될 수 있다. 이러한 신흥 사용 사례의 예는, 상이한 초점 거리로 캡쳐된 화상 세트로부터 원하는 초점을 갖는 이미지를 선택함으로써 샷(shot)을 리포커싱하는 것, 상이한 노출을 갖는 화상을 결합하는 것에 의한 높은 동적 범위 사진술, 및 연결된 풍경을 갖는 화상 세트로부터의 무지향성 또는 파노라마 이미지의 구축을 포함한다.
ISOBMFF 구조 및 기능은 HEIF의 설계에서 대부분 사용되며 HEIF 파일은 또한 ISOBMFF를 준수한다. HEIF에 대한 기본 설계는 스틸 이미지가 아이템으로 저장되고 이미지 시퀀스가 트랙으로 저장되는 것을 포함한다. 임의 개수의 이미지 아이템은 동일한 파일에 저장될 수 있다.
HEIF의 맥락에서, 이어지는 박스들은 루트 레벨의 '메타' 박스 내에 포함될 수 있으며 다음에서 설명되는 것처럼 사용될 수 있다. HEIF에서, 'meta' 박스의 핸들러(Handler) 박스의 핸들러 값은 'pict'이다. 코딩된 미디어 데이터를 포함 하는 리소스(동일한 파일에 있든 유니폼 리소스 식별자에 의해 식별되는 외부 파일에 있든 상관없음)는 데이터 정보('dinf') 박스를 통해 해석(reslove)되고, 아이템 위치('iloc') 박스는 참조된 파일 내의 모든 아이템의 위치 및 크기를 저장한다. 아이템 참조('iref') 박스는 유형화된 참조를 사용하여 아이템들 간의 관계를 문서화한다. 아이템들의 집합 중에 어떤 방식으로 다른 것들에 비해 가장 중요하다고 여겨지는 아이템이 있는 경우, 이 아이템은 주요 아이템('pitm') 박스에 의해 표시된다. 여기에 언급된 박스 외에도 'meta' 박스는 아이템을 설명하기 위해 필요할 수 있는 다른 박스를 포함하도록 유연성을 가질 수도 있다.
MIME(Multipurpose Internet Mail Extension) 유형으로도 알려진 인터넷 미디어 유형은, 리소스 또는 파일의 유형을 식별하기 위해 다양한 애플리케이션에 의해 사용된다. MIME 유형은 미디어 유형, 하위유형 및 0개 이상의 선택적 파라미터로 구성된다.
설명된 바와 같이, MIME은, 비디오 및 오디오, 이미지, 소프트웨어 등과 같이 인터넷에서 여러 종류의 데이터 파일을 전송 및 수신할 수 있게 해주는 이메일 프로토콜의 확장이다. 인터넷 미디어 유형은 파일에 포함된 데이터 유형을 나타 내기 위해 인터넷에서 사용되는 식별자이다. 이러한 인터넷 미디어 유형은 또한 콘텐츠 유형으로 불릴 수 있다. 상이한 미디어 포맷을 나타낼 수 있는 여러 가지 MIME 유형/하위유형 조합이 존재한다. 콘텐츠 유형 정보는 미디어 전송의 시작 시에 전송 엔티티에 의해 MIME 헤더 내에 포함될 수 있다. 따라서, 수신 엔터티는 코덱의 이용 가능한 세트가 주어지면 특정 요소가 렌더링될 수 있는지 여부를 판정하기 위해 이러한 미디어 콘텐츠의 세부사항을 조사할 필요가 있을 수 있다. 특히 최종 시스템의 리소스가 제한되어 있거나 최종 시스템에 대한 접속이 제한된 대역폭을 갖는 경우, 콘텐츠 유형으로부터 콘텐츠가 렌더링될 수 있는지 여부만을 알면 도움이 될 수 있다.
'코덱(codec)'과 '프로파일(profiles)'이라는 두 개의 파라미터는 다양한 MIME 유형 또는 유형/하위유형 조합과 함께 사용되도록 특정되어 내부에 포함된 미디어 포맷에 의해 사용된 코덱 또는 전체 컨테이너 포맷의 프로파일(들)의 명확한 설명을 허용할 수 있다.
포함된 미디어를 렌더링하도록 표시된 특정 코덱으로 콘텐츠를 레이블링함으로써 수신 시스템은 코덱이 최종 시스템에서 지원되는지 여부를 판정할 수 있으며, 지원되지 않을 경우 (콘텐츠 거부, 상황 알림 전송, 지원되는 유형으로 콘텐츠의 트랜스코딩, 필요한 코덱 페치 및 설치, 표시된 코덱의 서브세트를 지원하기에 충분한지 여부를 판정하기 위한 추가 검사 등과 같은) 적절한 조치를 취할 수 있다. ISOBMFF로부터 파생된 파일 포맷에 대해, 코덱 파라미터는 쉼표로 분리된 하나 이상의 리스트 아이템의 리스트를 포함하는 것으로 간주될 수 있다. 코덱 파라미터의 리스트 아이템이 ISOBMFF 준수 파일의 트랙을 나타낼 경우, 리스트 아이템은 트랙의 샘플 엔트리의 4 문자 코드를 포함할 수 있다.
프로파일 MIME 파라미터는 콘텐츠가 준수하는 사양의 전반적 표시를 수신기에 제공할 수 있다. 이는 컨테이너 포맷과 그 콘텐츠의 몇몇 사양에 대한 호환성의 표시이다. 수신기는 선언된 프로파일 중 어떤 것을 자신이 지원하지, 그리고 그것이 무엇을 의미하는지를 알기 위한 검사에 의해 자신이 처리하고 렌더링할 수 있는 콘텐츠의 규모(extent)를 산출할 수 있다. ISOBMFF 파일에 대한 프로파일 파라미터는 파일에 포함된 호환 가능한 브랜드의 리스트를 포함하도록 특정될 수 있다.
HTTP(Hypertext Transfer Protocol)는 예컨대 비디오 스트리밍 애플리케이션에서 인터넷을 통한 실시간 멀티미디어 콘텐츠의 전달을 위해 널리 사용된다. 사용자 데이터그램 프로토콜(User Datagram Protocol: UDP)을 통한 실시간 전송 프로토콜(Real-time Transport Protocol: RTP)의 사용과는 달리, HTTP는 쉽게 구성할 수 있으며 일반적으로 방화벽과 NAT(Network Address Translator)를 통과하는 것이 허용되는데, 이는 멀티미디어 스트리밍 애플리케이션에 매력적이다.
HTTP의 청크(chunk)된 전송 코딩(예를 들어, 청크된 전달)은, 예컨대 HTTP GET 응답의 페이로드 몸체를, 자신의 크기 표시자를 각각 갖는 일련의 청크로서 전달하기 위해 랩핑한다. 청크된 전송 코딩은 미지의 크기를 갖는 콘텐츠 스트림이 길이가 구분된 버퍼의 시퀀스로 전송되는 것을 가능하게 하므로, 송신자는 접속 지속성을 유지할 수 있고 수신자는 전체 메시지를 언제 받았는지를 알 수 있다.
ISO/IEC 국제 표준 23009-1은 HTTP를 통한 동적 적응형 스트리밍(DASH)을 특정한다. 이하, MPEG-DASH의 일부 개념, 포맷 및 동작이, 실시예가 구현될 수 있는 비디오 스트리밍 시스템의 예로서 설명된다. 본 발명의 양태는 MPEG-DASH에 한정되지 않고, 오히려 그 설명은 본 발명이 부분적으로 또는 완전히 실현될 수 있는 가능한 기반을 위해 제공된다.
HTTP를 통한 동적 적응형 스트리밍(DASH)에서, 멀티미디어 콘텐츠는 HTTP 서버에 캡처되어 저장될 수 있으며 HTTP를 사용하여 전달될 수 있다. 콘텐츠는 서버에 두 부분, 즉, 사용 가능한 콘텐츠, 다양한 대안, URL 주소 및 기타 특성의 목록을 설명하는 MPD(Media Presentation Description)와, 단일 또는 다중 파일에 실제 멀티미디어 비트스트림을 청크 형태로 포함하는 세그먼트로 저장될 수 있다. 콘텐츠를 재생하기 위해, DASH 클라이언트는 예컨대, HTTP, 이메일, 썸 드라이브, 방송 또는 기타 전송 방법을 사용하여 MPD를 획득할 수 있다. MPD를 분석함으로써, DASH 클라이언트는, 프로그램 타이밍, 미디어 콘텐츠 이용가용성, 미디어 유형, 해상도, 최소 및 최대 대역폭, 멀티미디어 컴포넌트의 다양한 인코딩된 대안, 액세스 가능성 기능 및 필수 디지털 권한 관리(digital right management: DRM), 네트워크상의 미디어-컴포넌트 위치 및 기타 콘텐츠 특성의 존재를 알 수 있다. 이런 정보를 사용하여, DASH 클라이언트는 적절한 인코딩된 대안을 선택할 수 있고, 예컨대 HTTP GET 요청을 사용하여 세그먼트를 페치함으로써 콘텐츠의 스트리밍을 시작할 수 있다. 네트워크 처리량 변동을 고려한 적절한 버퍼링 후에, 클라이언트는 후속 세그먼트를 계속 페치하고 네트워크 대역폭 변동을 모니터링할 수 있다. 클라이언트는 적절한 버퍼를 유지하기 위해 (낮은 비트 레이트 또는 높은 비트 레이트를 갖는) 상이한 대안의 세그먼트를 페치함으로써 어떻게 사용 가능한 대역폭으로 적응화할 것인지를 결정할 수 있다.
미디어 프레젠테이션 설명(medial presentation description: MPD)은 클라이언트가 HTTP를 통한 동적 적응형 스트리밍을 설정하기 위한 정보를 제공할 수 있다. MPD는 GET 세크먼트 요청을 만들기 위해 각 세그먼트의 HTTP-URL(uniform resource locator)과 같은 미디어 프레젠테이션을 설명하는 정보를 포함할 수 있다. DASH에서는 계층적 데이터 모델을 사용하여 다음과 같이 요약되는 미디어 프레젠테이션을 구축할 수 있다. 미디어 프레젠테이션은 하나 이상의 구간의 시퀀스를 포함할 수 있고, 각각의 구간은 하나 이상의 그룹을 포함할 수 있고, 각각의 그룹은 하나 이상의 적응 세트를 포함할 수 있고, 각각의 적응 세트는 하나 이상의 프레젠테이션을 포함할 수 있으며, 각각의 프레젠테이션은 하나 이상의 세그먼트를 포함할 수 있다. 프레젠테이션은 비트 레이트, 해상도, 언어, 코덱 등과 같은 인코딩 선택에 따라 다를 수 있는 미디어 콘텐츠 또는 그 서브세트의 대안적 선택 중 하나이다. 세그먼트는 일정 지속시간의 미디어 데이터와, 포함된 미디어 콘텐츠를 디코딩하여 제시하기 위한 메타데이터를 포함할 수 있다. 세그먼트는 URI(Uniform Resource Indicator)에 의해 식별될 수 있으며 HTTP GET 요청에 의해 요청될 수 있다. 세그먼트는 HTTP-URL과 연관된 데이터의 단위로 정의될 수 있으며 선택적으로 MPD에 의해 특정된 바이트 범위로 정의될 수도 있다.
DASH 서비스는 주문형 서비스 또는 라이브 서비스로 제공될 수 있다. 주문형 서비스의 경우 MPD는 정적이며, 콘텐츠 제공자가 MPD를 공개할 때 미디어 프레젠테이션의 모든 세그먼트는 이미 사용 가능하다. 그러나 라이브 서비스의 경우, MPD는 MPD에 의해 사용된 세그먼트 URL 구성 방법에 따라 정적 또는 동적일 수 있으며, 콘텐츠가 콘텐츠 제공자에 의해 생성되어 DASH 클라이언트에게 공개될 때 세그먼트는 연속적으로 생성될 수 있다. 세그먼트 URL 구성 방법은 템플릿 기반 세그먼트 URL 구성 방법 또는 세그먼트 리스트 생성 방법일 수 있다. 템플릿 기반 세그먼트 URL 구성 방법의 경우, DASH 클라이언트는 세그먼트를 요청하기 전에 MPD를 업데이트하지 않고 세그먼트 URL을 구성할 수 있다. 세그먼트 리스트 생성 방법의 경우, DASH 클라이언트는 세그먼트 URL을 얻기 위해 업데이트된 MPD를 주기적으로 다운로드해야 할 수 있다. 따라서 라이브 서비스의 경우 템플릿 기반 세그먼트 URL 구성 방법이 세그먼트 리스트 생성 방법보다 우수할 수 있다.
DASH의 맥락에서, 다음의 정의가 사용될 수 있다. 미디어 콘텐츠 컴포넌트 또는 미디어 컴포넌트는 개별적으로 미디어 스트림으로 인코딩될 수 있는 할당된 미디어 컴포넌트 유형을 갖는 미디어 콘텐츠의 하나의 연속 컴포넌트로서 정의될 수 있다. 미디어 콘텐츠는 하나의 미디어 콘텐츠 구간 또는 미디어 콘텐츠 구간의 연속 시퀀스로 정의될 수 있다. 미디어 콘텐츠 컴포넌트 유형은 오디오, 비디오 또는 텍스트와 같은 단일 유형의 미디어 콘텐츠로 정의될 수 있다. 미디어 스트림은 미디어 콘텐츠 컴포넌트의 인코딩된 버전으로 정의될 수 있다.
초기화 세그먼트는 미디어 세그먼트에 캡슐화된 미디어 스트림을 제시하기 위해 필요한 메타데이터를 포함하는 세그먼트로 정의될 수 있다. ISOBMFF 기반 세그먼트 포맷에서, 초기화 세그먼트는 모든 샘플에 대한 메타데이터를 포함하지 않을 수도 있는 무비 박스('moov')를 포함할 수 있는데, 즉, 샘플에 대한 메타데이터는 'moof boxes'에 제공된다.
미디어 세그먼트는 컨테이너 파일 포맷 및/또는 사용중인 미디어 포맷 또는 포맷들을 준수하는 세그먼트로 정의될 수 있으며, 0 이상의 선행 세그먼트 및 초기화 세그먼트(있는 경우)와 결합될 때 재생을 가능하게 한다. 미디어 세그먼트는 정상 속도로 재생하기 위한 미디어 데이터의 특정 지속시간을 포함할 수 있으며, 그러한 지속시간은 미디어 세그먼트 지속시간 또는 세그먼트 지속시간으로 지칭될 수 있다. 콘텐츠 작성자 또는 서비스 제공자는 원하는 서비스 특성에 따라 세그먼트 지속시간을 선택할 수 있다. 예를 들어 짧은 종단(end) 간 대기시간을 달성하기 위해 라이브 서비스에서는 상대적으로 짧은 세그먼트 지속시간을 사용할 수 있다. 그 이유는 세그먼트가 DASH에 대한 미디어 데이터를 생성하는 개별 단위이기 때문에 세그먼트 지속시간은 DASH 클라이언트에 의해 인지된 종단 간 대기시간의 하한이 될 수 있기 때문이다. 콘텐츠 생성은 미디어 데이터의 전체 세그먼트가 서버에 이용 가능해지는 방식으로 수행될 수 있다. 또한, 많은 클라이언트 구현은 세그먼트를 GET 요청에 대한 단위로 사용할 수 있다. 따라서, 라이브 서비스에 대한 몇몇 배치에서, 세그먼트는 미디어 세그먼트의 전체 지속시간이 이용가능하고 세그먼트로 인코딩되어 캡슐화될 때에만 DASH 클라이언트에 의해 요청될 수 있다. 주문형 서비스의 경우, 세그먼트 시속시간을 선택하는 다양한 전략이 사용될 수 있다.
세그먼트는, 예컨대 세그먼트를 여러 부분으로 다운로드하기 위해, 서브세그먼트로 더 분할될 수 있다. 서브세그먼트는 완전한 액세스 단위를 포함해야 할 수도 있다. 서브세그먼트는 각 서브세그먼트에 대한 프레젠테이션 시간 범위 및 바이트 범위를 매핑하는 정보를 포함하는 (신택스에서 SegmentIndexBox로 지칭될 수도 있는) 세그먼트 인덱스 박스(들)에 의해 인덱싱될 수 있다. 세그먼트 인덱스 박스는 또한 그 지속시간 및 바이트 오프셋을 시그널링함으로써 세그먼트의 서브세그먼트 및 스트림 액세스 포인트를 설명할 수도 있다. DASH 클라이언트는 세그먼트 인덱스 박스(들)로부터 획득된 정보를 사용하여 바이트 범위 HTTP 요청을 사용하는 특정 서브세그먼트에 대한 HTTP GET 요청을 만들 수 있다. 상대적으로 긴 세그먼트 지속시간이 사용되면, HTTP 응답 크기를 비트 레이트 적응을 위해 합리적이고 유연하게 유지할 수 있도록 서브세그먼트가 사용될 수 있다. 세그먼트의 인덱싱 정보는 그 세그먼트의 시작 부분에 있는 단일 박스에 넣어 지거나 세그먼트의 여러 인덱싱 박스에 분산될 수 있다. 계층형, 데이지 체인(daisy chain) 및 하이브리드와 같은 다양한 분산 방법이 가능하다. 이 기법은 세그먼트의 시작 부분에 큰 박스를 추가하는 것을 방지할 수 있으며, 따라서 초기 다운로드 지연 가능성을 방지할 수 있다.
각 미디어 세그먼트에는 고유한 URL(바이트 범위를 갖는 것도 가능함), 인덱스, 명시적 또는 암시적 시작 시간 및 지속시간이 할당될 수 있다. 각 미디어 세그먼트는 적어도 하나의 스트림 액세스 포인트를 포함할 수 있는데, 이는 해당 포인트로부터의 데이터만 사용하여 전방으로 디코딩을 시작할 수 있는 미디어 스트림 내의 무작위 액세스 또는 스위치 포인트이다.
세그먼트를 다수의 부분으로 다운로드하는 것을 가능하게 하기 위해, 세그먼트 인덱스 박스를 사용하여 서브세그먼트를 시그널링하는 방법이 활용될 수 있다. 이 박스는 그 지속시간 및 바이트 오프셋을 시그널링함으로써 세그먼트의 서브세그먼트 및 스트림 액세스 포인트를 설명한다. DASH 클라이언트는 부분적인 HTTP GET 요청을 사용하여 서브세그먼트를 요청하기 위해 인덱싱 정보를 사용할 수 있다. 세그먼트의 인덱싱 정보는 해당 세그먼트의 시작 부분에 있는 단일 박스에 넣어지거나 세그먼트의 다양한 인덱싱 박스로 분산될 수 있다. 계층형, 데이지 체인 및 하이브리드와 같은 다양한 분산 방법이 가능하다. 이 기법은 세그먼트의 시작 부분에 큰 박스를 추가하는 것을 방지할 수 있고, 따라서 초기 다운로드 지연 가능성을 방지할 수 있다.
MPEG-DASH는 ISO 기본 미디어 파일 포맷 및 MPEG-2 전송 스트림에 대한 세그먼트-컨테이너 포맷을 정의한다. 다른 사양은 다른 컨테이너 포맷에 기초한 세그먼트 포맷을 특정할 수 있다. 예를 들어, 마트로스카(Matroska) 컨테이너 파일 포맷에 기초한 세그먼트 포맷이 제안되었으며 다음과 같이 요약될 수 있다. 마트로스카 파일이 DASH 세그먼트로서 또는 유사하게 운반될 때, DASH 단위와 마트로스카 단위의 연관은 다음과 같이 특정될 수 있다. (DASH의) 서브세그먼트는 마트로스카-캡슐화된 콘텐츠의 하나 이상의 연속 클러스터로 정의될 수 있다. DASH의 초기화 세그먼트는 EBML 헤더, (마트로스카의) 세그먼트 헤더, (마트로스카의) 세그먼트 정보 및 트랙을 포함해야 할 수 있으며, 선택적으로 다른 레벨 요소 및 패딩을 포함할 수 있다. DASH의 세그먼트 인덱스는 마트로스카의 큐(Cues) 요소를 포함할 수 있다.
DASH는 다양한 네트워크 대역폭과 일치하도록 적응 세트 내의 상이한 표현(Representation)들로부터 미디어 세그먼트 및/또는 서브세그먼트를 동적으로 요청함으로써 속도 적응을 지원한다. DASH 클라이언트가 표현을 위/아래로 전환할 때 표현 내의 코딩 종속성을 고려해야 할 수 있다. 미디어 디코딩에서, 표현 스위치는 H.264/AVC와 같은 비디오 코딩 기술에 사용될 수 있는 랜덤 액세스 포인트(random access point: RAP)에서만 발생할 수 있다. 디코딩되지 않을 미디어 데이터의 요청 및 전송을 방지하기 위해, RAP는 미디어 세그먼트 및/또는 서브세그먼트의 시작 부분에 정렬될 수 있으며, MPD 및/또는 세그먼트 인덱스 박스는 미디어 세그먼트 및/또는 서브세그먼트의 시작 부분에서 RAP의 정렬을 나타내기 위해 사용될 수 있다. 결과적으로, DASH 클라이언트는, 표현 전환이 수행될 때 대상 표현의 제 1 세그먼트 및/또는 서브세그먼트가 RAP로 시작하고 소스 및 대상 표현의 세그먼트 및/또는 서브세그먼트가 (시간에 대해) 정렬되도록, 어떤 세그먼트 및/또는 서브세그먼트를 요청할지를 결정할 수 있다. DASH에서는, 표현에 액세스하고 표현들 간에 전환하기 위한 코덱 독립적 솔루션을 제공하기 위해 스트림 액세스 포인트(Stream Access Point: SAP)라는 보다 일반적인 개념이 도입된다. DASH에서, SAP은 미디어 스트림의 재생이 (만일 존재한다면, 초기화 세그먼트에서 데이터의 초기화가 선행되는) 해당 위치부터 시작하는 표현 데이터에 포함된 정보만 사용하여 시작할 수 있도록 하는 표현의 위치로서 특정된다. 따라서 SAP에서 표현 전환이 수행될 수 있다.
MPEG-DASH와 유사한 스트리밍 시스템은 예를 들어 IETF 인터넷 드래프트 draft-pantos-http-live-streaming-13(및 동일한 인터넷 드래프트의 다른 버전)에서 특정된 HTTP 라이브 스트리밍(HLS로도 알려짐)을 포함한다. MPD에 대응하는 매니페스트 포맷으로서 HLS는 확장된 M3U 포맷을 사용한다. M3U는 원래 오디오 파일 용으로 개발된 멀티미디어 재생 리스트용 파일 포맷이다. M3U 재생 리스트는 개별 라인으로 구성된 텍스트 파일이며, 각 라인은 URI 또는 공백이거나, 태그 또는 코멘트를 나타내는 '#' 문자로 시작한다. URI 라인은 미디어 세그먼트 또는 재생 리스트 파일을 식별한다. 태그는 #EXT로 시작한다. HLS 사양은 키-값 쌍으로 간주될 수 있는 다수의 태그를 특정한다. 태그의 값 부분은 쉼표로 분리된 속성-값 쌍 리스트인 속성 리스트를 포함할 수 있으며, 여기서 속성-값 쌍은 AttributeName=AttributeValue 신택스를 갖는 것으로 간주될 수 있다. 따라서, HLS M3U8 파일의 태그는 MPD 또는 XML의 요소와 유사한 것으로 간주될 수 있으며, HLS M3U8 파일의 속성은 MPD 또는 XML의 속성과 유사한 것으로 간주될 수 있다. HLS의 미디어 세그먼트는 MPEG-2 전송 스트림에 따라 포맷되고, 단일 MPEG-2 프로그램을 포함한다. 각 미디어 세그먼트는 PAT(Program Association Table) 및 PMT(Program Map Table)로 시작하는 것이 추천된다.
하이퍼텍스트 마크업 언어 버전 5.1(HTML 5.1)은 사용자 에이전트(예컨대, 웹 브라우저)가 선택할 수 있는 여러 이미지 리소스를 콘텐츠 작성자가 사용할 수 있는 다수의 사용 사례를 지원한다. 예를 들어, 다양한 사용자는 서로 다른 환경 특성을 가질 수 있고, 작성자는 동일한 이미지 콘텐츠를 보여주기는 하지만 상이한 렌더링 크기를 갖거나 상이한 이미지 포맷을 사용하기를 원할 수 있고/있거나, 작성자는 상이한 이미지 콘텐츠를 보여주기를 원할 수 있다.
이하, 환경 특성의 몇몇 비제한적 예가 간단히 설명될 것이다. 사용자 디바이스의 물리적 화면 크기는 디바이스마다 다를 수 있다. 예를 들어, 휴대 전화의 화면은 랩톱 컴퓨터의 화면보다 작을 수 있다. 이 차이는 이미지의 렌더링 크기가 뷰포트 크기에 따라 다를 때만 의미 있을 수 있다. 사용자 디바이스의 화면 픽셀 밀도는 상이한 디바이스에서 다를 수도 있다. 상이한 디바이스는 또한 물리적 화면 크기에 관계없이 상이한 픽셀 밀도를 가질 수 있다. 예를 들어, 한 휴대 전화의 화면은 다른 휴대 전화의 화면에 비해 인치당 더 많은 물리적 픽셀을 가질 수 있다. 디바이스 간에 줌 레벨에 차이가 있을 수도 있고 시간이 지남에 따라 단일 사용자의 줌 레벨이 변경될 수도 있다. 예를 들어, 사용자는 특정 이미지를 확대하여 더 자세히 볼 수 있다. 줌 레벨과 화면 픽셀 밀도는 모두 CSS 픽셀 당 물리적 화면 픽셀 수(캐스케이딩 스타일 시트-언어)에 영향을 줄 수 있다. 이 비율은 디바이스-픽셀 비율로 지칭될 수 있다. 또한, 화면 방향은 장치마다 다를 수 있으며 시간이 지남에 따라 단일 사용자에 대해 변경될 수도 있다. 예를 들어, 태블릿 컴퓨터는 업라이트로 유지되거나 90도 회전되어, 화면이 "세로방향" 또는 "가로방향"이 되도록 할 수 있다. 또한, 사용자의 네트워크 속도, 네트워크 대기시간 및 대역폭 비용에 차이가 있을 수 있으며, 시간이 지남에 따라 단일 사용자에 대해 변경될 수도 있다. 사용자는 직장에서는 고속의 짧은 대기시간 및 일정 비용의 접속을 사용하고 집에서는 저속의 짧은 대기시간 및 일정 비용의 접속을 사용하고, 그 이외의 곳에서는 가변 속도, 긴 대기시간 및 가변 비용의 접속을 사용하고 있을 수 있다.
이하, 동일한 이미지 콘텐츠를 보여주지만 상이한 렌더링 크기 및/또는 상이한 이미지 포맷을 사용하는 몇몇 비제한적 예가 제공될 것이다. 렌더링 크기를 선택하는 것은 예를 들어 뷰포트의 폭에 의존할 수 있다. 이것은 뷰포트 기반 선택으로 지칭될 수 있다.
웹 페이지는 상단에 항상 전체 뷰포트 폭에 걸쳐있는 배너를 가질 수 있다. 이 경우, (최대화된 브라우저 창을 가정하면) 이미지의 렌더링 크기는 화면의 물리적 크기에 의존한다.
다른 웹 페이지는 열이 있는 이미지를 가질 수 있는데, 물리적 크기가 작은 화면의 경우 단일 열, 물리적 크기가 중간인 화면의 경우 2열, 물리적 크기가 큰 화면의 경우 3열이며, 각 경우에 뷰포트를 채우도록 이미지는 렌더링 크기가 변한다. 이 경우, 이미지의 렌더링 크기는 화면이 작더라도 2열 레이아웃에 비해 1열 레이아웃에서 더 클 수 있다.
웹 콘텐츠 작성자는 이미지의 렌더링 크기에 따라 상이한 이미지 콘텐츠를 보여주기를 원할 수 있다. 이것은 아트 디렉션(art direction)으로 지칭될 수 있다.
(최대화된 브라우저 창을 가정하면) 물리적 크기가 큰 화면에서 웹 페이지가 시청될 때, 작성자는 이미지의 중요한 부분을 둘러싸는 몇몇 낮은 관련성 부분을 포함하고자 할 수 있다. 물리적 크기가 작은 화면에서 동일한 웹 페이지가 시청될 때, 작성자는 이미지의 중요한 부분만 표시하고자 할 수 있다.
웹 페이지의 작성자는 사용자 에이전트가 지원하는 이미지 포맷에 따라 상이한 이미지 포맷을 사용하여 동일한 이미지 콘텐츠를 보여주기를 원할 수 있다. 이것은 일반적으로 이미지 포맷 기반 선택으로 지칭된다.
웹 페이지는 JPEG(Joint Photographic Experts Group), WebP 및 JPEG XR(JPEG eXtended Range) 이미지 포맷의 몇몇 이미지를 가질 수 있으며, 후자의 두 가지는 JPEG와 비교하여 압축 능력이 더 나은 것으로 알려져 있다. 서로 다른 사용자 에이전트는 서로 다른 이미지 포맷을 지원할 수 있고 몇몇 포맷은 더 나은 압축률을 제공하기 때문에, 작성자는 더 나은 포맷을 지원하지 않는 사용자 에이전트에 대해 JPEG 폴백을 제공하면서 이를 지원하는 사용자 에이전트에 더 나은 포맷을 제공하고자 할 수 있다.
위의 상황은 상호 배타적이지 않다. 예를 들어, 서로 다른 디바이스-픽셀-비율에 대한 상이한 리소스를 아트 디렉션에 대한 상이한 리소스와 결합하는 것이 합리적일 수 있다.
HTML의 더 오래된 버전뿐만 아니라 HTML 5.1은 이미지를 나타내는 img 요소를 포함한다. img 요소는 페이징되거나 스크립팅되지 않은 비대화형, 선택적으로는 애니메이팅된 이미지 리소스를 참조하는 src 속성을 포함할 수 있다. 더 오래된 HTML 버전도 src 속성을 파싱(parsing)하므로 src 속성을 통해 제공되는 이미지는 디폴트 또는 폴백 이미지로 간주될 수 있다.
img 요소는 srcset 속성을 포함할 수도 있다. 존재할 경우, 이것은 쉼표로 분리된 하나 이상의 이미지 후보 스트링을 포함한다.
이미지 후보 스트링은 이 리스트 아래에 설명된 추가 제한 사항과 함께 순서대로 다음과 같은 컴포넌트를 포함할 수 있다. 먼저, 이미지 후보는 0개 이상의 공백 문자를 포함할 수 있고, 다음에 페이징되거나 스크립팅되지 않은 비대화형, 선택적으로는 애니메이팅된 이미지 리소스를 참조하고 쉼표(,)로 시작하거나 끝나지 않는 유효한 비어 있지 않은 URL(Uniform Resource Locator)을 포함한다. URL 다음에는 0개 이상의 공백 문자가, 그 뒤에 0 또는 폭 디스크립터와 픽셀 밀도 디스크립터 중 하나가 존재할 수 있다. 마지막으로 0개 이상의 공백 문자가 존재할 수 있다.
폭 디스크립터는 공백 문자, 폭 디스크립터 값을 나타내는 0보다 큰 수를 제공하는 유효한 음이 아닌 정수, 및 라틴 소문자 "w" 문자를 포함할 수 있다.
픽셀 밀도 디스크립터는 공백 문자, 픽셀 밀도 디스크립터 값을 나타내는 0보다 큰 수를 제공하는 유효한 부동 소수점 수, 및 라틴 소문자 "x" 문자를 포함할 수 있다.
디스크립터는 이미지 후보를 특성화하고 따라서 원하는 특성을 충족시키는 적절한 이미지를 선택하기 위해 사용될 수 있다.
img 요소는 HTML 5.1의 픽처(picture) 요소에 포함되거나 포함되지 않을 수 있다.
HTML 5.1은 하나의 img 요소가 뒤따르는 0개 이상의 소스(source) 요소를 포함하는 픽처 요소를 포함한다. 픽처 요소는, 포함된 img 요소에 다수의 소스를 제공하여 작성자로 하여금 화면 픽셀 밀도, 뷰포트 크기, 이미지 포맷 및 다른 요인에 기초하여 사용할 이미지 리소스에 대해 사용자 에이전트를 선언적으로 제어하거나 그에 힌트를 제공할 수 있게 해 주는 컨테이너이다. 이것은 그 자식(children)을 나타낸다.
픽처 요소 내의 소스 요소는 작성자로 하여금 img 요소에 대한 다수의 대체 소스 세트를 특정할 수 있게 한다. 픽처 요소 내의 소스 요소는 srcset 속성을 포함할 수 있으며, 크기(size) 속성을 포함할 수 있고, srcset 속성이 임의의 이미지 후보 스트링 중 폭 디스크립터를 포함하고 선택적으로 미디어 속성을 포함하고 선택적으로 유형(type) 속성을 포함할 경우, 크기 속성을 조건부로 포함해야 한다. 미디어(media) 속성은 유효한 미디어 쿼리 리스트를 포함한다. 유형 속성은 유효한 MIME 유형을 포함한다. 존재할 경우, 크기, 미디어 및 유형 속성은 소스 세트(즉, 동일한 소스 요소의 srcset 속성에서 식별된 이미지)를 특성화할 수 있으며, 따라서 원하는 애플리케이션 특성 또는 선호도를 충족시키는 적절한 소스 세트를 선택하기 위해 사용될 수 있다. 또한, 이 소스 세트로부터, 적절한 이미지가 선택될 수 있다.
링크는 두 개의 리소스(이 중 하나는 현재 문서임) 간의 연결을 나타내는 a, area, 및 link(링크) 요소에 의해 작성된 개념 구조이다. HTML에는 두 가지 종류의 링크가 존재할 수 있다. 첫 번째 유형은 외부 리소스에 대한 링크이다. 현재 문서를 보강하기 위해 외부 리소스에 대한 링크가 사용될 수 있는데, 이는 일반적으로 사용자 에이전트에 의해 자동으로 처리된다. 두 번째 유형은 하이퍼링크이다. 하이퍼 링크는 일반적으로 사용자 에이전트에 의해 사용자에게 노출되는 다른 리소스에 대한 링크이므로, 사용자는, 예컨대 브라우저에서 그 리소스를 방문하거나 다운로드하기 위해, 사용자 에이전트로 하여금 해당 리소스를 내비게이팅하게 할 수 있다.
href 속성 및 rel 속성을 갖는 링크 요소의 경우, rel 속성의 키워드에 대한 링크가 그 키워드에 대해 정의된 것처럼 생성되어야 한다. 마찬가지로 href 속성과 rel 속성을 갖는 a 및 area 요소의 경우, rel 속성의 키워드에 대한 링크가 해당 키워드에 대해 정의된 것처럼 생성되어야 한다. 그러나 링크 요소와 달리, rel 속성을 갖지 않거나, rel 속성이 하이퍼링크를 특정하는 것으로 정의되는 키워드를 갖지 않는 a 및 area 요소는 하이퍼링크를 또한 생성해야 한다. 이 함축된 하이퍼링크는 요소의 노드 문서를 요소의 href 속성에 의해 제공된 리소스에 링크하는 것 이상의 특별한 의미를 갖지 않을 수 있다(링크 유형을 갖지 않음).
다수의 링크 유형이 HTML 5.1 및 다른 사양에서 특정된다. 링크 유형은 rel 속성의 값으로서 사용된 특정 스트링으로 특정된다. 예를 들어, 프리페치(prefetch) 링크 유형은 대상 리소스가 선점적으로 캐시(cache)되어야 하는 것을 특정한다.
URI(Uniform Resource Identifier)는 리소스의 이름을 식별하기 위해 사용되는 문자의 스트링으로 정의될 수 있다. 이러한 식별은 특정 프로토콜을 사용하여 네트워크를 통해 리소스 표현과 상호작용하는 것을 가능하게 한다. URI는 URI에 대한 구체적인 신택스 및 관련 프로토콜을 특정하는 스킴(scheme)를 통해 정의된다. URI는 스킴 부분(예컨대, URI에 대한 프로토콜을 식별하는 것) 및 리소스를 식별하는 계층 부분을 포함하며, 이 두 부분은 콜론 문자로 분리된다. URI는 선택적으로 쿼리 부분(문자 '?'에 의해 분리됨) 및/또는 프래그먼트 부분(문자 '#'에 의해 분리됨)을 포함한다. URL(uniform resource locator) 및 URN(uniform resource name)은 URI의 형태이다. URL은 웹 리소스를 식별하고 리소스의 표현에 따라 행동하거나 리소스의 표현을 획득하는 수단을 특정하는 URI로 정의될 수 있으며, 주요 액세스 메커니즘과 네트워크 위치를 모두 특정한다. URN은 특정 네임스페이스에서 이름에 의해 리소스를 식별하는 URI로 정의될 수 있다. URN은 리소스의 위치나 액세스 방법을 암시하지 않고 리소스를 식별하기 위해 사용될 수 있다.
(예컨대, 프래그먼트 식별자 없이) URL의 베이스 부분에 의해 표시된 파일과 같은 리소스의 일부에 액세스하기 위해 특정 콘텐츠 유형에 대해 URL 프래그먼트 식별자(URL 형식으로도 지칭됨)가 특정될 수 있다. URL 프래그먼트 식별자는 예를 들어 URL 내의 해시('#') 문자에 의해 식별될 수 있다. ISOBMFF의 경우, 무비 프래그먼트에서 잠재적으로 발견되는 메타 박스들을 포함하여, URL 프래그먼트 "#X"는 track_ID가 X인 트랙을 지칭하고, "#item_ID=" 및 "#item_name="은 파일 레벨 메타 박스(들)를 지칭하고, "#item_ID=" 및 "#/item_name="은 무비 박스 내의 메타 박스(들)를 지칭하고, "#track_ID=X/item_ID=" 및 "#track_ID=X/item_name="은 track_ID가 X인 트랙 내의 메타 박스를 지칭하는 것으로 특정될 수 있다.
ISOBMFF에서, 트랙박스(TrackBox)에 의해 참조된 샘플(즉, 무비 프래그먼트에 의해 참조된 샘플을 제외함)의 정확한 위치는, (a) DataReferenceBox (b) SampleToChunkBox (c) ChunkOffsetBox 및 (d) SampleSizesBox에 의해 제공된 정보를 사용하여 계산될 수 있다. 또한, 샘플의 위치 결정은 파일의 시작부를 사용하는 오프셋 계산을 수반한다. 무비 프래그먼트에 의해 참조되는 샘플의 경우, 샘플의 정확한 위치는 TrackFragmentHeaderBox 및 TrackFragmentRunBox에 제공된 정보를 사용하여 계산될 수 있으며, 샘플의 위치 결정은 파일의 시작 또는 무비 프래그먼트의 시작부를 참조로 사용하는 오프셋 계산을 수반할 수 있다. 오프셋을 사용하면 파일을 편집할 때 취약해질 수 있다. 예를 들어, 계산된 오프셋을 파괴하고 파일을 디코딩할 수 없도록 렌더링하기 위해, 파일의 시작부와 MediaDataBox 사이에 바이트를 간단히 추가하거나 삭제하는 것으로 충분할 수 있다. 이는 파일에서 계산되고 설정된 모든 오프셋이 편집을 완료한 후에 유효해야 하는 것을 보장하도록 파일을 편집하는 모든 엔티티가 유의해야 함을 의미한다.
URL 프래그먼트를 사용하면 예컨대 HTTP GET 요청을 사용하여 파일 또는 리소스의 일부를 요청할 수 있다. 그러나, URL 프래그먼트를 사용하여 부분 수신된 파일이 파일 시작부와 관련된 어드레싱을 사용하는 경우, 서버가 파일 포맷(예컨대, ISOBMFF)을 준수하는 유효한 리소스를 반환하는 것이 어려울 수 있거나 플레이어가 해결된 요청으로부터 초래된 리소스를 파싱하는 것이 불가능할 수도 있다.
이하에서는, 부분 파일 수신을 초래하는 두 가지 개별 사용 사례의 예가 제공될 것이다.
첫 번째 예는 의도적인 부분 파일 수신과 관련된다. 이 예에서는, 컨테이너 파일이 서버에서 사용될 수 있다. 컨테이너 파일은 미디어 트랙 및/또는 아이템을 포함하며, 이들의 서브세트는 소비(예컨대, 디스플레이 또는 재생)하기에 충분하다. 예를 들어, 컨테이너 파일은 예컨대 상이한 코덱 및/또는 상이한 공간 해상도를 갖는 다수의 코딩된 버전으로 동일한 원본 이미지를 포함하는 이미지 컨테이너 파일일 수 있다. 예컨대 디스플레이 해상도에 적합한 다른 이미지가 다운로드되는 동안 디스플레이될 수 있는 섬네일 이미지를 디스플레이하기 위해 코딩된 이미지의 서브세트를 페치하는 것으로 충분하다. 따라서 클라이언트는 개별적으로 또는 적절한 번들로 미디어 트랙 및/또는 아이템의 서브세트를 파일로부터 요청한다. 단일 컨테이너 파일은 서버(들) 및/또는 콘텐츠 전달 네트워크(들)에서의 콘텐츠 관리에 바람직할 수 있다.
두 번째 예는 우발적인 부분 파일 수신과 관련된다. 파일은 MBMS 파일 전달 스택(3GPP(Third Generation Partnership Project)에 의해 특정된 멀티미디어 브로드캐스트 및 멀티캐스트 서비스)과 같은 신뢰할 수 없는 프로토콜을 사용하여 전송될 수 있다. 박스가 불완전하게 수신되었는지 여부가 알려지도록 손실이 검출될 수 있다고 가정할 수 있다. 그러나 수신된 파일의 일부가 누락될 수 있다. 수신기는 부분적으로 수신된 파일이 유효하거나 부합하는지 여부를 쉽게 결정할 수 없다. 파일이 오류가 없는 것으로 표시되거나 가정되는 ISOBMFF와 같은 포맷으로 파일을 표시하는 방식으로 부분적으로 수신된 파일을 저장하는 것은 적절하지 않을 수 있다. 마찬가지로, 오류 없는 파일 및/또는 오류 없는 미디어 비트스트림(들)을 각각 가정하는 파일 파서 및/또는 미디어 디코더로 부분적으로 수신된 파일을 처리하는 것은 적절하지 않을 수 있다.
특정 박스 유형의 경우, ISOBMFF는 동일한 4 문자 코드의 여러 박스가 파일 계층의 동일한 레벨에서 나타나는 것을 허용한다. 예를 들어, 파일의 루트 레벨에 여러 개의 MediaDataBox를 갖는 것이 허용된다. 특정 박스는 예컨대 파일의 시작에 대한 오프셋과 같은 오프셋을 사용하여 다른 박스에 대한 참조 또는 유사한 것을 포함할 수 있다. 예를 들어, MovieBox는 MediaDataBox(들)의 콘텐츠를 참조할 수 있는 청크 오프셋과 같은 참조를 포함한다. 파일이 부분적으로 수신될 경우, 파일을 올바르게 파싱할 수 있도록 이러한 참조의 무결성이 유지되는 것이 보장되어야 한다.
DASH의 전송 단위(세그먼트 또는 서브세그먼트)는 하나 이상의 자체 포함 무비 프래그먼트를 포함할 수 있는데, 자체 포함 무비 프래그먼트는 MovieFragmentBox 및 MovieFragmentBox에 설명된 미디어 데이터를 포함하는 MediaDataBox를 포함할 수 있다. 이런 설계는 모든 미디어 데이터가 코딩된 후에 만 전송 단위가 사용될 수 있기 때문에 라이브 콘텐츠 배포의 지연을 유발할 수 있다. 예를 들어, 1초의 세그먼트 지속시간은 세그먼트를 사용할 수 있도록 하기 위해 인코딩 및 파일 캡슐화에서 대략 동일한 지연(인코딩 및 캡슐화에서 발생하는 처리 지연도 추가됨)을 유발할 수 있다.
실시예에 따르면, 파일-레벨 박스는 박스 순서 및 다른 파일-레벨 박스의 존재와 상관없이 독립적으로 구성될 수 있다. 그러한 파일은 재정렬 가능한 파일(reorderable file)로 지칭될 수 있다. 일 실시예에서, 파일 및/또는 파일의 설명에 파일이 재정렬 가능한지 여부가 표시된다. 일 실시예에서, 상기 표시는 파일이 재정렬 가능함을 나타내는 특정 브랜드를 FileTypeBox에 포함시킴으로써 수행된다. 일 실시예에서, 특정 브랜드는 모든 MediaDataBox가 식별자를 포함하고 모든 파일 내부 미디어 데이터 참조가 미디어 데이터를 포함하는 각각의 MediaDataBox에 관련된다는 것을 나타낸다. 일 실시예에서, 브랜드에 부합하는 플레이어는 다음과 같이 동작한다. (예컨대, 다른 실시예에서 설명한 바와 같이 데이터 참조를 통해) 특정 id_value의 MediaDataBox가 참조되었지만 그 id_value와 동일한 mdat_identifier를 갖는 MediaDataBox가 파일에 존재하지 않을 경우, 플레이어는 관련 트랙 또는 아이템의 처리를 생략한다. 또한, 플레이어는 그러한 트랙 또는 아이템에 의존하는 임의의 트랙 또는 아이템의 처리를 생략한다. 플레이어는 예를 들어 트랙 참조 또는 아이템 참조를 통해 이러한 의존성을 결정한다.
일 실시예에서, 루트 레벨과 같은 파일의 동일한 계층 레벨에서 두 번 이상 나타날 수 있는 박스 유형의 박스는, 동일한 파일 계층 레벨 내의 동일한 유형의 다른 박스들과 그것을 구별하는 식별자로 태그되거나, 박스의 콘텐츠로부터 그러한 식별자가 도출된다. 일 실시예에서, 상기 태깅 또는 도출은 다른 박스(들)로부터의 참조가 발생할 수 있는 박스 또는 박스 유형에 대해서만 수행된다.
파일이나 참조된 파일에 포함된 많은 MediaDataBox가 존재할 수 있으므로, 샘플이 위치하는 MediaDataBox를 고유하게 인식할 수 있는 방법이 있어야 한다. 일 실시예에서, 다수의 MediaDataBox 중 한 MediaDataBox를 인식하는 능력은, 각 MediaDataBox를 식별자로 태깅함으로써 달성된다. 다음과 같은 것을 포함하여 MediaDataBox를 태깅하는 다수의 방법이 존재하지만, 그에 제한되지는 않는다. 제 1 예로서, 예컨대 특정 비트 카운트의 부호 없는 정수 값일 수 있는 식별자 값은 박스의 박스 헤더 바로 뒤에 첨부될 수 있다. 다른 예에 따르면, UUID(universally unique identifier)가 박스의 박스 헤더 다음에 첨부될 수 있다. 다른 예에서, MD5 체크섬(checksum)과 같은 식별자가 박스 콘텐츠의 서브세트 또는 전체 박스로부터 도출되어 박스를 식별하기 위해 사용된다. 또 다른 옵션으로, 재정렬 가능성은 특정 유형의 하나 이상의 박스(들)가 MediaDataBox의 바로 앞에(또는 다음에) 위치하여 MediaDataBox의 식별자를 포함하도록 제한될 수 있다.
실시예에 따르면, 파일에 표시된 주소 또는 포인터라고도 하는 오프셋은 어드레싱된 데이터를 포함하는 박스의 시작에 관련된다. 많은 경우에, 주소는 어드레싱된 데이터를 포함하는 파일-레벨 박스에 관련될 수 있다. 일 실시예에서, 샘플을 나타내는 오프셋은 샘플을 포함하는 MediaDataBox에 관한 것이다.
오프셋은 오프셋이 어드레싱하는 데이터와 다른 파일-레벨 박스에 포함될 수 있으므로, 오프셋을 포함하는 박스는 어드레싱된 데이터를 포함하는 박스와 연관될 수 있다. 일 실시예에서, 연관은, 파일 또는 참조된 파일에 포함된 MediaDataBox의 각각에 포함되는 예를 들어 mdat_identifier로 불릴 수 있는 식별자를 사용하여 구현될 수 있다. 임의의 MediaDataBox로부터의 데이터를 활용할 수 있는 트랙은 해당 식별자를 사용하여 MediaDataBox를 참조해야 할 수 있으며, MediaDataBox의 시작부를 참조로 사용하여 오프셋이 계산된다. 파일 내에서 아이템 데이터의 위치는 식별자를 사용하여 특정 MediaDataBox를 참조하는 것과 특정 MediaDataBox의 시작부와 관련된 오프셋에 의해 제공될 수 있다.
재정렬할 수 있는 파일의 기능으로 인해 파일을 쉽게 편집할 수 있다. 예를 들어, 제 1 트랙을 포함하는 파일에 제 2 트랙이 추가되는 상황에서, 제 2 트랙의 미디어 데이터가 제 1 트랙의 미디어 데이터를 포함하는 것과 다른 MediaDataBox에 배치될 때, 제 1 트랙의 샘플의 오프셋은 다시 도출될 필요가 없다. 트랙 또는 아이템이 재정렬 가능한 파일에 추가될 때, 그 미디어 데이터는 새로운 MediaDataBox에 포함될 수 있다. MovieBox에는 새로운 TrackBox 또는 아이템 정보가 추가된다. 오프셋은 각각의 미디어 데이터를 운반하는 MediaDataBox에 관련되므로, 파일에 이미 존재하는 트랙이나 아이템의 위치 오프셋 정보는 업데이트될 필요가 없다. 추가된 트랙 또는 아이템의 위치 오프셋 정보는 새로 추가된 MediaDataBox와 관련되므로 계산하기 쉽다. 위치 오프셋은 파일 순서가 MediaDataBox에 앞서는 박스들의 크기에 의존하지 않으므로, 수정된 MovieBox를 파일의 시작 부분에 쉽게 배치할 수 있다. 재정렬 가능한 파일에서 트랙이나 아이템이 제거될 경우, MediaDataBox에 제거된 트랙이나 아이템의 것이 아닌 다른 미디어 데이터가 없는지 여부가 확인될 수 있다. 그렇다면, 나머지 트랙 또는 아이템의 위치 오프셋에 영향을 주지 않고 MediaDataBox는 제거될 수 있다. 마찬가지로, 나머지 트랙 및 아이템의 위치 오프셋을 다시 계산할 필요없이 TrackBox 또는 아이템 정보는 파일에서 제거될 수 있다.
일 실시예에서, 파일-레벨 박스를 식별하기 위해 URL 프래그먼트 네이밍 스킴이 도입된다. 이 프래그먼트 네이밍 스킴을 사용하는 URL은 URL 프래그먼트에 의해 식별된 파일-레벨 박스로 구성된 리소스로 해석된다. 동일한 이름 또는 유형의 여러 박스가 파일 레벨에 존재할 수 있으므로, URL 프래그먼트 네이밍 스킴은 그 파일-레벨 박스를 동일한 박스 유형 또는 이름의 다른 파일-레벨 박스와 식별하는 수단을 또한 포함한다. 예를 들어, MediaDataBox의 전술된 식별자가 URL 프래그먼트에 포함될 수 있다.
일 실시예에서, 파일 및/또는 파일의 설명 또는 표현은 파일-레벨 박스의 시퀀스에 관한 정보를 포함한다. 정보는 파일의 콘텐츠의 디렉토리 또는 테이블로 간주될 수 있다. 이 정보는 예를 들어 중단없는 재생에 필요한 다운로드 순서에 대해 고객에게 알리는 데 유용할 수 있다. 정보는 파일-레벨 박스에 대한 URL 프래그먼트가 설명에 기초하여 생성되게 할 수 있다. 일 실시예에서, MediaDataBox의 식별자는 파일-레벨 박스의 시퀀스에 관한 정보의 일부를 포함할 수 있다. 일 실시예에서, MediaDataBox의 식별자는 예컨대 표준에서 사전 정의될 수 있거나 정보 내에 표시될 수 있는 넘버링 스킴을 따른다. MediaDataBox 넘버링 스킴이 사용 중일 때, MediaDataBox의 식별자는 각 MediaDataBox 마다 존재하지 않고, 각 MediaDataBox에 대한 넘버링 스킴으로부터 도출될 수 있다.
부분적 파일 수신이 가능할 수 있다. 일 실시예에서, 수신기는 파일-레벨 박스를 수신하고 있거나 수신했을 수 있다. 수신기는 선험적 정보를 가질 수 있거나 또는 수신기는 파일 내의 표시로부터 및/또는 파일의 설명에서 파일이 재정렬 가능한 것으로 결정할 수 있다. 수신기는 자신이 정확하게 수신한 파일-레벨 박스를 수신된 파일에 기록할 수 있다. 수신기는 수신된 파일을 플레이어에게 제공할 수 있고/있거나 플레이어는 RAM(random access memory), 플래시 메모리 또는 SSD(solid state drive)와 같은 메모리로부터 파일을 검색할 수 있다. 일 실시예에서, 플레이어는 선험적 정보를 가지거나 또는 파일 내의 표시로부터 및/또는 파일의 설명에서 파일이 재정렬 가능한 것으로 결정한다. 예를 들어, 플레이어는 미디어 프레젠테이션 설명에서 표현과 연관된 MIME 유형을 수신할 수 있으며, MIME 유형의 프로파일 파라미터로부터, 그것이 재정렬 가능한 파일 또는 세그먼트를 나타내는 브랜드를 포함할 경우, 파일 또는 세그먼트가 재정렬 가능하다고 결정할 수 있다. 플레이어는 파일-레벨 박스의 시퀀스의 정보를 파싱할 수 있다. 플레이어는 수신된 파일의 파일-레벨 박스를 파일-레벨 박스의 시퀀스의 정보에 표시된 순서로 파싱할 수 있다. 플레이어는 수신된 파일 내의 사용 가능한 박스를 파일-레벨 박스의 시퀀스 정보와 비교함으로써 수신된 파일의 누락된 박스를 식별할 수 있다. 플레이어는 예를 들어 사용자에게 통지하는 것 및/또는 예컨대 누락된 파일-레벨 박스와 연관된 URL 프래그먼트(들)를 사용하여 서버로부터 누락된 데이터를 요청하는 것에 의해 식별된 누락된 데이터를 처리할 수 있다.
실시예에 따르면, 짧은 대기시간 라이브 스트리밍은 다음과 같이 구현될 수 있다. 일 실시예에서, 스트리밍 클라이언트는, 예를 들어 표현의 설명으로부터, 세그먼트가 MediaDataBox 관련 오프셋을 사용한다고 결정할 수 있다. 예를 들어, 스트리밍 클라이언트는 미디어 프레젠테이션 설명 내에서 표현과 연관된 MIME 유형을 수신할 수 있으며, MIME 유형의 프로파일 파라미터로부터, 그것이 MediaDataBox 관련 오프셋의 사용을 나타내는 브랜드를 포함할 경우, 세그먼트가 MediaDataBox 관련 오프셋을 사용한다고 결정할 수 있다. 스트리밍 클라이언트는, 예를 들어 미디어 프레젠테이션 설명으로부터, MovieFragmentBox 또는 세그먼트 헤더와, 각각의 MediaDataBox 또는 세그먼트 페이로드를 수신하는 URL 프래그먼트를 결정할 수 있다. 스트리밍 클라이언트는 결정 시에 SegmentIndexBox와 같은 다른 파일-레벨 박스를 사용할 수도 있다. 스트리밍 클라이언트는, 예컨대 병렬 HTTP 접속을 사용하여, MovieFragmentBox 또는 세그먼트 헤더와 MediaDataBox 또는 세그먼트 페이로드의 URL 프래그먼트를 별도로 요청할 수 있다. 일 실시예에서, 스트리밍 클라이언트는, 예컨대 병렬 HTTP 접속을 사용하여 MovieFragmentBox와 MediaDataBox를 별도로 요청하기 위해, 세그먼트의 MovieFragmentBox를 표시하기 위한 box_id=moof 및 세그먼트의 MediaDataBox를 나타내는 box_id=mdat와 같은 특정 박스 또는 특정 박스들을 나타내는 URL 프래그먼트를 사용한다. 일 실시예에서, 스트리밍 클라이언트는 (예컨대, 병렬 HTTP 접속을 사용하여) 다른 실시예에서 설명된 바와 같이 seghdr과 같은 특정 URL 프래그먼트를 사용하여 세그먼트 헤더를 개별적으로 요청하고, 다른 실시예에서 설명된 바와 같이 segpayload와 같은 다른 특정 URL 프래그먼트를 사용하여 세그먼트 데이터를 개별적으로 요청할 수 있다. 일 실시예에서, 스트리밍 클라이언트는 다른 실시예에서 설명된 바와 같이 seghdr과 같은 특정 URL 프래그먼트를 사용하여 세그먼트 헤더를 요청할 수 있다. 스트리밍 클라이언트는, 예컨대 표현의 설명으로부터, 세그먼트에 대한 MediaDataBox(들)의 URL 프래그먼트를 결정할 수 있다. 스트리밍 클라이언트는 결정된 URL 프래그먼트를 사용하여 세그먼트의 미디어 데이터를 (예를 들어, 병렬 HTTP 접속을 사용하여) 개별적으로 요청할 수 있다.
일 실시예에서, 서버는 HTTP의 청크 배달(chunked delivery)에 의해 URL 프래그먼트 요청에 응답할 수 있다. 서버는 MovieFragmentBox 또는 세그먼트 헤더와 각각의 MediaDataBox(들) 또는 세그먼트 페이로드의 제 1 부분을, 동일한 MovieFragmentBox 또는 세그먼트 헤더(각각)와 동일한 MediaDataBox(들) 또는 세그먼트 페이로드(각각)의 제 2 부분을 전송하기 전에 전송할 수 있다. 제 1 부분은 라이브 에지까지의 데이터, 즉, 지금까지 사용할 수 있는 데이터를 포함할 수 있다. 제 1 부분은 예컨대 정수 개의 TrackFragmentBoxes와 MediaDataBox(들) 내의 대응하는 미디어 데이터로 제한될 수 있는데, 즉, 부분적 TrackFragmentBoxes를 전송하는 것이 방지된다. 따라서, 인코딩 및 파일 캡슐화와 관련된 고유 대기시간은 줄어들 수 있으며, 청크 HTTP 전달에서는 "청크" 지속시간 만큼 작아질 수 있다.
일 실시예에서, 미디어 캡슐화기는 서버에 접속된다. 미디어 캡슐화기는 적어도 하나의 코딩된 미디어 스트림을 컨테이너 파일 또는 세그먼트로 패킹할 수 있다. 미디어 캡슐화기는 MovieFragmentBox 및 각각의 MediaDataBox의 제 1 부분을, 동일한 MovieFragmentBox 및 동일한 MediaDataBox의 제 2 부분의 캡슐화를 완료하기 전에 전송되도록 서버에 제공한다.
이 사양의 앞부분에 MediaDataBox(들)를 태깅하는 몇 가지 방법이 존재할 수 있다고 언급되었다. 이하, 박스의 박스 헤더 바로 다음에 부호 없는 정수 식별자 값을 첨가하는 예가 보다 상세하게 설명될 것이다.
일 실시예에 따른 MediaDataBox의 설명, 신택스 및 시맨틱 스는 일 실시예에 따라 다음과 같다.
박스 유형: 'mdat'
컨테이너: 파일
필수: 아니요
수량: 0 이상
신택스
실시예에 따르면, MediaDataBox의 시맨틱스(semantics)는 다음과 같다. 유형 표시(박스 유형)는 박스가 MediaDataBox임을 나타낸다. 파라미터 mdat_identifier는, 파일의 다른 MediaDataBox의 mdat_identifier 값과 상이하며 따라서 이 mdat 박스의 식별을 허용하는 32 비트 부호 없는 정수이다. 파라미터 data는 포함된 미디어 데이터이다.
이러한 종류의 콘텐츠를 사용하면, 파일이나 참조된 파일에 캡슐화된 임의의 MediaDataBox가 mdat_identifier에 의해 고유하게 식별될 수 있다.
실시예에 따르면, 참조된 MediaDataBox는, 트랙에 대한 DataReferenceBox에 포함되고 따라서 데이터 참조 인덱스 값과 연관되는 박스에서 식별된다. 데이터 참조 인덱스 값이 트랙의 샘플 엔트리에 의해 참조될 때, 샘플 위치를 나타내는 것과 관련된 오프셋(들)은 데이터 참조 인덱스 값으로 참조된 박스에서 식별된 MediaDataBox에 관련된다.
실시예에 따르면, 참조된 MediaDataBox는, MetaBox에 대한 DataReferenceBox에 포함되고 따라서 데이터 참조 인덱스 값과 연관되는 박스에서 식별된다. 데이터 참조 인덱스 값이 예컨대 ItemLocationBox에서 아이템 위치를 나타내기 위해 참조될 때, 아이템 위치를 나타내는 것과 관련된 오프셋(들)은 데이터 참조 인덱스 값으로 참조된 박스에서 식별된 MediaDataBox에 관련된다.
DataReferenceBox에 포함된 박스 내의 MediaDataBox를 식별하는 것에 관한 실시예가 다음과 같이 설명된다.
일 실시예에서, DataReferenceBox에 포함될 수 있는, 예컨대 이름 DataEntryldentifiedMdatBox 및 4 문자 코드 'imdt'를 갖는 새로운 박스 유형이 특정된다. DataEntryldentifiedMdatBox는 참조된 MediaDataBox의 식별자, 예컨대 32 비트 mdat_identifier 필드를 포함하도록 특정된다. 파일 생성자가 특정 MediaDataBox와 관련된 오프셋(offset)을 가진 파일을 작성할 때, 파일 생성자는 DataReferenceBox 내에 그 MediaDataBox의 식별자를 갖는 DataEntryldentifiedMdatBox를 포함시킨다. 그 다음에, 파일 생성자는 DataEntryldentifiedMdatBox의 데이터 참조 인덱스가 오프셋(들)과 연관되도록 파일을 작성한다.
일 실시예에서, URL 또는 URN 스킴은 포함 파일(containing file) 내의 MediaDataBox를 식별하도록 특정된다. 일 실시예에서, 다른 실시예에서 설명된 URL 프래그먼트 스킴(또는 동일하게 URN 프래그먼트 스킴)은 포함 파일을 나타내는 URL 또는 URN과 함께 사용된다. 프래그먼트 부분을 갖는 URL 또는 URN은 (파일 생성자에 의해) DataReferenceUrlBox 또는 DataReferenceUrnBox에 포함된다.
일 실시예에서, 포함 파일을 식별하는 URL 또는 URN은 스킴 부분에 "file:"을 포함하고 계층 부분은 비어 있다. 비어 있는 계층 부분은 URI에 관련되는 관련 URL 또는 URN을 나타내는 것으로 간주될 수 있는데, 이는 이 경우(URL 또는 URN이 파일에 포함될 때) 포함 파일 자체를 나타내도록 해석될 수 있고 결과적으로 비어 있는 계층 부분은 포함 파일을 나타내는 것으로 해석될 수 있다. 다른 실시예에 따라 프래그먼트 부분은 MediaDataBox를 식별하기 위해 사용될 수 있다. 예를 들어, 프래그먼트 부분은 #box_id=mdat/mdat_identifier일 수 있고, 여기서 mdat_identifier는 MediaDataBox의 식별자 값이다. 전반적으로, DataReferenceUrlBox 또는 DataReferenceUriBox에 포함될 URL 또는 URN 신택스의 예는 따라서 "file:#box_id= mdat/mdat_identifier"이다.
일 실시예에서, 포함 파일을 식별하는 URL 또는 URN은 비어 있는 스킴 부분 및 비어 있는 계층 부분을 갖는다. 예컨대 포함 박스(DataReferenceUrlBox 또는 DataReferenceUmBox)의 플래그 필드의 최하위 비트에 의해 포함 파일 자체가 참조되는 것이 표시될 수 있거나, 포함된 URL 또는 URN로부터 예컨대 프래그먼트 부분을 나타내는 해시('#')로 시작하는 것에 기초하여 URL 또는 URN이 포함 파일 자체를 참조하는 것으로 결정될 수 있다.
파일 생성자가 특정 MediaDataBox에 관련된 오프셋을 가진 파일을 작성할 때, 파일 생성자는 포함 파일 자체를 나타내는 URL 및 DataReferenceBox의 MediaDataBox를 나타내는 URL 프래그먼트를 갖는 DataReferenceUrlBox를 DataReferenceBox에 포함시킨다. 다음에, 파일 생성자는 DataReferenceUrlBox의 데이터 참조 인덱스가 오프셋(들)과 연관되도록 파일을 작성한다.
일 실시예에서, DataReferenceBox 내의 포함된 박스의 박스 헤더의 플래그 내의 새로운 비트(예를 들어, 두 번째 최하위 비트)는 오프셋(들)이 특정 식별자의 MediaDataBox에 관련되는 경우 오프셋(들)을 나타내기 위해 다음과 같이 사용된다. 플래그 필드의 최하위 비트가 1이고 플래그 필드의 새로운 비트가 0인 경우, 오프셋(들)은 통상적인 참조 포인트, 일반적으로 포함 파일의 시작 부분을 갖는다. 플래그 필드의 최하위 비트가 1이고 플래그 필드의 새로운 비트가 1인 경우, 박스는 참조된 MediaDataBox의 식별을 포함하며, 오프셋(들)은 참조된 MediaDataBox에 관련된다. 일 실시예에서, DataReferenceUrlBox에서 플래그 필드의 최하위 비트가 1이고 플래그 필드의 새로운 비트가 1인 경우, 박스에 포함된 URL은 다른 실시예에 따라 MediaDataBox를 식별하는 URL 프래그먼트를 포함한다. 예를 들어, 프래그먼트 부분은 #box_id=mdat/mdat_identifier일 수 있고, 여기서 mdat_identifier는 MediaDataBox의 식별자 값이다. 예를 들어, 박스에 포함된 URL은 "#box_id=mdat/3456"일 수 있는데, 이는 식별자가 3456인 MediaDataBox를 지칭한다. 다른 실시예에서, DataReferenceUrlBox에서 플래그 필드의 최하위 비트가 1이고 플래그 필드의 새로운 비트가 1인 경우, 박스에 포함된 URL은 MediaDataBox의 식별자를 포함한다(즉, URL 프래그먼트 신택스를 따를 필요는 없음).
일 실시예에서, DataReferenceBox 내에 포함된 박스의 박스 헤더의 새로운 버전 값(예컨대, 2)은 오프셋이 특정 식별자의 MediaDataBox에 관련됨을 나타내기 위해 다음과 같이 사용된다. 플래그 필드의 최하위 비트가 1이고 버전 필드가 새로운 값을 갖는 경우, 박스는 참조된 MediaDataBox의 식별을 포함하며 오프셋(들)은 참조된 MediaDataBox에 관련된다. 일 실시예에서, DataReferenceUrlBox에서 플래그 필드의 최하위 비트가 1이고 버전 필드가 새로운 값(예컨대, 2)인 경우, 박스에 포함된 URL은 비어 있거나 URL 프래그먼트를 포함한다. URL이 비어 있는 경우, 포함 파일 전체가 표시되고, 오프셋(들)은 통상적인 참조 포인트, 일반적으로 포함 파일의 시작 부분을 갖는다. URL이 URL 프래그먼트를 포함할 경우, 다른 실시예에 따라, URL은 MediaDataBox를 식별한다. 예를 들어, 프래그먼트 부분은 #box_id=mdat/mdat_identifier일 수 있고, 여기서 mdat_identifier는 MediaDataBox의 식별자 값이다. 예를 들어, 박스에 포함된 URL은 "#box_id=mdat/3456"일 수 있는데, 이는 식별자가 3456인 MediaDataBox를 지칭한다. 다른 실시예에서, DataReferenceUrlBox에서 플래그 필드의 최하위 비트가 1이고 버전 필드가 새로운 값(예컨대, 2)인 경우, 박스에 포함된 URL은 MediaDataBox의 식별자를 포함한다(즉, URL 프래그먼트 신택스를 따를 필요는 없음).
일 실시예에서, DataReferenceBox에 포함된 박스에서 MediaDataBox가 식별되는 파일을 파싱하는 파일 파서는 다음과 같이 동작한다. 파일 파서는, (예를 들어, 샘플 또는 아이템 각각에 대해) 미디어 데이터의 위치를 나타내기 위해 사용된 오프셋(들)과 어떤 데이터 참조 인덱스가 연관되는지를 파일로부터(예컨대, 샘플 엔트리 또는 ItemLocationBox로부터) 결정한다. 데이터 참조 인덱스에 기초하여, 파일 파서는 DataReferenceBox로부터 (예컨대, 상이한 실시예에서 유형 DataEntryIdentifiedMdatBox 또는 DataEntryUrlBox의) 올바른 포함된 박스를 찾는다. 파일 파서는 올바른 포함된 박스에 포함된 MediaDataBox의 식별자를 파싱한다. 파일 파서는 식별자와 연결된 MediaDataBox를 찾는다. 파일 파서는 기본적으로 오프셋(들)을 MediaDataBox의 페이로드의 시작부에 추가함으로써 오프셋(들)에 의해 참조된 데이터를 찾는다. 예를 들어, box_id=mdat/<id_value>의 프래그먼트를 갖는 URL을 갖는 데이터 참조가 청크에 사용되는 경우, ChunkOffsetBox 내의 chunk_offset 값은 id_value와 동일한 mdat_identifier를 갖는 MediaDataBox의 시작 부분에 관련된다.
DataReferenceBox에서 전술된 수정을 사용하지 않는 실시예에 따르면, MediaDataBox(들)에 관련된 청크 오프셋은 다음과 같이 표시될 수 있다. ISOBMFF에서 청크 오프셋은 MovieBox에 설명된 일련의 연속 샘플 중 (파일 내의) 시작 위치를 나타내기 위해 사용된다. 일 실시예에서, ChunkOffsetBox 내의 청크에 대한 오프셋 계산은, 파일의 시작부로부터 계산되는 오프셋 대신에, 청크를 포함하는 MediaDataBox의 시작 부분으로부터 오프셋이 계산되도록 정의될 수 있다. 이를 가능하게 하기 위해, 일 실시예에 따르면, ChunkOffsetBox의 신택스 및 시맨틱스는 아래에 예시된 바와 같을 수 있다.
신택스
일 실시예에 따르면 ChunkOffsetBox의 시맨틱스는 다음과 같다. 파라미터 version은 이 박스의 버전을 특정하는 정수이며, entry_count는 다음 테이블의 엔트리의 수를 제공하는 정수이고, mdat_identifier는 이 파일 또는 dref 박스에 의해 표시된 다른 파일에 포함된 mdat 박스를 식별하는 32 비트 정수이며, chunk_offset은 청크 시작의 오프셋을 그것의 포함 미디어 파일에 제공하는 32 또는 64 비트 정수이다.
이하에서는 ISOBMFF 파일에서 프래그먼트화(fragmentation)가 사용될 때 MediaDataBox(들)에 관련된 트랙 런 오프셋(track run offsets)을 어떻게 표시할 것인지의 예가 제공된다. 먼저 박스의 몇 가지 예가 설명된다.
TrackFragmentBox는 일 실시예에 따라 다음과 같이 설명될 수 있다.
박스 유형: 'traf'
컨테이너: 무비 프래그먼트 박스('moof')
필수: 아니요
수량: 0 이상
무비 프래그먼트에는 트랙 당 0개 이상의 트랙 프래그먼트의 세트가 존재할 수 있다. 트랙 프래그먼트는 0개 이상의 트랙 런을 포함할 수 있는데, 이것은 해당 트랙에 대한 연속 샘플 런을 문서화할 수 있다.
일 실시예에 따르면, TrackFragmentBox의 신택스는 다음과 같을 수 있다.
TrackFragmentHeaderBox는 일 실시예에 따라 다음과 같이 설명될 수 있다.
박스 유형: 'tfhd'
컨테이너: 트랙 프래그먼트 박스('traf')
필수: 예
수량: 정확히 하나
각 무비 프래그먼트는 각 트랙에 0개 이상의 프래그먼트를 추가할 수 있고, 트랙 프래그먼트는 0 이상의 연속 샘플 런을 추가할 수 있다. 트랙 프래그먼트 헤더는 이러한 샘플 런에 사용되는 정보 및 디폴트를 설정할 수 있다.
일 실시예에 따르면, TrackFragmentHeaderBox의 신택스는 다음과 같을 수 있다.
일 실시예에 따르면, 세 번째 최하위 비트(예컨대, 비트식 논리 연산(tf_flag & 4)의 결과가 0이 아님)와 같은 tf_flags 내의 비트는, 오프셋을 계산하기 위한 앵커가 mdat_identifier를 사용하는 것에 기초한다는 것을 파서에 알리기 위해 사용될 수 있다. 예를 들어, tf_flags & 0x000004가 0x000004와 같을 때, 이것은 base_data_offset-present가 존재하지 않거나 존재할 경우 무시해야함을 시그널링하고, 디폴트 기본 오프셋은 default_base_is_moof 플래그가 시그널링될 경우에도 moof 박스의 시작부가 아니다.
TrackRunBox의 경우, 오프셋이 mdat_identifiers를 사용하여 계산됨을 나타내는 tr_flags 내의 비트가 정의된다. 일 실시예에 따르면, TrackRunBox의 신택스는 다음과 같을 수 있다.
신택스
일 실시예에 따르면, TrackRunBox의 시맨틱스는 다음과 같다. 파라미터 sample_count는 이 런에 추가되는 샘플 수와 다음 테이블의 행의 수(행은 비어있을 수 있음)를 나타내며, data_offset은 트랙 프래그먼트 헤더에 설정된 data_offset을 암시하거나 명시하기 위해 추가되고, first_sample_flags는 이 런의 첫 번째 샘플에만 플래그 세트를 제공하며, mdat_identifier는 이 파일 또는 dref 박스에 의해 표시된 다른 파일에 포함된 mdat 박스를 식별하는 32 비트 정수이다.
일 실시예에 따르면, TrackFragmentHeaderBox의 신택스는 다음과 같을 수 있다.
일 실시예에 따르면, 세 번째 최하위 비트(예를 들어, 비트식 논리 연산(tf_flags & 4)의 결과가 0이 아님)와 같은 tf_flags 내의 비트는, 필드 mdat_identifier가 TrackFragmentHeaderBox에 존재하는 것과 이 TrackFragmentHeaderBox를 포함하는 TrackFragmentBox에 포함된 TrackRunBox(들) 내의 base_data_offset(존재할 경우) 및 data_offset과 같은 오프셋이 식별된 MediaDataBox의 데이터의 첫 번째 바이트에 관련되는 것을 나타내기 위해 사용될 수 있다. 예를 들어, tf_flags & 0x000004가 0x000004와 같을 때, 이것은 mdat_identifier가 존재하고 오프셋이 mdat_identifier와 동일한 식별자를 가진 MediaDataBox의 데이터 시작에 관련되는 것을 나타낸다. 이 실시예에서 TrackRunBox(들)은 mdat_identifier를 나타내지 않으므로, 이 트랙 프래그먼트의 모든 트랙 런은 동일한 MediaDataBox에 존재해야 할 수 있다.
이하에서는 일 실시예에 따라, 식별된 MediaDataBox와 관련된 아이템 위치가 어떻게 표시될 수 있는지가 설명될 것이다. MetaBox에서 동일한 종류의 MediaDataBox 기반 오프셋 계산 프로세스를 가능하게 하기 위해, ItemLocationBox에 새로운 구축 방법이 도입된다. 이 구축 방법은 예를 들어 4의 값을 가지며 그 시맨틱스는 아래에 설명된다.
ItemLocationBox는 일 실시예에 따라 다음과 같이 설명될 수 있다.
박스 유형: 'iloc'
컨테이너: 메타 박스('meta')
필수: 아니요
수량: 0 또는 1
아이템 위치 박스는 컨테이너의 위치, 해당 컨테이너 내의 오프셋 및 길이를 결정함으로써 이 파일 또는 다른 파일에 리소스 디렉토리를 제공할 수 있다. 박스는 오프셋 필드, 길이 필드, base_offset 필드 및 extent_index 필드의 크기를 각각 바이트 단위로 특정하는 3개 또는 4개의 값으로 시작할 수 있다. 이 값은 집합 {0, 4, 8}로부터 선택될 수 있다. construction_method 필드는 다음과 같이 아이템에 대한 '구축 방법'을 나타낼 수 있다.
i) file_offset: data_reference_index에 대한 일반적인 절대적 파일 오프셋에 의함 (construction_method == 0)
ii) idat_offset: 동일한 메타 박스 내의 idat 박스에 대한 박스 오프셋에 의하고, data_reference_index 및 extent_index 필드가 사용되지 않음 (construction_method == 1)
iii) item_offset: 이 구축 방법에 의해서만 (현재) 사용되는 extent_index 필드에 의해 표시된 아이템에 대한 아이템 오프셋에 의함 (construction_method == 2)
iv) mdat_offset: 동일한 또는 참조된 파일에 포함된 MediaDataBox에 대한 박스 오프셋에 의함 (construction_method == 4)
일 실시예에 따르면 ItemLocationBox의 신택스는 다음과 같을 수 있다.
그런 다음, ItemLocationBox 내의 필드 extent_index는 아이템이 존재하는 MediaDataBox의 고유 mdat_identifier 값을 보유할 수 있고, extent_offset은 아이템을 시작하는 MediaDataBox의 시작부로부터의 바이트 오프셋을 제공하기 위해 사용될 수 있다.
이하에서는, 일 실시예에 따라, URL 프래그먼트 생성의 예시적인 구현이 설명될 것이다. URL 프래그먼트 내의 박스의 어드레싱을 용이하게 하기 위해, ISOBMFF의 URL 프래그먼트 스킴에 대한 다음과 같은 추가가 구현될 수 있다. #box_id=<4cc string>은 'ftyp'과 같은 4cc(4 자리 코드) 스트링으로 식별되는 고유 박스를 지칭한다. 키워드 box_id 대신에 다른 사전 정의된 키워드가 동등하게 사용될 수 있음에 유의해야 한다. #box_id=<4cc string>/<id>는 4cc 스트링으로 식별되고 파일 내에 동일한 4cc 스트링을 갖는 박스 중 고유 식별자 값이 id인 박스를 지칭하며, 예컨대, #box_id=moof/3는 고유 식별자 값이 3인 moof 박스를 식별한다. 슬래시 문자 '/' 대신 다른 분리 기호(separator)가 동등하게 사용될 수 있음에 유의해야 한다. id 값은 4 문자 코드마다 특정될 수 있다. 'moof'의 경우, id 값은 'moof' 박스에 포함된 MovieFragmentHeaderBox의 sequence_number 필드를 지칭할 수 있다. ProducerReferenceTimeBox('prft')의 경우, id 값은 'prft'박스와 연관된 'moof' 박스에 포함된 MovieFragmentHeaderBox의 sequence_number 필드를 지칭할 수 있다. 'mdat'의 경우, id 값은 위의 실시예에서 특정된 mdat_identifier를 지칭하거나 위의 몇몇 실시예에서 설명된 바와 같이 MediaDataBox에 대한 임의의 다른 식별자를 지칭할 수 있다. 'styp', 'sidx' 및 'ssix'와 같은 세그먼트 관련 박스의 경우, id 값은, 예컨대 슬래시 문자와 같은 분리 기호 문자로 분리된, 연관된 SegmentIndexBox('sidx')의 reference_ID 필드와 earliest_presentation_time 필드의 조합일 수 있다.
하나의 요청으로 몇 개의 박스와 같은 몇 개의 리소스를 요청하기 위해, 일 실시예에 따라, URL 프래그먼트의 번들이 특정될 수 있다. 예를 들어, URL 프래그먼트 아이템들 사이에 쉼표와 같은 특정된 구분자(delimiter)를 포함함으로써 두 개 이상의 URL 프래그먼트 아이템은 URL의 프래그먼트 부분에 포함될 수 있다. 예컨대, #box_id=ftyp,box_id=meta,box_id=mdat/398. 또 다른 예시적 신택스에서, box_id와 같은 키워드는 반복될 필요가 없다. 예컨대, #box_id=ftyp,meta,mdat/398. 쉼표 문자(',') 대신 다른 분리 기호가 동등하게 사용될 수 있음에 유의해야 한다.
일 실시예에서, 세그먼트의 MediaDataBox를 제외하고 (MPEG-DASH와 같은 동적 적응형 스트리밍 환경에서 이해되는 바와 같이) 세그먼트의 모든 박스를 나타내기 위해 URL 프래그먼트 스킴이 정의된다. MediaDataBox(들)가 아닌 세그먼트의 박스는 예를 들어 'styp'(세그먼트 유형 박스), SegmentIndexBox(들)('sidx'), SubsegmentIndexBox(들)('ssix'), MovieFragmentBox(들)('moof') 및/또는 ProducerReferenceTimeBox(들)('prft')를 포함할 수 있다. 예를 들어, 키워드 seghdr이 사용될 수도 있지만, 키워드 seghdr 대신 다른 사전 정의된 키워드가 동등하게 사용될 수 있음에 유의해야 한다. URL 프래그먼트가 #seghdr인 것은 URL(URL 프래그먼트를 포함함)의 스킴 이름과 계층 부분에 의해 식별된 세그먼트의 세그먼트 관련 박스로 해석된다.
일 실시예에서, URL 프래그먼트 스킴은 미디어 데이터를 운반하는 세그먼트의 모든 박스를 나타내기 위해 정의된다. 예를 들어, 키워드 segpayload가 사용될 수도 있지만, 키워드 segpayload 대신 다른 사전 정의된 키워드가 동등하게 사용될 수 있음에 유의해야 한다. URL 프래그먼트가 #segpayload인 것은 URL(URL 프래그먼트를 포함함)의 스킴 이름과 계층 부분에 의해 식별된 세그먼트의 미디어 데이터를 전달하는 박스로 해석된다.
일 실시예에 따르면, 서버는 URL 요청에 대한 응답으로서 제공되는 리소스 또는 파일 내에 식별된 박스만을 포함시킴으로써 전술된 박스를 식별하는 URL 프래그먼트에 의해 URL을 해석한다. 예를 들어, #box_id=<four_character_string>은 박스 유형이 four_character_string인 파일-레벨 박스로 해석된다. 다수의 파일-레벨 박스의 표시에 의해 URL 프래그먼트를 해석하면 URL 프래그먼트에 나열되는 순서로 표시된 파일-레벨 박스로 구성되는 리소스가 생성되도록 특정할 수 있다. 대안으로, 다수의 파일-레벨 박스의 표시에 의해 URL 프래그먼트를 해석하면 임의의 순서로 표시된 파일-레벨 박스로 구성되는 리소스가 생성되도록 특정할 수 있다.
일 실시예에서, 플레이어 또는 이와 유사한 것은 (예를 들어, 무비 박스를 어드레싱하는 프래그먼트를 포함하는 URL에 의한 HTTP GET 요청을 통해) MovieBox를 획득한다. 플레이어 또는 이와 유사한 것은 MovieBox를 파싱하고, DataReferenceBox로부터의 외부 데이터 참조 및 MovieBox를 포함하는 파일 내부의 MediaDataBox(들)를 가리키는 내부 데이터 참조를 해석한다. 플레이어는 예컨대 파일이 이미지 아이템을 포함하는 것이 알려지거나 해석될 경우에 파일-레벨 MetaBox를 획득할 수 있다. 플레이어 또는 이와 유사한 것은 이런 목적을 위해 어떤 미디어 데이터가 필요한지를 판정한다. 예를 들어, 플레이어 또는 이와 유사한 것은 파일 레벨 MetaBox로부터 어떤 이미지 아이템(들)이 이런 목적에 적합한지를 판정할 수 있다. 다른 예에서, 플레이어 또는 이와 유사한 것은 MovieBox로부터 어떤 트랙이 이런 목적에 적합한지를 판정할 수 있다. 그런 다음, 플레이어 또는 이와 유사한 것은 이런 목적에 필요한 미디어 데이터에 대해 어떤 외부 데이터 참조 및/또는 MediaDataBox(들)이 필요한지를 판정한다. 일 실시예에서, 콘텐츠 캡슐화기 또는 이와 유사한 것은 미디어 데이터와 연관된 URL 프래그먼트를 DataReferenceBox에 포함시키거나 그와 연관시킨다. 일 실시예에서, 플레이어 또는 이와 유사한 것은, DataReferenceBox 또는 연관된 박스로부터 미디어 데이터와 연관된 URL 프래그먼트를 파싱하고, URL 프래그먼트과 함께 DataReferenceBox로부터 획득된 URL 또는 파일 이름을 사용한다. 일 실시예에서, 플레이어 또는 이와 유사한 것은 프래그먼트 부분 없이 (DataReferenceBox로부터 파싱된) URL을 사용하여 외부 참조를 페치한다.
이하에서는, 일 실시예에 따라, 선택적 이미지 페치를 위한 이미지 컨테이너 파일을 갖는 URL 프래그먼트의 사용이 보다 상세히 설명될 것이다.
HTML5.1은 웹 브라우저가 예컨대 코딩 포맷 및/또는 디스플레이 윈도우의 폭에 기초하여 적절한 이미지를 선택할 수 있도록 이미지의 다른 버전이나 대안을 나타내는 기능을 제공한다. 보다 구체적으로, 픽처 요소는 동일한 이미지의 여러 버전을 묶을 수 있는데, 이 중 브라우저는 시청 영역의 해상도 및 지원되는 코덱과 같이 필요에 가장 적합한 버전을 선택할 수 있다. 일 실시예에 따르면, HTML 페이지 작성과 같은 콘텐츠 작성은, 동일한 컨테이너 파일의 이미지 아이템 또는 이미지 아이템의 번들이 페치에 이용 가능하도록 URL 프래그먼트를 사용하여 공표(announce)되는 방식으로 수행된다. 예를 들어, HTML5.1(또는 더 이후)의 픽처 요소가 사용될 수 있다. 픽처 요소를 갖는 HTML5.1 코드의 일부의 예에서 사용 가능한 동일한 파일의 서로 다른 아이템은 다음과 같이 제공된다. 이 예에서, ID가398인 MediaDataBox('mdat')는 작은 디스플레이 윈도우 폭(1024 픽셀 이하)에 대한 이미지를 포함하고, ID가 399인 MediaDataBox는 더 큰 윈도우 폭에 대한 이미지를 포함한다.
일 실시예에서, 브라우저 또는 이와 유사한 것은, 위의 코드의 미디어 쿼리 부분과 같은 이미지의 설명에 기초하여 픽처 요소로부터 이미지를 선택한다. 이미지 URL은 HEIF 포맷을 준수하는 데 필요한 박스를 나열하는 것과 같이 전술된 프래그먼트 부분을 포함할 수 있다.
이하에서는, 일 실시예에 따라, 콘텐츠 테이블 박스의 형태의 파일-레벨 박스들의 시퀀스에 관한 정보의 예시적 구현이 보다 상세히 설명될 것이다.
파일의 루트 레벨에서 박스의 고유 식별을 가능하게 하기 위해, 아래에 제안된 박스를 포함하는 각 박스는 4 문자 코드 'rbsq'를 갖는 새로 특정된 박스에 나열될 수 있다. 'rbsq' 내의 박스 리스트는 파일에 저장된 순서와 정확히 일치해야 한다. (예컨대 루트 레벨 박스의 제거 또는 추가에 의해) 파일을 편집할 때, 이 박스는 편집된 파일의 새로운 레이아웃을 고려하여 역시 수정되어야 한다.
설명
박스 유형: 'rbsq'
컨테이너: File
필수: 재정렬 가능한 것으로 브랜딩된 파일의 경우 예
수량: 단 하나
신택스
일 실시예에 따르면, RootBoxSequence의 시맨틱스는 다음과 같다. box_4cc는 파일의 루트 레벨에 배치된 박스의 4 자리 코드 값이고, ext_flags는 박스에 어떤 추가 정보가 제공되는지를 나타내며, box_id는 4 문자 코드 값 box_4cc를 갖는 박스에 (포함 파일 내의) 고유 ID를 제공하는 32 비트 부호 없는 정수이다.
이하, 도 3a 및 도 3b의 장치 및 도 4a 및 도 4b의 흐름도를 참조하여 몇몇 예시적인 실시예를 보다 상세하게 설명한다. 예시적 실시예에 따르면, 장치(700)는 미디어 데이터(720)를 수신하거나 획득하여 미디어 데이터로부터 하나 이상의 컨테이너 파일을 생성한다(도 4a의 블록 750). 미디어 데이터는 하나 이상의 미디어 데이터 유닛을 포함할 수 있다. 각각의 미디어 데이터 유닛은 비디오, 오디오, 이미지 또는 다른 미디어 데이터(예컨대, 텍스트)와 관련될 수 있다. 장치(700)는 컨테이너 파일(722)을 획득 및/또는 생성하기 위한 파일 합성기(702) 또는 다른 수단을 가질 수 있다. 파일 합성기(702)는 컨테이너 파일(722)에 하나 이상의 미디어 데이터 유닛을 포함시킬 수 있거나, 파일 합성기(702)는 컨테이너 파일(722) 내에 하나 이상의 미디어 데이터 유닛에 대한 참조를 포함시킬 수 있다. 참조는 예를 들어 하나 이상의 미디어 데이터 유닛을 포함하는 파일 또는 리소스를 식별하는 URN(Uniform Resource Name) 또는 URL(Uniform Resource Locator)을 포함할 수 있다. 상기 파일 또는 리소스는 컨테이너 파일(722)과 동일하거나 상이한 저장 시스템, 대용량 메모리 및/또는 장치에 존재할 수 있다.
장치(700)의 파일 합성기(702) 또는 몇몇 다른 수단은 또한 MediaDataBox의 시작 부분으로부터의 오프셋을 사용할지(754) 데이터 원점 포인터로부터의 오프셋을 사용할지(755)를 여부를 검사할 수 있고(752), 오프셋의 계산 원리에 관한 표시(758)를 포함시킬 수 있으며, 오프셋이 MediaDataBox에 관련하여 계산되면 ChunkOffsetBox 또는 오프셋에 관한 다른 엔티티를 포함하는 파일에 오프셋 정보가 또한 포함될 수 있다(756). 또한, 오프셋이 MediaDataBox에 관련하여 계산되는 경우, MediaDataBox의 식별자를 포함하도록 TrackRunBoxes가 구축될 수 있다.
전술된 데이터 원점 포인터는, 예를 들어, 파일의 시작 부분, MovieFragmentBox의 시작 부분, 아이템 데이터 박스 내의 데이터 시작 부분 또는 참조된 아이템 데이터의 시작 부분일 수 있다.
컨테이너 파일(722) 및 다른 정보는 메모리(706) 및/또는 몇몇 다른 저장 위치에 저장될 수 있고/있거나, 컨테이너 파일(722)은 저장, 분해 및 재생을 위해 다른 디바이스로 전송될 수 있다.
일 실시예에 따르면, 파일 판독기(710)(도 3b) 또는 플레이어는 컨테이너 파일(722)로부터 미디어 데이터를 분해하기 위해 다음과 같은 동작을 수행할 수 있다. 파일 판독기(710)는 파일 분해기(712)를 포함할 수 있으며, 파일 분해기(712)는 수신된 파일에 관한 오프셋이 MediaDataBox에 관련하여 계산된 것인지 여부를 확인할 수 있다(772, 774). 만일 그렇다면, 파일 분해기(712)는 MediaDataBox의 식별에 관한 정보 및 오프셋 정보를 판독하여 미디어 데이터의 위치를 정확하게 계산(777)하고 파일에서 수신된 미디어를 재구성(778)할 수 있다. 오프셋이 MediaDataBox에 관련하여 계산되지 않고 파일의 시작 부분에 관련하여 계산되는 경우, 파일 분해기(712)는 파일의 시작 부분에 관련된 미디어 데이터의 위치를 계산(776)하고 파일에서 수신된 미디어를 재구성(778)할 수 있다.
장치(700, 710, 또는 이와 유사한 것)가 예컨대 URI 또는 URN을 사용하여 컨테이너 파일 이외의 파일 또는 리소스에 액세스하고 파일 및 리소스가 컨테이너 파일과 동일한 장치에 존재하지 않을 경우, 액세스는 예를 들어 유선, 무선(예컨대, WLAN) 및/또는 모바일(예컨대, GSM, 3G 및/또는 LTE/4G) 접속과 같은 네트워크 접속을 사용하여 수행될 수 있다.
도 5에는 하이퍼 텍스트 전송 프로토콜(HTTP) 스트리밍 시스템에 포함된 몇몇 기능 블록, 포맷 및 인터페이스의 예시가 도시된다. 파일 캡슐화기(100)는 미디어 프레젠테이션의 미디어 비트스트림을 입력으로서 취한다. 비트스트림은 이미 하나 이상의 컨테이너 파일(102)에 캡슐화될 수 있다. 비트스트림은 하나 이상의 미디어 인코더에 의해 생성되는 동안 파일 캡슐화기(100)에 의해 수신될 수 있다. 파일 캡슐화기는 미디어 비트스트림을 HTTP 스트리밍 서버와 같은 스트리밍 서버(110)에 의해 처리될 수 있는 하나 이상의 파일(104)로 변환한다. 파일 캡슐화기의 출력(106)은 서버 파일 포맷에 따라 포맷된다. HTTP 스트리밍 서버(110)는 HTTP 스트리밍 클라이언트와 같은 스트리밍 클라이언트(120)로부터 요청을 수신할 수 있다. 요청은 예컨대 GET 요청 메시지와 같은 하이퍼 텍스트 전송 프로토콜에 따라 메시지 또는 메시지들에 포함될 수 있다. 요청은 요청된 미디어 스트림을 나타내는 주소를 포함할 수 있다. 주소는 소위 URL(uniform resource locator)일 수 있다. HTTP 스트리밍 서버(110)는 요청된 미디어 파일(들) 및 메타데이터 파일과 같은 다른 정보를 HTTP 스트리밍 클라이언트(120)에 전송함으로써 요청에 응답할 수 있다. 몇몇 경우에, 그 다음에 HTTP 스트리밍 클라이언트(120)는 미디어 파일(들)을 HTTP 스트리밍 클라이언트 및/또는 미디어 플레이어(130)에 의한 재생에 적합한 파일 포맷으로 변환할 수 있다. 다른 경우에, 수신된 미디어 파일(들)은 변환 없는 재생에 적합하고, HTTP 스트리밍 클라이언트(120)는 (예컨대, 미디어 플레이어(130)에 의한) 재생을 위해 미디어 파일(들)을 제공할 수 있다. 재생을 위해 제공된 미디어 데이터 파일(들)은 또한 메모리(140) 및/또는 다른 종류의 저장 매체에 저장될 수 있다. HTTP 스트리밍 클라이언트 및/또는 미디어 플레이어는, HTTP 응답에 포함된 비트스트림을 렌더링될 수 있는 포맷으로 디코딩할 수 있는 하나 이상의 미디어 디코더를 포함하거나 선택적으로는 그에 동작 가능하게 접속될 수 있다.
HTTP 스트리밍 서버
HTTP 스트리밍 서버(110)는 미디어 프레젠테이션의 하나 이상의 파일을 입력으로서 취한다. 입력 파일은 서버 파일 포맷에 따라 포맷된다. HTTP 스트리밍 서버(110)는 HTTP 응답 내에 미디어를 캡슐화함으로써 HTTP 스트리밍 클라이언트(120)로부터의 HTTP 요청(112)에 응답한다(114). HTTP 스트리밍 서버는, 전송 파일 포맷에 따라 포맷되고 HTTP 응답 내에 캡슐화된 미디어 프레젠테이션의 한 파일 또는 많은 파일을 출력하여 전송한다.
일 실시예에 따르면, HTTP 스트리밍 서버(110)는 크게 3개의 클래스로 분류될 수 있다. 제 1 클래스는 "고정" 모드에서 HTTP 서버로서 또한 알려져 있는 웹 서버이다. 이 모드에서, HTTP 스트리밍 클라이언트(120)는 서버 파일 포맷에 따라 포맷될 수 있는 프레젠테이션의 파일 중 하나 이상을 전체적으로 또는 부분적으로 전송되도록 요청할 수 있다. 서버는 임의의 수단에 의해 콘텐츠를 준비할 필요가 없다. 대신 콘텐츠 준비는 별도의 엔티티에 의해 미리, 어쩌면 오프라인으로 수행된다. 도 6a는 HTTP 스트리밍 서버로서 웹 서버의 예를 도시한다. 콘텐츠 제공자(300)는 콘텐츠 준비(310)를 위해 콘텐츠를 제공할 수 있고 콘텐츠의 공표를 위해 서비스/콘텐츠 공표 서비스(320)에 콘텐츠를 제공할 수 있다. HTTP 스트리밍 클라이언트(120)를 포함할 수 있는 사용자 디바이스(330)는 서비스/콘텐츠 공표 서비스(320)로부터의 공표에 관한 정보를 수신할 수 있는데, 사용자 디바이스(330)의 사용자는 수신할 콘텐츠를 선택할 수 있다. 서비스/콘텐츠 공표 서비스(320)는 웹 인터페이스를 제공할 수 있고, 결과적으로 사용자 디바이스(330)는 사용자 디바이스(330)의 웹 브라우저를 통해 수신할 콘텐츠를 선택할 수 있다. 대안으로 또는 부가적으로, 서비스/콘텐츠 공표 서비스(320)는 텔레비전 방송 시스템의 SAP(Service Advertising Protocol), RSS(Really Simple Syndication) 프로토콜, 또는 ESG(Electronic Service Guide) 메커니즘과 같은 다른 수단 및 프로토콜을 사용할 수 있다. 사용자 디바이스(330)는, 서비스/콘텐츠에 관한 정보를 수신하고 예컨대 정보를 사용자 디바이스의 디스플레이에 제공하는 서비스/콘텐츠 발견 요소(332)를 포함할 수 있다. 다음에, 스트리밍 클라이언트(120)는 웹 서버(340)와 통신하여 사용자가 다운로드를 위해 선택한 콘텐츠를 웹 서버(340)에 알린다. 웹 서버(340)는 콘텐츠 준비 서비스(310)로부터 콘텐츠를 페치하여 HTTP 스트리밍 클라이언트(120)로 제공할 수 있다.
제 2 클래스는 도 6b에 도시된 바와 같이 동적 스트리밍 서버와 동작 가능하게 접속된 (정규) 웹 서버이다. 동적 스트리밍 서버(410)는, 클라이언트(420)로부터의 요청에 기초하여, 스트리밍된 콘텐츠를 클라이언트(420)에 맞게 동적으로 조정한다. HTTP 스트리밍 서버(430)는 클라이언트(420)로부터의 HTTP GET 요청을 해석하고 주어진 콘텐츠로부터 요청된 미디어 샘플을 식별한다. HTTP 스트리밍 서버(430)는 콘텐츠 파일(들) 내에서 또는 라이브 스트림으로부터 요청된 미디어 샘플의 위치를 찾아낸다. 그런 다음, 요청된 미디어 샘플을 추출하여 컨테이너(440)에 동봉한다. 이어서, 미디어 샘플을 갖는 새롭게 형성된 컨테이너는 HTTP GET 응답 몸체 내에서 클라이언트로 전달된다.
도 6a 및 도 6b의 제 1 인터페이스 "1"은 HTTP 프로토콜에 기초하며, HTTP 스트리밍 요청 및 응답의 신택스 및 시맨틱스를 정의한다. HTTP 스트리밍 요청/응답은 HTTP GET 요청/응답에 기초할 수 있다.
도 6b의 제 2 인터페이스 "2"는 콘텐츠 전달 설명에 대한 액세스를 가능하게 한다. 미디어 프레젠테이션 설명으로도 불릴 수 있는 콘텐츠 전달 설명은 콘텐츠 제공자(450) 또는 서비스 제공자에 의해 제공될 수 있다. 이것은 관련 콘텐츠에 액세스하는 수단에 대한 정보를 제공한다. 특히, 이것은 HTTP 스트리밍을 통해 콘텐츠에 액세스할 수 있는지 여부 및 어떻게 액세스를 수행하는지를 설명한다. 콘텐츠 전달 설명은 일반적으로 HTTP GET 요청/응답을 통해 검색되지만, SAP, RSS 또는 ESG를 사용하는 것과 같이 다른 수단으로도 전달될 수 있다.
도 6b의 제 3 인터페이스 "3"은 CGI(Common Gateway Interface)를 나타내는데, 이는 웹 서버와 동적 콘텐츠 생성 서버 간의 표준화되고 광범위하게 배치된 인터페이스이다. REST(Representational State Transfer) 인터페이스와 같은 다른 인터페이스가 가능하며, 이는 캐시 친화적 리소스 로케이터의 구축을 가능하게 한다.
CGI(Common Gateway Interface)는 웹 서버 소프트웨어가 웹 페이지의 생성을 콘솔 애플리케이션에 위임하는 방법을 정의한다. 이러한 애플리케이션은 CGI 스크립트로 알려져 있으며, 스크립팅 언어가 종종 사용되지만, 이들은 모든 프로그래밍 언어로 작성될 수 있다. 웹 서버의 한 가지 태스크는, 요청의 콘텐츠를 분석하고, 응답으로 전송할 적절한 문서를 결정하고, 클라이언트에게 문서를 제공함으로써, 클라이언트(일반적으로 웹 브라우저)가 발행한 웹 페이지에 대한 요청에 응답하는 것이다. 요청이 디스크 상의 파일을 식별하면, 서버는 파일의 콘텐츠를 반환할 수 있다. 대안으로, 문서의 콘텐츠는 즉시(on the fly) 구성될 수 있다. 이를 수행하는 한 가지 방법은 콘솔 애플리케이션으로 하여금 문서의 콘텐츠를 계산하도록 하고 웹 서버에 그 콘솔 애플리케이션을 사용하도록 알리는 것이다. CGI는 웹 서버와 콘솔 애플리케이션 사이에 어떤 정보가 어떻게 통신되지를 특정한다.
REST(Representational State Transfer)는 WWW(World Wide Web)와 같은 분산형 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 스타일이다. REST 스타일의 아키텍처는 클라이언트와 서버로 구성된다. 클라이언트는 서버에 대한 요청을 시작하고, 서버는 요청을 처리하여 적절한 응답을 반환한다. 요청과 응답은 "리소스"의 "표현"의 전송을 중심으로 구축된다. 근본적으로 리소스는 어드레싱될 수 있는 일관되고 의미있는 개념일 수 있다. 리소스의 표현은 리소스의 현재 또는 의도된 상태를 캡처하는 문서일 수 있다. 특정 시간에, 클라이언트는 애플리케이션 상태들 간에 전이(transition) 중이거나 휴면 상태일 수 있다. 휴면 상태에 있는 클라이언트는 사용자와 상호작용할 수는 있지만, 로드를 생성하지 않으며 서버 세트나 네트워크 상에서 클라이언트에 대한 스토리지를 사용하지 않는다. 클라이언트는 새로운 상태로 전이할 준비가 되면 요청을 전송하기 시작할 수 있다. 하나 이상의 요청이 미해결인 동안, 클라이언트는 상태를 전이 중인 것으로 간주된다. 각 애플리케이션 상태의 표현은 클라이언트가 새로운 상태 전이를 개시하기 위해 선택하는 다음에 사용될 수 있는 링크를 포함한다.
이 예시적 분류에 따르면, HTTP 스트리밍 서버의 제 3 클래스는 동적 HTTP 스트리밍 서버이다. 다른 것은 제 2 클래스와 유사하지만, HTTP 서버와 동적 스트리밍 서버는 단일 컴포넌트를 형성한다. 또한, 동적 HTTP 스트리밍 서버는 상태를 유지할 수 있다.
서버 측 솔루션은 정적 HTTP 스트리밍과 동적 HTTP 스트리밍의 두 가지 동작 모드로 HTTP 스트리밍을 구현할 수 있다. 정적 HTTP 스트리밍의 경우, 콘텐츠는 미리 또는 서버와 상관없이 준비된다. 미디어 데이터의 구조는 클라이언트의 요구에 맞게 서버에 의해 수정되지 않는다. "정적" 모드의 정규 웹 서버는 정적 HTTP 스트리밍 모드에서만 동작할 수 있다. 동적 HTTP 스트리밍의 경우, 콘텐츠 준비는 서버에서 캐시되지 않은 요청을 수신하면 동적으로 수행된다. 동적 스트리밍 서버 및 동적 HTTP 스트리밍 서버와 동작 가능하게 연결된 정규 웹 서버는 동적 HTTP 스트리밍 모드에서 동작할 수 있다.
전송 파일 포맷
일 실시예에서, 전송 파일 포맷은 크게 2개의 클래스로 분류될 수 있다. 제 1 클래스에서, 전송된 파일은 파일 재생에 사용될 수 있는 기존 파일 포맷을 준수한다. 예를 들어, 전송된 파일은 ISO 기본 미디어 파일 포맷 또는 3GPP 파일 포맷의 프로그레시브 다운로드 프로파일(progressive download profile)을 준수한다.
제 2 클래스에서, 전송된 파일은 파일 재생에 사용되는 기존 파일 포맷에 따라 포맷된 파일과 유사하다. 예를 들어, 전송된 파일은 재생을 위해 개별적으로 자체 포함하지 않을 수도 있는 서버 파일의 프래그먼트일 수 있다. 다른 접근법에서, 전송될 파일은 파일 재생에 사용될 수 있는 기존의 파일 포맷을 준수하지만, 파일은 부분적으로만 전송되므로 그러한 파일의 재생은 부분 파일 관리에 대한 인식 및 능력을 필요로 한다.
전송된 파일은 일반적으로 파일 재생에 사용되는 기존 파일 포맷을 준수하도록 변환될 수 있다.
HTTP 캐시
HTTP 캐시(150)(도 5)는 HTTP 요청 및 요청에 대한 응답을 저장하여 대역폭 사용량, 서버 로드 및 인식된 지연을 줄이는 정규 웹 캐시일 수 있다. HTTP 캐시가 특정 HTTP 요청 및 그 응답을 포함하면, HTTP 스트리밍 서버 대신 요청자에게 서빙할 수 있다.
HTTP 스트리밍 클라이언트
HTTP 스트리밍 클라이언트(120)는 미디어 프레젠테이션의 파일(들)을 수신한다. HTTP 스트리밍 클라이언트(120)는 미디어 플레이어(130)를 포함할 수도 있고 그에 동작 가능하게 접속될 수도 있는데, 미디어 플레이어(130)는 파일을 파싱하고, 포함된 미디어 스트림을 디코딩하고, 디코딩된 미디어 스트림을 렌더링한다. 또한, 미디어 플레이어(130)는 수신된 파일(들)을 나중에 사용하기 위해 저장할 수 있다. 교환 파일 포맷은 저장을 위해 사용될 수 있다.
몇몇 예시적인 실시예에서, HTTP 스트리밍 클라이언트는 적어도 다음 두 클래스로 크게 분류될 수 있다. 제 1 클래스에서, 종래의 프로그레시브 다운로드 클라이언트는 수신되고 있는 디지털 미디어 파일에 대한 적절한 버퍼링 시간을 추측하거나 결정하고 이 버퍼링 시간 이후에 미디어 렌더링을 시작한다. 종래의 프로그레시브 다운로드 클라이언트는 미디어 프레젠테이션의 비트 레이트 적응과 관련된 요청을 생성하지 않는다.
제 2 클래스에서, 능동적 HTTP 스트리밍 클라이언트는 HTTP 스트리밍 클라이언트에서 프레젠테이션의 버퍼링 상태를 모니터링하고, 중단없는 프레젠테이션의 렌더링을 보장하기 위해 비트 레이트 적응과 관련된 요청을 생성할 수 있다.
HTTP 스트리밍 클라이언트(120)는 전송 파일 포맷에 따라 포맷된 수신된 HTTP 응답 페이로드를 교환 파일 포맷에 따라 포맷된 하나 이상의 파일로 변환할 수 있다. 변환은 HTTP 응답이 수신될 때 수행되는데, 즉, HTTP 응답은 수신되는 즉시 미디어 파일에 기록된다. 대안으로, 변환은 스트리밍 세션의 스트리밍 세션에 대한 모든 HTTP 응답까지 다수의 HTTP 응답이 수신되었을 때 수행될 수 있다. 변환은, 예를 들어, 수신된 HTTP 응답 페이로드의 순차적 결합이 뒤따르는 교환 파일의 시작 부분에 초기화 세그먼트를 배치하는 것을 포함할 수 있다.
교환 파일 포맷
몇몇 예시적인 실시예에서, 교환 파일 포맷은 적어도 다음과 같은 2개의 클래스로 크게 분류될 수 있다. 제 1 클래스에서 수신된 파일은 예컨대 전송 파일 포맷에 따라 저장된다.
제 2 클래스에서 수신된 파일은 파일 재생에 사용된 기존 파일 포맷에 따라 저장된다.
미디어 파일 플레이어
미디어 파일 플레이어(130)는 저장된 파일을 파싱, 검증, 디코딩 및 렌더링할 수 있다. 미디어 파일 플레이어(130)는 교환 파일들의 어느 한 클래스 또는 두 클래스 모두를 파싱, 검증, 디코딩 및 렌더링할 수 있다. 미디어 파일 플레이어(130)가 기존 파일 포맷에 따라 저장된 파일을 파싱 및 재생할 수 있지만 전송 파일 포맷에 따라 저장된 파일을 재생할 수 없는 경우, 미디어 파일 플레이어(130)는 레거시 플레이어로 지칭된다. 미디어 파일 플레이어(130)가 전송 파일 포맷에 따라 저장된 파일을 파싱 및 재생할 수 있다면, 미디어 파일 플레이어(130)는 HTTP 스트리밍 인식 플레이어로 지칭된다.
몇몇 구현예에서, HTTP 스트리밍 클라이언트는 하나 이상의 파일을 수신 및 저장하기만 하고 그들을 재생하지는 않는다. 반대로, 미디어 파일 플레이어는 이러한 파일이 수신되고 저장되고 있는 동안 이들을 파싱, 검증, 디코딩 및 렌더링한다.
몇몇 구현예에서, HTTP 스트리밍 클라이언트(120) 및 미디어 파일 플레이어(130)는 상이한 디바이스 내에 존재하거나 상주한다. 몇몇 구현예에서, HTTP 스트리밍 클라이언트(120)는 WLAN(wireless local area network) 접속과 같은 네트워크 접속을 통해 교환 파일 포맷에 따라 포맷된 미디어 파일을, 미디어 파일을 재생하는 미디어 파일 플레이어(130)로 전송한다. 미디어 파일은 수신된 HTTP 응답을 미디어 파일로 변환하는 프로세스에서 그것이 생성되고 있는 동안 전송될 수 있다. 대안으로, 미디어 파일은 수신된 HTTP 응답을 미디어 파일로 변환하는 프로세스에서 그것이 완성된 후에 전송될 수 있다. 미디어 파일 플레이어(130)는 미디어 파일이 수신되고 있는 동안 그것을 디코딩하고 재생할 수 있다. 예를 들어, 미디어 파일 플레이어(130)는 HTTP 스트리밍 클라이언트로부터의 HTTP GET 요청을 사용하여 미디어 파일을 점진적으로 다운로드할 수 있다. 대안으로, 미디어 파일 플레이어(130)는 미디어 파일이 완전히 수신된 후에 그것을 디코딩하고 재생할 수 있다.
HTTP 파이프라이닝(pipelining)은 다수의 HTTP 요청이 대응하는 응답을 기다리지 않고 단일 소켓에 기록되는 기술이다. 전송 제어 프로토콜(TCP) 패킷과 같은 동일한 전송 패킷에 몇 개의 HTTP 요청을 피팅(fitting)하는 것이 가능할 수 있기 때문에, HTTP 파이프라이닝은 네트워크를 통해 더 적은 전송 패킷이 전송되는 것을 허용하며, 이는 네트워크 부하를 줄일 수 있다.
접속은 서버 IP 주소, 서버 포트 번호, 클라이언트 IP 주소 및 클라이언트 포트 번호의 쿼드러플렛(quadruplet)에 의해 식별될 수 있다. 각 클라이언트 프로세스에는 상이한 포트 번호가 할당되므로 동일 클라이언트에서 동일 서버로 다수의 동시 TCP 접속이 가능하다. 따라서, 모든 TCP 접속이 동일한 서버 프로세스(예컨대, HTTP 전용인 포트 80에서의 웹 서버 프로세스)에 액세스하더라도, 이들은 모두 상이한 클라이언트 소켓을 가지며 고유 접속을 나타낸다. 이로 인해, 동일 컴퓨터로부터 동일 웹 사이트로 몇 개의 동시적 요청이 가능하다.
멀티미디어 포맷의 분류
멀티미디어 컨테이너 파일 포맷은, 멀티미디어 콘텐츠 제작, 조작, 전송 및 소비의 사슬에서 사용되는 요소이다. 코딩 포맷(기본 스트림 포맷이라고도 함)과 컨테이너 파일 포맷 간에는 상당한 차이가 있을 수 있다. 코딩 포맷은 콘텐츠 정보를 비트스트림으로 코딩하는 특정 코딩 알고리즘의 동작에 관련된다. 컨테이너 파일 포맷은, 다양한 저장 및 전송 아키텍처를 모두 활용하여, 로컬 디코딩 및 재생을 위해 액세스되거나, 파일로서 전송되거나 스트리밍될 수 있는 방식으로 생성된 비트스트림을 체계화하는 수단을 포함한다. 또한, 파일 포맷은 수신된 실시간 스트림을 파일에 기록하는 것뿐만 아니라 미디어의 교환 및 편집을 용이하게 할 수 있다.
도 7은 다양한 실시예가 구현될 수 있는 일반적 멀티미디어 통신 시스템의 일 예의 그래픽 표현이다. 도 7에 도시된 바와 같이, 데이터 소스(1500)는 아날로그, 비압축 디지털 또는 압축 디지털 포맷, 또는 이들 포맷의 임의의 조합으로 소스 신호를 제공한다. 인코더(1510)는 소스 신호를 코딩된 미디어 비트스트림으로 인코딩한다. 디코딩될 비트스트림은 사실상 임의 유형의 네트워크 내에 위치된 원격 디바이스로부터 직접 또는 간접적으로 수신될 수 있음에 유의해야 한다. 또한, 비트스트림은 로컬 하드웨어 또는 소프트웨어로부터 수신될 수 있다. 인코더(1510)는 오디오 및 비디오와 같은 하나 이상의 미디어 유형을 인코딩할 수 있거나, 소스 신호의 상이한 미디어 유형을 코딩하기 위해 하나 이상의 인코더(1510)가 필요할 수 있다. 인코더(1510)는 또한 그래픽 및 텍스트와 같은 합성적으로 생성된 입력을 얻을 수도 있고 합성 미디어의 코딩된 비트스트림을 생성할 수도 있다. 이하에서는, 설명을 단순화하기 위해 하나의 미디어 유형의 하나의 코딩된 미디어 비트스트림의 처리만이 고려된다. 그러나, 일반적으로 실시간 방송 서비스는 몇 개의 스트림(일반적으로 적어도 하나의 오디오, 비디오 및 텍스트 자막처리 스트림)을 포함한다는 점에 유의해야 한다. 또한, 시스템은 다수의 인코더를 포함할 수 있지만, 도 7에서는 보편성의 결여 없이 설명을 단순화하기 위해 하나의 인코더(1510)만이 표시됨에 유의해야 한다. 본 명세서에 포함된 텍스트 및 예는 인코딩 프로세스를 구체적으로 설명할 수 있지만, 당업자는 동일한 개념 및 원리가 대응하는 디코딩 프로세스에도 적용되고 그 반대도 마찬가지라는 것을 이해할 것이다.
코딩된 미디어 비트스트림은 스토리지(1520)로 전송된다. 스토리지(1520)는 코딩된 미디어 비트스트림을 저장하기 위한 임의의 유형의 대용량 메모리를 포함할 수 있다. 스토리지(1520) 내의 코딩된 미디어 비트스트림의 포맷은 기본 자체 포함 비트스트림 포맷일 수 있고, 하나 이상의 코딩된 미디어 비트스트림은 컨테이너 파일로 캡슐화될 수도 있다. 몇몇 시스템은 "라이브(live)"로 동작하는데, 즉, 스토리지를 생략하고 인코더(1510)로부터 송신기(1530)로 직접 코딩된 미디어 비트스트림을 전송한다. 그 다음, 코딩된 미디어 비트스트림은 필요에 따라 서버로 지칭되기도 하는 송신기(1530)로 전송된다. 전송에 사용된 포맷은 기본 자체 포함 비트스트림 포맷 또는 패킷 스트림 포맷일 수 있고, 하나 이상의 코딩된 미디어 비트스트림은 컨테이너 파일로 캡슐화될 수도 있다. 인코더(1510), 스토리지(1520) 및 송신기(1530)는 동일한 물리적 디바이스 내에 상주할 수도 있고, 개별 디바이스에 포함될 수도 있다. 인코더(1510) 및 송신기(1530)는 라이브 실시간 콘텐츠를 사용하여 동작할 수 있는데, 이 경우, 코딩된 미디어 비트스트림은 일반적으로 영구적으로 저장되지 않고 오히려 짧은 시간 동안 콘텐츠 인코더(1510) 및/또는 송신기(1530)에서 버퍼링되어, 처리 지연, 전송 지연 및 코딩된 미디어 비트 레이트의 변화를 제거한다.
송신기(1530)는 통신 프로토콜 스택을 사용하여 코딩된 미디어 비트스트림을 전송한다. 스택은 RTP(Real-Time Transport Protocol), UDP(User Datagram Protocol) 및 IP(Internet Protocol)을 포함할 수 있지만 이에 제한되지는 않는다. 통신 프로토콜 스택이 패킷 지향성(packet-oriented)일 경우, 송신기(1530)는 코딩된 미디어 비트스트림을 패킷으로 캡슐화한다. 예를 들어, RTP가 사용될 때, 송신기(1530)는 코딩된 미디어 비트스트림을 RTP 페이로드 포맷에 따라 RTP 패킷으로 캡슐화한다. 일반적으로, 각 미디어 유형은 전용 RTP 페이로드 포맷을 갖는다. 시스템이 하나 이상의 송신기(1530)를 포함할 수 있다는 것에 다시 한번 유의해야하지만, 단순화를 위해 다음의 설명은 하나의 송신기(1530)만을 고려한다.
미디어 콘텐츠가 스토리지(1520)를 위해 또는 송신기(1530)에 데이터를 입력하기 위해 컨테이너 파일에 캡슐화되는 경우, 송신기(1530)는 "송신 파일 파서"(도시되지 않음)를 포함할 수 있거나 이것에 동작 가능하게 부착될 수 있다. 특히, 컨테이너 파일이 그대로 전송되지 않고 포함된 코딩된 미디어 비트스트림 중 적어도 하나가 통신 프로토콜을 통한 전송을 위해 캡슐화되면, 송신 파일 파서는 통신 프로토콜을 통해 전달될 코딩된 미디어 비트스트림의 적절한 부분의 위치를 찾는다. 송신 파일 파서는 또한 패킷 헤더 및 페이로드와 같은 통신 프로토콜에 대한 올바른 포맷을 생성하는 데 도움을 줄 수도 있다. 멀티미디어 컨테이너 파일은 통신 프로토콜 상에서 포함된 미디어 비트스트림 중 적어도 하나를 캡슐화하기 위해, ISO 베이스 미디어 파일 포맷의 힌트 트랙과 같은 캡슐화 명령어를 포함할 수 있다.
송신기(1530)는 통신 네트워크를 통해 게이트웨이(1540)에 접속되거나 접속되지 않을 수 있다. 게이트웨이(1540)는, 하나의 통신 프로토콜 스택에 따른 패킷 스트림의 다른 통신 프로토콜 스택으로의 변환, 데이터 스트림의 병합 및 포킹(forking), 지배적인 다운링크 네트워크 상태에 따라 포워딩된 스트림의 비트 레이트을 제어하는 것과 같은 다운링크 및/또는 수신기 성능에 따른 데이터 스트림의 조작과 같은 상이한 유형의 기능을 수행할 수 있다. 게이트웨이(1540)의 예는, MCU, 회선 교환형과 패킷 교환형 화상 통화 사이의 게이트웨이, PoC(Push-to-Talk over Cellular) 서버, DVB-H(digital video broadcasting-handheld) 시스템 내의 IP 캡슐화기, 또는 방송 전송을 가정용 무선 네트워크로 로컬로 포워딩하는 셋톱 박스를 포함한다. RTP가 사용될 때, 게이트웨이(1540)는 RTP 믹서 또는 RTP 변환기로 불리며, 일반적으로 RTP 접속의 종단점으로서 작용한다.
시스템은 일반적으로 송신된 신호를 코딩된 미디어 비트스트림으로 수신, 복조 및 캡슐 해제할 수 있는 하나 이상의 수신기(1550)를 포함한다. 코딩된 미디어 비트스트림은 레코딩 스토리지(1555)로 전송된다. 레코딩 스토리지(1555)는 코딩된 미디어 비트스트림을 저장하기 위한 임의 유형의 대용량 메모리를 포함할 수 있다. 레코딩 스토리지(1555)는 대안으로 또는 부가적으로 랜덤 액세스 메모리와 같은 계산 메모리를 포함할 수 있다. 레코딩 스토리지(1555) 내의 코딩된 미디어 비트스트림의 포맷은 기본 자체 포함 비트스트림 포맷일 수 있거나 하나 이상의 코딩된 미디어 비트스트림이 컨테이너 파일로 캡슐화될 수도 있다. 서로 연관된 오디오 스트림 및 비디오 스트림과 같은 다수의 코딩된 미디어 비트스트림이 존재하는 경우, 일반적으로 컨테이너 파일이 사용되고 수신기(1550)는 입력 스트림으로부터 컨테이너 파일을 생성하는 컨테이너 파일 생성기를 포함하거나 그에 부착된다. 몇몇 시스템은 "라이브"로 동작하는데, 즉, 레코딩 스토리지(1555)를 생략하고 코딩된 미디어 비트스트림을 수신기(1550)로부터 직접 디코더(1560)로 전송한다. 몇몇 시스템에서, 레코딩된 스트림의 가장 최근의 부분, 예컨대 레코딩된 스트림의 가장 최근 10분의 발췌부분은 레코딩 스토리지(1555)에서 유지되고, 이전에 레코딩된 데이터는 레코딩 스토리지(1555)로부터 폐기된다.
코딩된 미디어 비트스트림은 레코딩 스토리지(1555)로부터 디코더(1560)로 전송된다. 서로 연관되고 컨테이너 파일로 캡슐화된 오디오 스트림 및 비디오 스트림과 같은 많은 코딩된 미디어 비트스트림이 존재하는 경우, 파일 파서(도면에 도시되지 않음)는 컨테이너 파일로부터 각각의 코딩된 미디어 비트스트림을 캡슐 해제하기 위해 사용된다. 레코딩 스토리지(1555) 또는 디코더(1560)가 파일 파서를 포함할 수 있거나, 파일 파서는 레코딩 스토리지(1555) 또는 디코더(1560) 중 하나에 부착될 수 있다.
코딩된 미디어 비트스트림은 하나 이상의 비압축 미디어 스트림을 출력하는 디코더(1560)에 의해 더 처리될 수 있다. 마지막으로, 렌더러(renderer)(1570)는 예를 들어 확성기 또는 디스플레이를 사용하여 비압축 미디어 스트림을 재생성할 수 있다. 수신기(1550), 레코딩 스토리지(1555), 디코더(1560) 및 렌더러(1570)는 동일한 물리적 디바이스에 상주할 수도 있고, 개별 디바이스에 포함될 수도 있다.
도 8은, 본 발명의 일 실시예에 따른 코덱을 포함할 수 있는 예시적 장치 또는 전자 디바이스(50)의 개략적 블록도로서 일 실시예에 따른 비디오 코딩 시스템의 블록도를 도시한다. 도 9는 예시적인 실시예에 따른 장치의 레이아웃을 도시한다. 도 8 및 도 9의 요소들은 다음에 설명될 것이다.
전자 디바이스(50)는 예를 들어 무선 통신 시스템의 이동 단말기 또는 사용자 장비일 수 있다. 그러나, 본 발명의 실시예들은 비디오 이미지의 인코딩 및 디코딩 또는 인코딩 또는 디코딩을 요구할 수 있는 임의의 전자 디바이스 또는 장치 내에서 구현될 수 있음이 이해될 것이다.
장치(50)는 디바이스를 통합하고 보호하기 위한 하우징(30)을 포함할 수 있다. 장치(50)는 액정 디스플레이 형태의 디스플레이(32)를 더 포함할 수 있다. 본 발명의 다른 실시예에서, 디스플레이는 이미지 또는 비디오를 디스플레이하기에 적합한 임의의 적합한 디스플레이 기술일 수 있다. 장치(50)는 키패드(34)를 더 포함할 수 있다. 본 발명의 다른 실시예에서, 임의의 적합한 데이터 또는 사용자 인터페이스 메커니즘이 사용될 수 있다. 예를 들어, 사용자 인터페이스는 터치 감지 디스플레이의 일부로서 가상 키보드 또는 데이터 입력 시스템으로서 구현될 수 있다. 장치는 마이크로폰(36), 또는 디지털 또는 아날로그 신호 입력일 수 있는 임의의 적절한 오디오 입력을 포함할 수 있다. 장치(50)는, 본 발명의 실시예에서 이어 피스(38), 스피커, 또는 아날로그 오디오 또는 디지털 오디오 출력 접속 중 하나일 수 있는 오디오 출력 디바이스를 더 포함할 수 있다. 장치(50)는 또한 배터리(40)를 포함할 수 있다(또는 본 발명의 다른 실시예에서는 태양 전지, 연료 전지 또는 태엽 발전기(clockwork generator)와 같은 임의의 적합한 모바일 에너지 디바이스에 의해 동력을 공급받을 수 있다). 장치는 이미지 및/또는 비디오를 레코딩 또는 캡처할 수 있는 카메라(42)를 더 포함할 수 있다. 일 실시예에 따르면, 장치(50)는 다른 디바이스들에 대한 단거리 시선 통신을 위한 적외선 포트를 더 포함할 수 있다. 다른 실시예에서, 장치(50)는 예를 들어 블루투스 무선 접속 또는 USB/파이어와이어 유선 접속과 같은 임의의 적합한 단거리 통신 솔루션을 더 포함할 수 있다.
장치(50)는 장치(50)를 제어하기 위한 제어기(56) 또는 프로세서를 포함할 수 있다. 제어기(56)는, 본 발명의 실시예에서 이미지 및 오디오 데이터 형태의 데이터를 모두 저장할 수 있고/있거나 제어기(56) 상에서 구현하기 위한 명령어를 또한 저장할 수 있는 메모리(58)에 접속될 수 있다. 제어기(56)는 또한, 오디오 및/또는 비디오 데이터의 코딩 및 디코딩을 수행하거나 제어기(56)에 의해 수행되는 코딩 및 디코딩을 보조하는데 적합한 코덱 회로(54)에 접속될 수 있다.
장치(50)는, 사용자 정보를 제공하고 네트워크에서 사용자의 인증 및 허가를위한 인증 정보를 제공하기에 적합한, UICC 및 UICC 판독기와 같은 카드 판독기(48) 및 스마트 카드(46)를 더 포함할 수 있다.
장치(50)는, 예컨대 셀룰러 통신 네트워크, 무선 통신 시스템 또는 무선 로컬 영역 네트워크와 통신하기 위한 무선 통신 신호를 생성하기에 적합하고 제어기에 접속된 무선 인터페이스 회로(52)를 포함할 수 있다. 장치(50)는, 무선 인터페이스 회로(52)에 접속되어 무선 인터페이스 회로(52)에서 생성된 무선 주파수 신호를 다른 장치(들)로 송신하고 다른 장치(들)로부터 무선 주파수 신호를 수신하는 안테나(44)를 더 포함할 수 있다.
일 실시예에 따르면, 장치(50)는, 처리를 위해 코덱(54) 또는 제어기로 전달되는 개별 프레임을 레코딩 또는 검출할 수 있는 카메라를 포함한다. 일 실시예에 따르면, 장치는 전송 및/또는 저장에 앞서 다른 디바이스로부터 처리를 위한 비디오 이미지 데이터를 수신할 수 있다. 일 실시예에 따르면, 장치(50)는 코딩/디코딩을 위한 이미지를 무선 또는 유선 접속에 의해 수신할 수 있다.
도 10은 예시적인 실시예에 따른 복수의 장치, 네트워크 및 네트워크 요소를 포함하는, 비디오 코딩을 위한 배치를 도시한다. 도 10을 참조하면, 본 발명의 실시예가 활용될 수 있는 시스템의 예가 도시된다. 시스템(10)은 하나 이상의 네트워크를 통해 통신할 수 있는 다수의 통신 디바이스를 포함한다. 시스템(10)은 무선 셀룰러 전화 네트워크(예컨대, GSM, UMTS, CDMA 네트워크 등), 예컨대 IEEE 802.x 표준들 중 임의의 것에 의해 정의되는 WLAN(wireless local area network), 블루투스 사설 영역 네트워크, 이더넷 로컬 영역 네트워크, 토큰 링 로컬 영역 네트워크, 광역 통신망, 및 인터넷을 포함을 포함하지만 이에 제한되지는 않는 유선 또는 무선 네트워크의 임의의 조합을 포함할 수 있다.
시스템(10)은 유선 및 무선 통신 디바이스 또는 본 발명의 실시예를 구현하기에 적합한 장치(50)를 포함할 수 있다. 예를 들어, 도 10에 도시된 시스템은 이동 전화 네트워크(11) 및 인터넷(28)의 표현을 도시한다. 인터넷(28)으로의 접속은 장거리 무선 접속, 단거리 무선 접속, 전화선, 케이블 회선, 전력선 및 유사한 통신 경로를 포함하지만 이에 제한되지는 않는 다양한 유선 접속을 포함할 수 있지만 이에 제한되는 것은 아니다.
시스템(10)에 도시된 예시적인 통신 디바이스는 전자 디바이스 또는 장치(50), 개인 휴대 정보 단말기(PDA)와 이동 전화의 결합(14), PDA(16), 통합 메시징 디바이스(IMD)(18), 데스크톱 컴퓨터(20), 노트북 컴퓨터(22)를 포함하지만 이에 제한되지는 않는다. 장치(50)는 움직이고 있는 사람에 의해 운반될 때 정지되거나 이동될 수 있다. 장치(50)는 또한, 자동차, 트럭, 택시, 버스, 기차, 보트, 비행기, 자전거, 오토바이 또는 임의의 유사한 적합한 운송 모드를 포함하지만 이에 제한되지는 않는 운송 모드에 위치될 수 있다.
일부 또는 추가 장치는 호출 및 메시지를 송수신할 수 있고, 기지국(24)에 대한 무선 접속(25)을 통해 서비스 제공자와 통신할 수 있다. 기지국(24)은 이동 전화 네트워크(11)와 인터넷(28) 사이의 통신을 허용하는 네트워크 서버(26)에 접속될 수 있다. 시스템은 부가적인 통신 디바이스 및 다양한 유형의 통신 디바이스를 포함할 수 있다.
통신 디바이스는 CDMA(code division multiple access), GSM(global systems for mobile communications), UMTS(universal mobile telecommunications system), TDMA(time divisional multiple access), FDMA(frequency division multiple access), TCP-IP(transmission control protocol-internet protocol), SMS(short messaging service), MMS(multimedia messaging service), 이메일, IMS(instant messaging service), 블루투스, IEEE 802.11 및 임의의 유사한 무선 통신 기술을 포함하지만 이에 제한되지는 않는 다양한 송신 기술을 사용하여 통신할 수 있다. 본 발명의 다양한 실시예를 구현하는 것과 관련된 통신 디바이스는 무선, 적외선, 레이저, 케이블 접속 및 임의의 적합한 접속을 포함하지만 이에 제한되지는 않는 다양한 매체를 사용하여 통신할 수 있다.
위에서 몇몇 실시예는 ISOBMFF의 구조 및 개념을 참조하여 설명되었다. 실시예는 마트로스카 또는 그 파생물과 같은 다른 컨테이너 파일 포맷으로 유사하게 실현될 수 있다는 것이 이해되어야 한다. 실시예는 박스와 같은 ISOBMFF의 구조와 유사한 데이터 구조를 참조하여 유사하게 실현될 수 있다.
위에서 몇몇 실시예는 특정 MediaDataBox 또는 유사한 어구(phrase)와 관련된 어구 오프셋(들)을 참조하여 설명되었다. 한편, 몇몇 실시예는 MediaDataBox 내의 미디어 페이로드 데이터의 시작 부분에 오프셋(들)을 추가함으로써 오프셋(들)에 의해 지시된 위치를 유도하는 것을 보다 명확하게 설명한다. 더 나아가, 오프셋(들)이 MediaDataBox의 시작부에 관련되는 몇몇 실시예가 설명되었다. 오프셋(들)에 대한 참조 포인트가 MediaDataBox의 시작 부분(MediaDataBox의 박스 헤더의 첫 번째 바이트)이거나, (몇몇 실시예에서 MediaDataBox의 식별자를 가리킬 수 있는) MediaDataBox의 박스 데이터의 시작 부분이거나, MediaDataBox 내의 미디어 데이터의 시작 부분(몇몇 실시예에서는 MediaDataBox의 식별자 바로 다음의 바이트임)이거나 또는 MediaDataBox의 위치에 관련되는 임의의 사전 정의되거나 표시된 위치인 경우에 실시예는 유사하게 실현될 수 있음이 이해되어야 한다.
위에서 몇몇 실시예는 ISOBMFF에 정의된 MediaDataBox(들)를 참조하여 설명되었다. 몇몇 실시예는 다른 박스 유형에 의해 유사하게 실현될 수 있음이 이해되어야 한다. 예를 들어, MediaDataBox의 식별자에 대한 또는 그에 기초한 실시예는 다른 박스 유형에 대해 유사하게 구현될 수 있다. 또한 실시예들이 미디어 데이터에 대한 다른 컨테이너 구조에 의해 유사하게 구현될 수 있음이 이해되어야 한다. 예를 들어, 미디어 데이터가 뒤따르는 mdat_identifier 또는 이와 유사한 것을 포함하기 위해 MediaDataBox와는 다른 4 문자 코드를 가진 새로운 박스 유형이 특정될 수 있다.
위에서 몇몇 실시예는 HTTP 및 HTTP/1.1과 관련하여 설명되었다. 실시예는 HTTP의 사용에 제한되지 않고, 웹 소켓과 같은 다른 프로토콜, 또는 HTTP/2와 같은 HTTP의 다른 버전이 대신 또는 추가로 사용될 수 있다.
위에서 몇몇 실시예는 DASH의 포맷 및 개념을 참조하여 설명되었다. 실시예가 (IETF 인터넷 드래프트 draft-pantos-http-live-streaming에 정의된 바와 같은) HTTP 라이브 스트리밍 또는 MPEG 미디어 트랜스 포트(MMT, ISO/TEC 23008의 일부로서 특정됨)와 같은 다른 스트리밍 및 전송 시스템 및 메커니즘에 의해 유사하게 실현될 수 있음이 이해되어야 한다.
위에서 몇몇 실시예는 파일을 참조하여 설명되었다. DASH에 정의된 바와 같은 세그먼트 또는 서브세그먼트와 같은 파일 세그먼트, 또는 예컨대 HTTP GET 요청에 대한 응답으로 수신되는 것으로 이해되는 리소스를 참조하여 실시예가 마찬가지로 설명될 수 있음이 이해되어야 한다.
위에서 몇몇 실시예는 예컨대 URL 프래그먼트 스킴을 통해 동일한 컨테이너 파일 내에 저장된 다수의 대체 이미지의 사용 가능성을 공표할 때 HTML 5.1의 특징을 참조하여 설명되었다. URL 프래그먼트 스킴 또는 이와 유사한 것이 사용되는 다른 스킴에 의해 실시예가 유사하게 구현될 수 있음이 이해되어야 한다. 예를 들어, 실시예는 SMIL(Synchronized Media Integration Language)과 함께 사용될 수 있다.
본 발명의 실시예들은 소프트웨어, 하드웨어, 애플리케이션 로직, 또는 소프트웨어, 하드웨어 및 애플리케이션 로직의 조합으로 구현될 수 있다. 예시적인 실시예에서, 애플리케이션 로직, 소프트웨어 또는 명령어 세트는 다양한 종래의 컴퓨터-판독가능 매체 중 임의의 하나 상에서 유지된다. 이 문서의 맥락에서, "컴퓨터 판독가능 매체"는 도 8 및 도 9에 설명되고 도시된 컴퓨터의 일 예를 갖는 컴퓨터와 같은 명령어 실행 시스템, 장치 또는 디바이스에 의해 또는 이와 관련하여 사용하기 위한 명령어를 포함, 저장, 통신, 전파 또는 전송할 수 있는 임의의 매체 또는 수단일 수 있다. 컴퓨터 판독가능 매체는 컴퓨터와 같은 명령어 실행 시스템, 장치 또는 디바이스에 의해 또는 그와 관련하여 사용하기 위한 명령을 포함하거나 저장할 수 있는 임의의 매체 또는 수단일 수 있는 컴퓨터 판독가능 저장 매체를 포함할 수 있다.
원한다면, 여기에서 설명된 상이한 기능들은 서로 다른 순서 및/또는 동시에 수행될 수 있다. 또한, 원한다면, 전술된 기능들 중 하나 이상은 선택사항이거나 조합될 수 있다.
일반적으로, 본 발명의 다양한 실시예는 하드웨어 또는 특수 목적 회로, 소프트웨어, 로직 또는 이들의 임의의 조합으로 구현될 수 있다. 예를 들어, 몇몇 양태는 하드웨어로 구현될 수 있지만, 다른 양태는 제어기 또는 마이크로프로세서 또는 다른 컴퓨팅 디바이스에 의해 실행될 수 있는 펌웨어 또는 소프트웨어로 구현될 수 있으며, 본 발명은 이에 제한되지 않는다. 본 발명의 다양한 양태는 블록도, 순서도 또는 몇몇 다른 그림 표현을 사용하여 도시되고 설명될 수 있지만, 본 명세서에 설명된 이러한 블록, 장치, 시스템, 기술 또는 방법은 비제한적 예로서 하드웨어, 소프트웨어, 펌웨어, 특수 목적 회로 또는 논리, 범용 하드웨어 또는 제어기 또는 다른 컴퓨팅 디바이스, 또는 이들의 조합으로 구현될 수 있음이 쉽게 이해된다.
본 발명의 실시예들은 프로세서 엔티티와 같은 모바일 디바이스의 데이터 프로세서에 의해, 또는 하드웨어에 의해, 또는 소프트웨어와 하드웨어의 조합에 의해 실행 가능한 컴퓨터 소프트웨어에 의해 구현될 수 있다. 또한 이와 관련하여, 도면에서와 같은 논리 흐름의 임의의 블록은 프로그램 단계, 상호접속된 논리 회로, 블록 및 기능, 또는 프로그램 단계, 논리 회로 블록 및 기능의 조합을 나타낼 수 있음에 유의해야 한다. 소프트웨어는 메모리 칩, 또는 프로세서 내에 구현된 메모리 블록과 같은 물리적 매체, 하드 디스크 또는 플로피 디스크와 같은 자기 매체, 및 예를 들어 DVD 및 그의 데이터 변형물인 CD와 같은 광학 매체 상에 저장될 수 있다.
본 발명의 다양한 실시예들은, 메모리에 상주하고 관련 장치들로 하여금 본 발명을 수행하게 하는 컴퓨터 프로그램 코드의 도움으로 구현될 수 있다. 예를 들어, 단말 디바이스는 데이터를 처리, 수신 및 송신하기 위한 회로 및 전자장치, 메모리 내의 컴퓨터 프로그램 코드, 및 컴퓨터 프로그램 코드를 실행할 때 단말 디바이스로 하여금 실시예의 특징을 수행하게 하는 프로세서를 포함할 수 있다. 또한, 네트워크 디바이스는 데이터를 처리, 수신 및 송신하기 위한 회로 및 전자장치, 메모리 내의 컴퓨터 프로그램 코드, 및 컴퓨터 프로그램 코드를 실행할 때 네트워크 디바이스로 하여금 실시예의 특징을 수행하게 하는 프로세서를 포함할 수 있다.
메모리는 로컬 기술 환경에 적합한 임의 유형일 수 있고, 반도체 기반 메모리 디바이스, 자기 메모리 디바이스 및 시스템, 광 메모리 디바이스 및 시스템, 고정 메모리 및 착탈식 메모리와 같은 임의의 적합한 데이터 저장 기술을 사용하여 구현될 수 있다. 데이터 프로세서는 로컬 기술 환경에 적합한 임의 유형일 수 있으며, 범용 컴퓨터, 특수 목적 컴퓨터, 마이크로프로세서, 디지털 신호 프로세서(DSP) 및 멀티 코어 프로세서 아키텍처 기반의 프로세서를 비제한적 예로서 포함할 수 있다.
본 발명의 실시예들은 집적 회로 모듈과 같은 다양한 컴포넌트로 실시될 수 있다. 집적 회로 설계는 대체로 고도로 자동화된 프로세스이다. 로직 레벨 설계를 반도체 기판에 에칭 및 형성될 준비가 된 반도체 회로 설계로 변환하기 위해 복잡하고 강력한 소프트웨어 툴이 사용될 수 있다.
캘리포니아주 마운틴뷰에 있는 Synopsys Inc. 및 캘리포니아주 산호세에 있는 Cadence Design에 의해 제공되는 것과 같은 프로그램은 잘 설정된 설계 규칙뿐만 아니라 사전 저장된 설계 모듈의 라이브러리를 사용하여 도체를 자동으로 라우팅하고 반도체 칩에 부품을 배치한다. 일단 반도체 회로에 대한 설계가 완료되면, 표준화된 전자 포맷(예를 들어, Opus, GDSII 등)의 결과적인 설계는 제조를 위해 반도체 제조 시설 또는 "제조공장(fab)"에 전송될 수 있다.
전술한 설명은 예시적이고 비제한적인 예에 의해 본 발명의 예시적 실시예의 완전하고 유익한 설명을 제공한다. 그러나, 첨부된 도면 및 첨부된 청구 범위와 관련하여 읽을 때, 전술한 설명의 측면에서 당업자에게는 다양한 수정 및 개조가 명백해질 수 있다. 그러나, 본 발명의 교시에 대한 이와 같은 변경과 유사한 변경은 모두 여전히 본 발명의 범위에 속한다.
이하에서는 몇몇 예가 제공될 것이다.
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하는 단계와,
오프셋 데이터를 수신하는 단계와,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하는 단계와,
검사가 상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다고 나타내면, 상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하는 단계를 포함하는
방법이 제공된다.
실시예에서, 상기 방법은,
상기 미디어 데이터 구조의 식별자를 수신하는 단계 － 상기 식별자는 상기 오프셋 데이터와 연관됨 － 와,
상기 식별자에 기초하여 상기 컨테이너 파일로부터 상기 미디어 데이터 구조를 선택하는 단계를 더 포함한다.
실시예에서, 상기 방법은,
상기 미디어 데이터 구조 내에서 제 2 식별자를 수신하는 단계와,
상기 제 2 식별자와 동일한 식별자에 기초하여 상기 컨테이너 파일로부터 상기 미디어 데이터 구조를 선택하는 단계를 더 포함한다.
실시예에서, 상기 방법은,
상기 컨테이너 파일 내에 포함된 데이터 참조 리스트에 대한 데이터 참조 인덱스와 상기 오프셋 데이터를 연관시키는 단계와,
상기 데이터 참조 인덱스를 사용하여 상기 데이터 참조 리스트로부터 데이터 참조를 선택하는 단계 － 상기 선택된 데이터 참조는 상기 미디어 데이터 구조의 식별자를 포함함 － 를 더 포함한다.
실시예에서, 상기 방법은,
상기 오프셋 데이터를 포함하는 데이터 구조 내에서 상기 식별자를 수신하는 단계를 더 포함한다.
상기 방법의 실시예에서, 상기 적어도 하나의 미디어 데이터 유닛은 트랙의 샘플이고, 상기 트랙은 샘플 시퀀스를 디코딩 순서로 포함한다.
상기 방법의 실시예에서, 상기 적어도 하나의 미디어 데이터 유닛은 디코딩 순서와 연관되지 않은 아이템이다.
상기 방법의 실시예에서, 상기 오프셋 데이터는 상기 미디어 데이터 구조의 시작 부분에 관련되고,
상기 방법은, 상기 오프셋 데이터 및 상기 미디어 데이터 구조의 시작 부분의 위치를 사용하여 상기 미디어 데이터 유닛을 획득하는 단계를 더 포함한다.
상기 방법의 실시예에서, 상기 컨테이너 파일은 상기 미디어 데이터의 2개 이상의 서브세트를 포함하고,
상기 방법은 상기 2개 이상의 서브세트 중에서 상기 미디어 데이터의 하나의 서브세트를 서버로부터 요청하는 단계를 더 포함한다.
실시예에서, 상기 방법은,
오프셋을 포함하는 제 1 미디어 파일 포맷 박스를 수신하는 단계 － 상기 제 1 미디어 파일 포맷 박스는 어드레싱된 데이터를 포함하는 제 2 미디어 파일 포맷 박스와 연관됨 － 와,
상기 제 2 미디어 파일 포맷 박스를 수신하는 단계와,
상기 제 1 미디어 파일 포맷 박스로부터의 오프셋 데이터를 사용하여 상기 제 2 미디어 파일 포맷 박스로부터 상기 미디어 데이터 유닛을 획득하는 단계를 더 포함한다.
제 2 예에서는, 적어도 하나의 프로세서 및 적어도 하나의 메모리를 포함하는 장치로서,
상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하는 것과,
오프셋 데이터를 수신하는 것과,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하는 것과,
검사가 상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다고 나타내면, 상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하는 것
을 수행하게 하는 코드가 저장되어 있는
장치가 제공된다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
상기 미디어 데이터 구조의 식별자를 수신하는 것 － 상기 식별자는 상기 오프셋 데이터와 연관됨 － 과,
상기 식별자에 기초하여 상기 컨테이너 파일로부터 상기 미디어 데이터 구조를 선택하는 것
을 수행하게 하는 코드가 저장되어 있다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
상기 미디어 데이터 구조 내에서 제 2 식별자를 수신하는 것과,
상기 제 2 식별자와 동일한 식별자에 기초하여 상기 컨테이너 파일로부터 상기 미디어 데이터 구조를 선택하는 것
을 수행하게 하는 코드가 저장되어 있다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
상기 컨테이너 파일 내에 포함된 데이터 참조 리스트에 대한 데이터 참조 인덱스와 상기 오프셋 데이터를 연관시키는 것과,
상기 데이터 참조 인덱스를 사용하여 상기 데이터 참조 리스트로부터 데이터 참조를 선택하는 것 － 상기 선택된 데이터 참조는 상기 미디어 데이터 구조의 식별자를 포함함 －
을 수행하게 하는 코드가 저장되어 있다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
상기 오프셋 데이터를 포함하는 데이터 구조 내에서 상기 식별자를 수신하는 것을 수행하게 하는 코드가 저장되어 있다.
상기 장치의 실시예에서, 상기 오프셋 데이터는 상기 미디어 데이터 구조의 시작 부분에 관련되고,
상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도, 상기 오프셋 데이터 및 상기 미디어 데이터 구조의 시작 부분의 위치를 사용하여 상기 미디어 데이터 유닛을 획득하는 것을 수행하게 하는 코드가 저장되어 있다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
오프셋을 포함하는 제 1 미디어 파일 포맷 박스를 수신하는 것 － 상기 제 1 미디어 파일 포맷 박스는 어드레싱된 데이터를 포함하는 제 2 미디어 파일 포맷 박스와 연관됨 － 과,
상기 제 2 미디어 파일 포맷 박스를 수신하는 것과,
상기 제 1 미디어 파일 포맷 박스로부터의 오프셋 데이터를 사용하여 상기 제 2 미디어 파일 포맷 박스로부터 상기 미디어 데이터 유닛을 획득하는 것
을 수행하게 하는 코드가 저장되어 있다.
제 3 예에서는, 컴퓨터 프로그램 코드를 포함하는 비일시적 컴퓨터 판독가능 매체 상에서 구현된 컴퓨터 프로그램 제품으로서,
상기 프로그램 코드는 적어도 하나의 프로세서 상에서 실행될 때 장치 또는 시스템으로 하여금,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하게 하고,
오프셋 데이터를 수신하게 하고,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하게 하고,
검사가 상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다고 나타내면, 상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여 상기 미디어 데이터 유닛을 획득하게 하도록 구성되는
컴퓨터 프로그램 제품이 제공된다.
제 4 예에서는, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하는 단계와,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하는 단계와,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키는 단계를 포함하는
방법이 제공된다.
실시예에서, 상기 방법은,
상기 컨테이너 파일 내에 상기 미디어 데이터 구조의 제 1 식별자를 포함시키는 단계를 더 포함하되, 상기 제 1 식별자는 상기 오프셋 데이터와 연관된다.
실시예에서, 상기 방법은,
상기 컨테이너 파일 내에 상기 미디어 데이터 구조 내의 미디어 데이터 구조의 제 2 식별자를 포함시키는 단계를 더 포함하되, 상기 제 2 식별자는 상기 제 1 식별자와 동일한 것이다.
실시예에서, 상기 방법은,
상기 컨테이너 파일 내에 데이터 참조 리스트를 포함시키는 단계와,
상기 데이터 참조 리스트 내에 상기 제 1 식별자를 포함하는 데이터 참조를 포함시키는 단계와,
상기 컨테이너 파일 내에서, 상기 데이터 참조 리스트에 대한 데이터 참조 인덱스와 상기 오프셋 데이터를 연관시키는 단계 － 상기 데이터 참조 인덱스는 상기 제 1 식별자를 포함하는 데이터 참조를 참조함 － 와,
상기 데이터 참조 인덱스를 사용하여 상기 데이터 참조 리스트로부터 데이터 참조를 선택하는 단계 － 상기 선택된 데이터 참조는 상기 미디어 데이터 구조의 식별자를 포함함 － 를 더 포함한다.
실시예에서, 상기 방법은,
상기 오프셋 데이터를 포함하는 데이터 구조 내에 상기 제 1 식별자를 포함시키는 단계를 더 포함한다.
제 5 예에서는, 적어도 하나의 프로세서 및 적어도 하나의 메모리를 포함하는 장치로서,
상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하는 것과,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하는 것과,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키는 것
을 수행하게 하는 코드가 저장되어 있는
장치가 제공된다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
상기 컨테이너 파일 내에 상기 미디어 데이터 구조의 제 1 식별자를 포함시키는 것 － 상기 제 1 식별자는 상기 오프셋 데이터와 연관됨 － 을 수행하게 하는 코드가 저장되어 있다.
상기 장치의 실시예에서, 상기 적어도 하나의 메모리에는, 상기 적어도 하나의 프로세서에 의해 실행될 때 장치로 하여금 적어도,
상기 컨테이너 파일 내에 상기 미디어 데이터 구조 내의 미디어 데이터 구조의 제 2 식별자를 포함시키는 것 － 상기 제 2 식별자는 상기 제 1 식별자와 동일한 것임 － 을 수행하게 하는 코드가 저장되어 있다.
제 6 예에서는, 컴퓨터 프로그램 코드를 포함하는 비일시적 컴퓨터 판독가능 매체 상에서 구현된 컴퓨터 프로그램 제품으로서,
상기 프로그램 코드는 적어도 하나의 프로세서 상에서 실행될 때 장치 또는 시스템으로 하여금,
미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하게 하고,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하게 하고,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키게 하도록 구성되는
컴퓨터 프로그램 제품이 제공된다.
제 7 예에서는, 제 1 예의 방법을 수행하도록 구성된 장치가 제공된다.
제 8 예에서는, 제 4 예의 방법을 수행하도록 구성된 장치가 제공된다.
제 9 예에서는, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 수신하는 수단과,
오프셋 데이터를 수신하는 수단과,
상기 오프셋 데이터가 상기 컨테이너 파일 내의 상기 미디어 데이터 구조의 위치에 관련된다고 판정하는 수단과,
상기 오프셋 데이터를 상기 미디어 데이터 구조의 위치에 대한 참조로서 사용하여, 검사가 상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다고 나타내면, 상기 미디어 데이터 유닛을 획득하는 수단을 포함하는
장치가 제공된다.
제 10 예에서는, 미디어 데이터 구조 내에 적어도 하나의 미디어 데이터 유닛을 포함하는 컨테이너 파일을 형성하는 수단과,
상기 미디어 데이터 구조에 관련된 상기 미디어 데이터 유닛의 위치에 대한 참조로서 오프셋 데이터를 상기 컨테이너 파일에 형성하는 수단과,
상기 오프셋 데이터가 상기 미디어 데이터 구조의 위치에 관련된다는 표시를 포함시키는 수단을 포함하는
장치가 제공된다.
제 11 예에서는, 제 1 요청에 의해 파일의 일부를 요청하는 단계를 포함하되, 상기 제 1 요청은 데이터 구조의 식별을 포함하고, 상기 식별은 유형 및 식별자를 포함하고, 상기 식별자는 동일 유형의 몇 개의 데이터 구조 중에서 상기 데이터 구조를 식별하는
방법이 제공된다.
제 12 예에서는, 파일의 일부를 요청하는 제 1 요청을 수신하는 단계 － 상기 제 1 요청은 데이터 구조의 식별을 포함하고, 상기 식별은 유형 및 식별자를 포함하고, 상기 식별자는 동일 유형의 몇 개의 데이터 구조 중에서 상기 데이터 구조를 식별함 － 와,
상기 파일의 일부를 결정(concluding)하는 단계 － 상기 결정은 상기 유형 및 상기 식별자에 기초한 상기 데이터 구조의 식별을 포함함 － 와,
상기 파일의 일부를 송신함으로써 상기 제 1 요청에 응답하는 단계를 포함하는
방법이 제공된다.
실시예에서, 상기 방법은,
2개 이상의 청크로 상기 파일의 일부를 점진적으로 송신하는 단계를 더 포함한다.
제 13 실시예에서는, 제 11 예의 방법을 수행하도록 구성된 장치가 제공된다.
제 14 예에서는, 제 12 예의 방법을 수행하도록 구성된 장치가 제공된다.
Claims (63)
- 국제 표준 기구 기본 미디어 파일 포맷(International Standards Organization Base Media File Format, ISOBMFF)에 기초한 컨테이너 파일을 수신하는 수단 - 상기 컨테이너 파일은,
적어도 두개의 미디어 데이터 박스 - 적어도 하나의 미디어 데이터 박스는 상기 적어도 하나의 미디어 데이터 박스를 상기 컨테이너 파일 내의 다른 미디어 데이터 박스로부터 식별하는 미디어 데이터 박스 식별자의 값을 포함하도록 확장됨 - 와,
데이터 필드로서 상기 미디어 데이터 박스 식별자의 값을 갖는 데이터 엔트리 박스를 포함하는 데이터 참조 박스를 포함함으로써 상기 적어도 하나의 미디어 데이터 박스와 연관되는 적어도 하나의 트랙과,
상기 적어도 하나의 미디어 데이터 박스 내의 적어도 하나의 미디어 샘플의 위치를 지시하는 오프셋
을 포함함 - 과,
상기 데이터 엔트리 박스 내의 상기 미디어 데이터 박스 식별자의 값을 확인함으로써 상기 적어도 하나의 미디어 샘플이 상기 적어도 하나의 미디어 데이터 박스에 포함되어 있다고 판정하는 수단을 포함하는
장치.
- 제 1 항에 있어서,
상기 적어도 하나의 미디어 데이터 박스로부터 적어도 하나의 미디어 데이터 유닛을 획득하기 위해 상기 오프셋을 사용하는 수단을 더 포함하며,
상기 오프셋은 상기 컨테이너 파일 내의 상기 적어도 하나의 미디어 데이터 박스의 위치의 시작에 상대적인
장치.
- 제 1 항 또는 제 2 항에 있어서,
상기 오프셋은 상기 데이터 참조 박스 내에 포함되어 있는 상기 데이터 엔트리 박스를 지시하는 데이터 참조 인덱스를 통해 상기 트랙의 샘플 엔트리와 연관되는
장치.
- 제 3 항에 있어서,
상기 샘플 엔트리는 상기 ISOBMFF에 기초하여 상기 트랙의 샘플 설명 박스 (a sample description box)에 포함되는
장치.
- 제 1 항 또는 제 2 항에 있어서,
상기 미디어 데이터 박스 식별자는 32 비트 숫자를 포함하는
장치.
- 국제 표준 기구 기본 미디어 파일 포맷(International Standards Organization Base Media File Format, ISOBMFF)에 기초하여 컨테이너 파일을 형성하는 수단을 포함하되,
상기 컨테이너 파일은,
적어도 두개의 미디어 데이터 박스 - 적어도 하나의 미디어 데이터 박스는 상기 적어도 하나의 미디어 데이터 박스를 상기 컨테이너 파일 내의 다른 미디어 데이터 박스로부터 식별하는 미디어 데이터 박스 식별자의 값을 포함하도록 확장됨 - 와,
데이터 필드로서 상기 미디어 데이터 박스 식별자의 값을 갖는 데이터 엔트리 박스를 포함하는 데이터 참조 박스를 포함함으로써 상기 적어도 하나의 미디어 데이터 박스와 연관되는 적어도 하나의 트랙과,
상기 적어도 하나의 미디어 데이터 박스 내의 적어도 하나의 미디어 샘플의 위치를 지시하는 오프셋을 포함하는
장치.
- 제 6 항에 있어서,
상기 오프셋은 상기 컨테이너 파일 내의 상기 적어도 하나의 미디어 데이터 박스의 위치의 시작에 상대적인
장치.
- 제 6 항 또는 제 7 항에 있어서,
상기 오프셋은 상기 데이터 참조 박스 내에 포함되어 있는 상기 데이터 엔트리 박스를 지시하는 데이터 참조 인덱스를 통해 상기 트랙의 샘플 엔트리와 연관되는
장치.
- 제 8 항에 있어서,
상기 샘플 엔트리는 상기 ISOBMFF에 기초하여 상기 트랙의 샘플 설명 박스 (a sample description box)에 포함되는
장치.
- 제 6 항 또는 제 7 항에 있어서,
상기 미디어 데이터 박스 식별자는 32 비트 숫자를 포함하는
장치.
- 국제 표준 기구 기본 미디어 파일 포맷(International Standards Organization Base Media File Format, ISOBMFF)에 기초한 컨테이너 파일을 수신하는 단계 - 상기 컨테이너 파일은,
적어도 두개의 미디어 데이터 박스 - 적어도 하나의 미디어 데이터 박스는 상기 적어도 하나의 미디어 데이터 박스를 상기 컨테이너 파일 내의 다른 미디어 데이터 박스로부터 식별하는 미디어 데이터 박스 식별자의 값을 포함하도록 확장됨 - 와,
데이터 필드로서 상기 미디어 데이터 박스 식별자의 값을 갖는 데이터 엔트리 박스를 포함하는 데이터 참조 박스를 포함함으로써 상기 적어도 하나의 미디어 데이터 박스와 연관되는 적어도 하나의 트랙과,
상기 적어도 하나의 미디어 데이터 박스 내의 적어도 하나의 미디어 샘플의 위치를 지시하는 오프셋
을 포함함 - 와,
상기 데이터 엔트리 박스 내의 상기 미디어 데이터 박스 식별자의 값을 확인함으로써 상기 적어도 하나의 미디어 샘플이 상기 적어도 하나의 미디어 데이터 박스에 포함되어 있다고 판정하는 단계를 포함하는
방법.
- 국제 표준 기구 기본 미디어 파일 포맷(International Standards Organization Base Media File Format, ISOBMFF)에 기초하여 컨테이너 파일을 형성하는 단계를 포함하되,
상기 컨테이너 파일은,
적어도 두개의 미디어 데이터 박스 - 적어도 하나의 미디어 데이터 박스는 상기 적어도 하나의 미디어 데이터 박스를 상기 컨테이너 파일 내의 다른 미디어 데이터 박스로부터 식별하는 미디어 데이터 박스 식별자의 값을 포함하도록 확장됨 - 와,
데이터 필드로서 상기 미디어 데이터 박스 식별자의 값을 갖는 데이터 엔트리 박스를 포함하는 데이터 참조 박스를 포함함으로써 상기 적어도 하나의 미디어 데이터 박스와 연관되는 적어도 하나의 트랙과,
상기 적어도 하나의 미디어 데이터 박스 내의 적어도 하나의 미디어 샘플의 위치를 지시하는 오프셋을 포함하는
방법. - 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/FI2016/050096 WO2017140939A1 (en) | 2016-02-16 | 2016-02-16 | Media encapsulating and decapsulating |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20180112026A KR20180112026A (ko) | 2018-10-11 |
| KR102125162B1 true KR102125162B1 (ko) | 2020-06-22 |
Family
ID=59625627
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020187026684A KR102125162B1 (ko) | 2016-02-16 | 2016-02-16 | 미디어 캡슐화 및 캡슐 해제 기법 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US10631069B2 (ko) |
| EP (2) | EP3417633A4 (ko) |
| KR (1) | KR102125162B1 (ko) |
| CN (1) | CN109076261A (ko) |
| MX (1) | MX2018009876A (ko) |
| WO (1) | WO2017140939A1 (ko) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2560921B (en) | 2017-03-27 | 2020-04-08 | Canon Kk | Method and apparatus for encoding media data comprising generated content |
| US10887645B2 (en) | 2017-07-13 | 2021-01-05 | Qualcomm Incorporated | Processing media data using file tracks for web content |
| US11172268B2 (en) * | 2017-07-31 | 2021-11-09 | Samsung Electronics Co., Ltd. | Method and apparatus for providing broadcast service |
| GB201721847D0 (en) * | 2017-12-22 | 2018-02-07 | Telecom Paris Tech | Priority map for media files |
| US11321516B2 (en) * | 2018-01-19 | 2022-05-03 | Qualcomm Incorporated | Processing dynamic web content of an ISO BMFF web resource track |
| US11711526B2 (en) * | 2018-04-05 | 2023-07-25 | Canon Kabushiki Kaisha | Method and apparatus for encapsulating images or sequences of images with proprietary information in a file |
| US10749958B2 (en) | 2018-04-24 | 2020-08-18 | Western Digital Technologies, Inc. | Reduced storage of metadata in a distributed encoded storage system |
| US10474368B1 (en) | 2018-04-24 | 2019-11-12 | Western Digital Technologies, Inc | Fast read operation utilizing reduced storage of metadata in a distributed encoded storage system |
| US10216424B1 (en) | 2018-04-25 | 2019-02-26 | Western Digital Technologies, Inc. | Staging of write operations for container-based storage for sequential media |
| CN110545466B (zh) * | 2018-05-29 | 2021-07-06 | 北京字节跳动网络技术有限公司 | 基于网页的媒体文件的播放方法、装置及存储介质 |
| CN110545469B (zh) * | 2018-05-29 | 2021-07-06 | 北京字节跳动网络技术有限公司 | 非流媒体文件的网页播放方法、装置及存储介质 |
| US11019123B2 (en) * | 2018-06-22 | 2021-05-25 | International Business Machines Corporation | Multi-bitrate component sharding |
| WO2020008115A1 (en) * | 2018-07-06 | 2020-01-09 | Nokia Technologies Oy | An apparatus, a method and a computer program for video coding and decoding |
| JP7267703B2 (ja) * | 2018-09-27 | 2023-05-02 | キヤノン株式会社 | 画像データ格納装置、画像データ格納方法、及び、プログラム |
| GB2582014A (en) * | 2019-03-08 | 2020-09-09 | Canon Kk | Method, device, and computer program for optimizing transmission of portions of encapsulated media content |
| GB2582155B (en) * | 2019-03-12 | 2023-12-27 | Canon Kk | Method, device, and computer program for signaling available portions of encapsulated media content |
| WO2020183053A1 (en) | 2019-03-14 | 2020-09-17 | Nokia Technologies Oy | Method and apparatus for late binding in media content |
| US11457231B2 (en) | 2019-03-15 | 2022-09-27 | Mediatek Singapore Pte. Ltd. | Methods and apparatus for signaling spatial relationships for point cloud multimedia data tracks |
| US11245926B2 (en) * | 2019-03-19 | 2022-02-08 | Mediatek Singapore Pte. Ltd. | Methods and apparatus for track derivation for immersive media data tracks |
| US20220253476A1 (en) | 2019-06-18 | 2022-08-11 | Sony Group Corporation | File processing device, file processing method, and program |
| WO2020255757A1 (ja) * | 2019-06-18 | 2020-12-24 | ソニー株式会社 | ファイル処理装置、ファイル処理方法、及び、プログラム |
| GB2585052B (en) * | 2019-06-26 | 2023-07-26 | Canon Kk | Method and apparatus for encapsulating panorama images in a file |
| JP7442302B2 (ja) * | 2019-11-22 | 2024-03-04 | キヤノン株式会社 | データ処理装置およびその制御方法、プログラム |
| CN113364728B (zh) * | 2020-03-03 | 2023-04-14 | 腾讯美国有限责任公司 | 媒体内容接收方法、装置、存储介质和计算机设备 |
| WO2021182090A1 (ja) * | 2020-03-09 | 2021-09-16 | ソニーグループ株式会社 | ファイル処理装置、ファイル処理方法、及び、プログラム |
| US11463746B2 (en) * | 2021-02-12 | 2022-10-04 | Netflix, Inc. | Techniques for composite media storage and retrieval |
| GB2611105B (en) * | 2021-09-28 | 2024-01-17 | Canon Kk | Method, device and computer program for optimizing encapsulation of redundant portions of metadata in fragments of media file |
| US20230297539A1 (en) * | 2022-03-18 | 2023-09-21 | Streaming Global, Inc. | Portable cloud services for media and data distribution |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090119594A1 (en) * | 2007-10-29 | 2009-05-07 | Nokia Corporation | Fast and editing-friendly sample association method for multimedia file formats |
| US20150193494A1 (en) * | 2014-01-07 | 2015-07-09 | Nokia Corporation | Media encapsulating and decapsulating |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100353450C (zh) * | 2003-01-10 | 2007-12-05 | 华为技术有限公司 | 一种多媒体数据的处理方法 |
| US9432433B2 (en) * | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
| US9521469B2 (en) * | 2013-04-19 | 2016-12-13 | Futurewei Technologies, Inc. | Carriage of quality information of content in media formats |
| US20110096828A1 (en) * | 2009-09-22 | 2011-04-28 | Qualcomm Incorporated | Enhanced block-request streaming using scalable encoding |
| EP2580919A1 (en) | 2010-06-14 | 2013-04-17 | Thomson Licensing | Method and apparatus for encapsulating coded multi-component video |
| KR101768222B1 (ko) * | 2010-07-20 | 2017-08-16 | 삼성전자주식회사 | 적응적 스트리밍 방식의 컨텐트 송수신 방법 및 장치 |
| WO2012032502A1 (en) * | 2010-09-10 | 2012-03-15 | Nokia Corporation | A method and apparatus for adaptive streaming |
| US11025962B2 (en) | 2011-02-28 | 2021-06-01 | Adobe Inc. | System and method for low-latency content streaming |
| US9843844B2 (en) * | 2011-10-05 | 2017-12-12 | Qualcomm Incorporated | Network streaming of media data |
| US8856218B1 (en) * | 2011-12-13 | 2014-10-07 | Google Inc. | Modified media download with index adjustment |
| CN102611690A (zh) * | 2011-12-22 | 2012-07-25 | 南京邮电大学 | 一种基于超文本传输协议流化的容器格式转化方法 |
| US9454995B2 (en) * | 2012-11-30 | 2016-09-27 | Samsung Electronics Co., Ltd. | Information storage medium storing content, content providing method, content reproducing method and apparatus therefor |
| GB2516825B (en) * | 2013-07-23 | 2015-11-25 | Canon Kk | Method, device, and computer program for encapsulating partitioned timed media data using a generic signaling for coding dependencies |
| JP6598109B2 (ja) * | 2014-12-25 | 2019-10-30 | パナソニックＩｐマネジメント株式会社 | 映像受信方法及び端末装置 |
| WO2018070092A1 (ja) * | 2016-10-11 | 2018-04-19 | ソニー株式会社 | 情報提供装置と情報提供方法および情報再生装置と情報再生方法 |
-
2016
- 2016-02-16 KR KR1020187026684A patent/KR102125162B1/ko active IP Right Grant
- 2016-02-16 US US16/077,576 patent/US10631069B2/en active Active
- 2016-02-16 WO PCT/FI2016/050096 patent/WO2017140939A1/en active Application Filing
- 2016-02-16 EP EP16890418.3A patent/EP3417633A4/en not_active Withdrawn
- 2016-02-16 EP EP20166101.4A patent/EP3703384B1/en active Active
- 2016-02-16 MX MX2018009876A patent/MX2018009876A/es unknown
- 2016-02-16 CN CN201680084597.XA patent/CN109076261A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090119594A1 (en) * | 2007-10-29 | 2009-05-07 | Nokia Corporation | Fast and editing-friendly sample association method for multimedia file formats |
| US20150193494A1 (en) * | 2014-01-07 | 2015-07-09 | Nokia Corporation | Media encapsulating and decapsulating |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2017140939A1 (en) | 2017-08-24 |
| CN109076261A (zh) | 2018-12-21 |
| EP3703384A1 (en) | 2020-09-02 |
| EP3703384B1 (en) | 2024-02-14 |
| US20190052937A1 (en) | 2019-02-14 |
| MX2018009876A (es) | 2018-11-09 |
| CN112383540A (zh) | 2021-02-19 |
| EP3417633A4 (en) | 2019-10-23 |
| EP3417633A1 (en) | 2018-12-26 |
| US10631069B2 (en) | 2020-04-21 |
| KR20180112026A (ko) | 2018-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102125162B1 (ko) | 미디어 캡슐화 및 캡슐 해제 기법 | |
| TWI774744B (zh) | 在使用mime類型參數之網路視頻串流中發信重要視頻資訊 | |
| US9820015B2 (en) | Media encapsulating and decapsulating | |
| KR102303582B1 (ko) | 웹 콘텐츠에 대한 파일 트랙들을 사용하여 미디어 데이터를 프로세싱 | |
| US20120233345A1 (en) | Method and apparatus for adaptive streaming | |
| CN110832872B (zh) | 使用用于文件格式方框的通用描述符处理媒体数据 | |
| CN111602406B (zh) | 一种处理媒体数据的方法、装置和计算机可读存储媒体 | |
| JP6903688B2 (ja) | サンプルエントリーおよびランダムアクセス | |
| WO2016097482A1 (en) | Media encapsulating and decapsulating | |
| CN110870323B (zh) | 使用全向媒体格式处理媒体数据 | |
| TW201909647A (zh) | 增強區域取向包封及視埠獨立高效視頻寫碼媒體資料檔 | |
| EP4068781A1 (en) | File format with identified media data box mapping with track fragment box | |
| CN112383540B (en) | Media encapsulation and decapsulation |
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 |