KR20200026891A

KR20200026891A - 웹 콘텐츠에 대한 파일 트랙들을 사용하여 미디어 데이터를 프로세싱

Info

Publication number: KR20200026891A
Application number: KR1020207000924A
Authority: KR
Inventors: 토마스 슈토크하머; 예쿠이 왕; 기리다르 다티 만디암; 찰스 눙 로; 와카르 지아
Original assignee: 퀄컴 인코포레이티드
Priority date: 2017-07-13
Filing date: 2018-07-13
Publication date: 2020-03-11
Also published as: WO2019014574A1; SG11201911715XA; AU2018300191A1; EP3652919A1; CN110870282B; CN110870282A; BR112020000307A2; TWI727186B; US10887645B2; US20190020915A1; KR102303582B1; TW201909626A

Abstract

일 예에서, 미디어 데이터를 취출하기 위한 디바이스는 미디어 데이터를 저장하도록 구성된 메모리, 및 회로부에 구현된 하나 이상의 프로세서들을 포함하며, 상기 하나 이상의 프로세서들은, 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하고, 그리고 미디어 데이터 및 웹 컨텐츠를 제시하도록 구성되며, 상기 하나 이상의 프로세서들은 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하도록 구성된다.

Description

웹 콘텐츠에 대한 파일 트랙들을 사용하여 미디어 데이터를 프로세싱

본 출원은 2017 년 7 월 13 일자로 출원된 미국 가출원 제 62/532,237 호 및 2018 년 7 월 12 일자로 출원된 미국 출원 제 16/033,999 호의 이점을 청구하며, 이들의 전체 내용들은 주장하며 참조에 의해 통합된다.

본 개시는 인코딩된 비디오 데이터의 저장 및 전송에 관한 것이다.

디지털 비디오 능력들은 디지털 텔레비전들, 디지털 직접 브로드캐스트 시스템들, 무선 브로드캐스트 시스템들, 개인 휴대정보 단말기 (PDA) 들, 랩탑 또는 데스크탑 컴퓨터들, 디지털 카메라들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게이밍 디바이스들, 비디오 게임 콘솔들, 셀룰러 또는 위성 무선 전화기들, 원격 화상회의 디바이스들 등을 포함한, 광범위한 디바이스들에 포함될 수 있다. 디지털 비디오 디바이스들은, 디지털 비디오 정보를 보다 효율적으로 송신 및 수신하기 위해, MPEG-2, MPEG-4, ITU-T H.263 또는 ITU-T H.264/MPEG-4, Part 10, AVC (Advanced Video Coding), (고 효율 비디오 코딩 (High Efficiency Video Coding; HEVC) 으로도 지칭되는) ITU-T H.265) 에 의해 정의되는 표준들, 및 그러한 표준들의 확장들에 설명된 것들과 같은 비디오 압축 기법들을 구현한다.

비디오 데이터가 인코딩된 후에, 비디오 데이터는 송신 또는 저장을 위해 패킷화될 수도 있다. 비디오 데이터는 ISO (International Organization for Standardization) 베이스 미디어 파일 포맷 및 그 확장들, 예컨대 AVC 와 같은 임의의 다양한 표준들에 부합하는 비디오 파일로 어셈블링될 수도 있다.

일반적으로, 본 개시는 프리젠테이션 동기화된 웹 컨텐츠를 운반하는 하나 이상의 트랙들을 갖는 파일 포맷에 포함된 미디어 데이터를 프로세싱하기 위한 기술들을 설명한다. 즉, 웹 컨텐츠는 미디어 데이터와 시간 동기화된 방식으로 제시되어야 한다. 예를 들어, 상호작용 웹 컨텐츠 엘리먼트들은 비디오 데이터로 오버레이된 특정 시간에 제시될 수도 있다. 파일은 미디어 데이터, 웹 콘텐츠, 및 웹 콘텐츠와 미디어 데이터 간의 동기화를 나타내는 데이터를 포함할 수도 있다. 이러한 방식으로, 클라이언트 디바이스는 오직 단일 파일만을 취출할 수 있지만, 취출된 파일의 오직 컨텐츠만을 사용하여 미디어 데이터 및 웹 컨텐츠의 프리젠테이션을 시간 동기화할 수 있다.

일 예에서, 미디어 데이터를 취출하는 방법은 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하는 단계, 및 미디어 데이터 및 웹 컨텐츠를 제시하는 단계를 포함하며, 상기 미디어 데이터 및 웹 컨텐츠를 제시하는 단계는 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하는 단계를 포함한다.

다른 예에서, 미디어 데이터를 취출하기 위한 디바이스는 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하는 수단, 및 미디어 데이터 및 웹 컨텐츠를 제시하는 수단을 포함하며, 상기 미디어 데이터 및 웹 컨텐츠를 제시하는 수단은 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하는 수단을 포함한다.

다른 예에서, 컴퓨터 판독가능한 저장 매체는 명령들을 저장하고, 상기 명령들은, 실행될 경우, 프로세서로 하여금, 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하게 하고, 그리고 미디어 데이터 및 웹 컨텐츠를 제시하게 하며, 상기 프로세서로 하여금 미디어 데이터 및 웹 컨텐츠를 제시하게 하는 명령들은 상기 프로세서로 하여금 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하게 하는 명령들을 포함한다.

하나 이상의 예들의 상세들이 첨부 도면들 및 하기의 설명에 개시된다. 다른 특징, 목적 및 이점들은 상세한 설명 및 도면, 그리고 청구항들로부터 분명해질 것이다.

도 1 은 네트워크를 통해 미디어 데이터를 스트리밍하기 위한 기술들을 구현하는 예시적인 시스템을 도시하는 블록도이다.
도 2 는 취출 유닛의 컴포넌트들의 예시적인 세트를 도시하는 블록도이다.
도 3 은 본 개시의 기술에 따른 예시적인 웹 상호작용 트랙을 도시한 개념도이다.
도 4 는 예시적인 멀티미디어 콘텐츠의 엘리먼트들을 도시하는 개념도이다.
도 5 는 예시적인 비디오 파일의 엘리먼트들을 도시하는 블록도이다.
도 6 은 본 개시의 기술에 따른 예시적인 수신기 데이터 프로세싱 모델을 도시하는 개념도이다.
도 7 은 본 개시의 기술에 따른 예시적인 프로세싱 모델을 도시하는 개념도이다.
도 8 은 본 개시의 기술에 따른 예시적인 이벤트 기반 모델을 도시하는 개념도이다.
도 9 는 본 개시의 기술들에 따라 미디어 데이터 및 동기화된 웹 컨텐츠를 취출하고 프로세싱하기 위한 예시적인 방법을 도시하는 흐름도이다.

일반적으로, 본 개시의 기술은 미디어 데이터 및 시간 동기화된 웹 컨텐츠 양자를 포함하는 미디어 파일을 사용하는 것에 관한 것이다. 예를 들어, 웹 컨텐츠는 미디어 데이터 (예를 들어, 오디오 데이터 및/또는 비디오 데이터) 와 시간 동기화 방식으로 제시될 수도 있다. 예를 들어, 특정 웹 컨텐츠는 오디오 데이터의 특정 오디오 샘플이 재생되는 것과 동시에 또는 비디오 데이터의 특정 이미지 또는 이미지 시퀀스가 디스플레이될 때 제시될 수도 있다. 본 개시는 클라이언트 디바이스가 그러한 미디어 파일을 프로세싱하고 시간 동기화 방식으로 미디어 데이터 및 웹 컨텐츠 양자를 제시할 수 있는 기술들을 설명한다.

예를 들어, 클라이언트 디바이스는 웹 소켓 서버, HTTP 서버 캐시, 및 HTML-5 프로세서를 포함할 수도 있다. HTML-5 프로세서는 WebSocket API (application programming interface) 를 통해 웹 소켓 서버로 그리고 XHR (XML HTTP Request) 접속을 통해 HTTP 서버 캐시에 통신가능하게 커플링될 수도 있다. 다른 예로서, 클라이언트 디바이스는 웹 컨텐츠 트랙 데이터를 해석하기 위한 인터프리터를 포함하고, 미디어 디코더로부터의 시간을 디코딩/디스플레이하고 그에 따라 웹 컨텐츠의 프리젠테이션을 조정할 수도 있다.

본 개시의 기술들은 ISO 기본 미디어 파일 포맷 (BMFF), SVC (Scalable Video Coding) 파일 포맷, AVC (Advanced Video Coding) 파일 포맷, 3GPP (Third Generation Partnership Project) 파일 포맷, 및/또는 MVC (Multiview Video Coding) 파일 포맷, 또는 다른 유사한 비디오 파일 포맷들 중 임의의 파일 포맷에 따라 캡슐화된 비디오 데이터를 따르는 비디오 파일들에 적용될 수도 있다.

DASH (Dynamic Adaptive Streaming over HTTP) 와 같은 HTTP 스트리밍에서, 자주 사용되는 동작들은 HEAD, GET 및 부분 GET 을 포함한다. HEAD 동작은 주어진 URL (uniform resource locator) 또는 URN (uniform resource name) 에 연관된 파일의 헤더를, 그 URL 또는 URN 과 연관된 페이로드를 취출하는 일 없이, 취출한다. GET 동작은 주어진 URL 또는 URN 과 연관된 전체 파일을 취출한다. 부분 GET 동작은 입력 파라미터로서 바이트 범위를 수신하고 파일의 연속적인 수의 바이트들을 취출하며, 여기서, 바이트들의 수는 수신된 바이트 범위에 대응한다. 따라서, 무비 프래그먼트들은 HTTP 스트리밍을 위해 제공될 수도 있는데, 왜냐하면 부분 GET 동작이 하나 이상의 개별 무비 프래그먼트들을 얻을 수 있기 때문이다. 무비 프래그먼트에 있어서, 상이한 트랙들의 수개의 트랙 프래그먼트들이 존재할 수 있다. HTTP 스트리밍에 있어서, 미디어 프리젠테이션은, 클라이언트에 액세스가능한 데이터의 구조화된 컬렉션일 수도 있다. 클라이언트는, 스트리밍 서비스를 사용자에게 제시하기 위해 미디어 데이터 정보를 요청 및 다운로딩할 수도 있다.

HTTP 스트리밍을 사용하여 3GPP 데이터를 스트리밍하는 예에 있어서, 멀티미디어 컨텐츠의 비디오 및/또는 오디오 데이터에 대한 다중의 레프리젠테이션들이 존재할 수도 있다. 하기에서 설명되는 바와 같이, 상이한 레프리젠테이션들은 상이한 코딩 특성들 (예컨대, 비디오 코딩 표준의 상이한 프로파일들 또는 레벨들), (멀티뷰 및/또는 스케일가능 확장들과 같은) 상이한 코딩 표준들 또는 코딩 표준들의 확장들, 또는 상이한 비트레이트들에 대응할 수도 있다. 그러한 레프리젠테이션들의 매니페스트는 미디어 프리젠테이션 디스크립션 (MPD) 데이터 구조에서 정의될 수도 있다. 미디어 프리젠테이션은 HTTP 스트리밍 클라이언트 디바이스에 액세스가능한 데이터의 구조화된 컬렉션에 대응할 수도 있다. HTTP 스트리밍 클라이언트 디바이스는 스트리밍 서비스를 클라이언트 디바이스의 사용자에게 제시하기 위해 미디어 데이터 정보를 요청 및 다운로딩할 수도 있다. 미디어 프리젠테이션은, MPD 의 업데이트들을 포함할 수도 있는 MPD 데이터 구조에서 기술될 수도 있다.

미디어 프리젠테이션은 하나 이상의 주기(Period)들의 시퀀스를 포함할 수도 있다. 각각의 주기는 다음 주기의 시작까지, 또는 마지막 주기의 경우에는 미디어 프리젠테이션의 끝까지 연장할 수도 있다. 각각의 주기는 동일한 미디어 컨텐츠에 대한 하나 이상의 레프리젠테이션들을 포함할 수도 있다. 레프리젠테이션은 오디오, 비디오, 타이밍된 (timed) 텍스트, 또는 다른 그러한 데이터의 다수의 대안적 인코딩된 버전들 중 하나일 수도 있다. 레프리젠테이션들은 인코딩 타입들에 의해, 예컨대, 비디오 데이터에 대한 비트레이트, 해상도, 및/또는 코덱과, 오디오 데이터에 대한 비트레이트, 언어, 및/또는 코덱에 의해 상이할 수도 있다. 용어 '레프리젠테이션' 은, 멀티미디어 컨텐츠의 특정 주기에 대응하고 특정 방식으로 인코딩되는 인코딩된 오디오 또는 비디오 데이터의 섹션을 지칭하는데 사용될 수도 있다.

특정 주기의 레프리젠테이션들은, 레프리젠테이션들이 속하는 적응 세트를 나타내는 MPD 에서의 속성에 의해 표시된 그룹에 할당될 수도 있다. 동일한 적응 세트에서의 레프리젠테이션들은 일반적으로, 클라이언트 디바이스가, 예컨대, 대역폭 적응을 수행하기 위해, 이들 레프리젠테이션들 사이를 동적으로 그리고 심리스로 (seamlessly) 스위칭할 수 있다는 점에서, 서로에 대한 대안들로서 고려된다. 예를 들어, 특정 주기 동안의 비디오 데이터의 각각의 레프리젠테이션은 동일한 적응 세트에 할당될 수도 있어서, 그 레프리젠테이션들 중 임의의 레프리젠테이션이 대응하는 주기 동안의 멀티미디어 컨텐츠의 비디오 데이터 또는 오디오 데이터와 같은 미디어 데이터를 제시하기 위한 디코딩을 위해 선택될 수도 있다. 일 주기 내의 미디어 컨텐츠는, 일부 예들에 있어서, 존재한다면, 그룹 0 으로부터의 하나의 레프리젠테이션, 또는 각각의 비-제로 그룹으로부터의 많아야 하나의 레프리젠테이션의 조합 중 어느 하나에 의해 나타낼 수도 있다. 주기의 각각의 레프리젠테이션에 대한 타이밍 데이터는 그 주기의 시작 시간과 관련하여 표현될 수도 있다.

레프리젠테이션은 하나 이상의 세그먼트들을 포함할 수도 있다. 각각의 레프리젠테이션은 초기화 세그먼트를 포함할 수도 있거나, 또는 레프리젠테이션의 각각의 세그먼트는 자체 초기화될 수도 있다. 존재하는 경우, 초기화 세그먼트는 레프리젠테이션에 액세스하기 위한 초기화 정보를 포함할 수도 있다. 일반적으로, 초기화 세그먼트는 미디어 데이터를 포함하지 않는다. 세그먼트는 URL (uniform resource locator), URN (uniform resource name), 또는 URI (uniform resource identifier) 와 같은 식별자에 의해 고유하게 참조될 수도 있다. MPD 는 각각의 세그먼트에 대해 식별자들을 제공할 수도 있다. 일부 예들에서, MPD 는 URL, URN, 또는 URI 에 의해 액세스가능한 파일 내의 세그먼트를 위한 데이터에 대응할 수도 있는 범위 속성의 형태로 바이트 범위들을 제공할 수도 있다.

상이한 레프리젠테이션들이 상이한 타입들의 미디어 데이터에 대한 실질적으로 동시 취출을 위해 선택될 수도 있다. 예를 들어, 클라이언트 디바이스는, 세그먼트들을 취출할 오디오 레프리젠테이션, 비디오 레프리젠테이션, 및 타이밍된 텍스트 레프리젠테이션을 선택할 수도 있다. 일부 예들에 있어서, 클라이언트 디바이스는 대역폭 적응을 수행하기 위한 특정 적응 세트들을 선택할 수도 있다. 즉, 클라이언트 디바이스는 비디오 레프리젠테이션들을 포함하는 적응 세트, 오디오 레프리젠테이션들을 포함하는 적응 세트, 및/또는 타이밍된 텍스트를 포함하는 적응 세트를 선택할 수도 있다. 대안적으로, 클라이언트 디바이스는 특정 타입들의 미디어 (예컨대, 비디오) 를 위한 적응 세트들을 선택하고, 다른 타입들의 미디어 (예컨대, 오디오 및/또는 타이밍된 텍스트) 를 위한 레프리젠테이션들을 직접 선택할 수도 있다.

본 개시의 기술들은 다양한 사용 케이스들에서 적용될 수도 있다. 예를 들어, 본 개시는 오디오/비디오 컨텐츠 및 웹 데이터를 패키징하여 일반적인 웹 브라우저로부터의 상호작용식 재생이 HTML 로직에 대한 특정 수정 없이 (예를 들어, 파일 로딩, 트랙 핸들링, 등을 위한 특정 코드 없이) 달성될 수 있도록 하는 것이 가능해야만 하는 것을 인식한다. 특히, MP4 로 패키징된 상호작용 애플리케이션에 대한 액세스는 브라우저에 투명해야 한다.

오디오/비디오 파일을 소비할 때의 하나의 일반적인 사용 케이스는 파일 타임라인에서 특정 위치를 찾는 것이다. 모든 비디오/오디오 프레임이 개별적으로 디코딩가능할 수도 있는 것은 아니므로, 파일 포맷은 통상적으로 인트라-예측된 비디오 프레임과 같은 랜덤 액세스 포인트를 식별한다. 파일이 웹 페이지 변경 또는 업데이트 (레이아웃, 컨텐츠 등) 를 위한 추가 데이터를 포함하는 경우, 파일에서 소정 시간을 찾는 것은 가능하면 페이지 변경 내로의 랜덤 액세스 포인트로, 정확한 페이지 렌더링을 생성해야 한다.

일반적으로, 상이한 타입의 클라이언트들 (부분 웹 엔진 기능성을 갖춘 완전한 브라우저 기반의 전용 미디어 클라이언트 등) 및 서비스들 (주로 오버레이되는 A/V, 웹 기반 미디어 소비) 이 존재하며, 상이한 타입의 클라이언트들에게 서비스를 제공하는 것이 바람직할 수도 있다. 일부 클라이언트는 기본 기능만 지원하는 반면, 다른 클라이언트는 고급 기능을 지원할 수도 있다.

서비스 제공자의 주요 요건은, 자체적으로 애플리케이션 환경을 정의하지 않고, 미디어 시간 동기화된 그래픽들, 오버레이, 상호작용 데이터, 임의의 타입의 웹 데이터 등을 전송하는 능력이다. LASER, DIMS 또는 FLASH 의 재실행 (redo) 은 고려되지 않는다.

파일 포맷 트랙 레벨에서, 중요한 양태들은 웹 데이터의 캐리지 (carriage) 및 이들의 동기화, 상호동작가능한 구현을 위한 데이터의 신택스 및 시맨틱스를 포함할 수도 있다.

다양한 기존 기술이 본 개시의 기술과 관련된 것으로 간주된다. 예를 들어, DASH 이벤트는 동기화된 데이터를 운반하기 위한 하나의 옵션을 나타낸다. 이러한 DASH 이벤트는 대역 내일 수도 있거나 또는 MPD (Media Presentation Description) 이벤트 스트림의 부분을 형성할 수도 있다. 브라우저에서 지원되는 일반적인 구현들은 애플리케이션 개입을 요구할 수도 있다. 예를 들어, MPD 운반된 이벤트 스트림은 애플리케이션 또는 DASH 클라이언트가 MPD 로부터 이러한 이벤트를 파싱한 후에 애플리케이션이 이러한 이벤트를 핸들링하는 것을 요구할 수도 있다. 'emsg' 캐리지 방법은, 많은 미디어 플레이어 구현들이 (핸들링을 위해 데이터를 애플리케이션에 전달하는 것과는 반대로) 이 박스를 완전히 무시한다는 점에서 문제가 될 수도 있다. 추가로, DASH 이벤트는 통상적으로 DASH 클라이언트에 의해 파싱되고 프로세싱되고, 따라서 DASH 이벤트는 통상적으로 ISO BMFF (Base Media File Format) 파일에 적절히 저장될 수 없다. 또한, DASH 이벤트는 통상적으로 오직 캐리지만을 제공하지만, 페이로드의 프로세싱 모델을 설명하지는 않는다.

HTML-5 는 다른 예시적인 기술이다. 특히, 비디오 및 오디오 리소스들이 또한 사용되는 경우, HTML 페이지에서 상호작용 (interactivity) 및 역동성 (dynamicity) 을 제공하는 적어도 2 개의 옵션이 있다. 페이지 변경은 메인 HTML 리소스의 부분으로서 (예를 들면, 임베디드 JavaScript 의 부분으로서) 제공될 수도 있으며, 이 경우 오디오/비디오에 대한 동기화는 JavaScript 에 의해 특별히 핸들링된다. 대안적으로, 페이지 변경은 추가적인 타이밍된 리소스의 부분으로서 제공될 수도 있으며, 이는 브라우저에 의해 직접 동기화된다. 제 1 접근방식은 점진적 파서들을 포함하며, 이 경우 전달은 이벤트 실행을 스케줄링할 수 있지만, 미디어에 오직 조밀하게 동기화된다.

제 2 접근방식은 텍스트 트랙 (TextTrack) 엘리먼트들을 포함하며, 이 경우 텍스트 트랙의 컨텐츠는 브라우저 의해 동기식으로 및 자연적으로 디스플레이될 수 있다. 숨겨진 모드의 텍스트 트랙은 브라우저에 의해 프로세싱되지만 (즉, 트랙의 컨텐츠가 JavaScript 에 노출되고, 이벤트는 사용될 경우 트리거된다), 그 컨텐츠는 브라우저에 의해 스크린에 직접 렌더링되지 않는다. 컨텐츠는 JavaScript 이벤트 핸들러에 의해 프로세싱된다. "메타 데이터" 종류의 텍스트 트랙들은 웹 애플리케이션에 모든 종류의 데이터를 제공하는데 사용되는 범용 트랙이다. 메타 데이터 트랙은 브라우저가 이러한 트랙을 "숨겨짐" 으로 처리하므로, 디스플레이할 준비가 된 데이터를 제공하도록 의도되지 않는다. 메타 데이터 트랙 컨텐츠는 페이지에서의 JavaScript 코드로 프로세싱되도록 의도되며, 그 결과는 페이지에 디스플레이될 수도 있다. HTML-5 는 일부 타입의 ISOBMFF 트랙의 TextTrack 개념, 특히 "메타 데이터" 역할의 트랙으로의 기본 매핑을 정의한다. 이 작업은 www.w3.org/community/inbandtracks/ 에 설명된 바와 같은, W3C Media Resources In-Band Tracks Community Group 에 의해 리파이닝되고 있다.

파일 포맷 기술은 또한 관련있는 것으로 간주된다. ISO/IEC 14496-12 는 예를 들어, ISOBMFF 에 대하여, 트랙을 사용하여 타이밍된 데이터의 저장을 정의한다. ISO/IEC 14496-12 에서의 ISOBMFF 는 "트랙 핸들러" 로 불리는 제 1 의 4 문자 코드 및 "샘플 디스크립션 포맷" 으로 불리는 제 2 의 4 문자 코드를 사용하여, 여러 타입의 트랙을 정의한다. 트랙 핸들러는 트랙과 연관된, 예측된 일반적인 프로세싱을 식별한다 (예를 들어, 오디오 프로세싱 대 텍스트 프로세싱 대 비디오 프로세싱 ...). 샘플 디스크립션 포맷은 트랙에서 미디어 샘플의 특정 포맷을 식별한다. '메타' 는 연관된 디코더가 가능하게는 디스플레이에 대하여, 애플리케이션에 의해 직접 디스플레이되지만 프로세싱되도록 의도되지 않는 데이터를 프로세싱할 것임을 표시한다.

ISOBMFF '메타' 트랙 핸들러는 트랙 컨텐츠가 직접 디스플레이를 위해 의도되지 않는 것을 표시한다. 이는 또한 HTML 5 TextTrack API 의 컨텐츠에서도 사용될 수 있다. 핸들러 '메타' 의 트랙에 사용가능한 몇 가지 샘플 디스크립션 포맷들이 있다. ISOBMFF 에 따라, 데이터가 이진일 때, URIMetadataSampleEntry (샘플 디스크립션 포맷 'urim' 으로 식별됨) 가 사용된다. URI 는 각 샘플의 포맷을 식별하고, 일부 초기화 정보가 제공될 수 있다.

입력 데이터가 텍스트 기반이 아닌 이진 데이터인 경우, URIMetadataSampleEntry 가 웹 상호작용을 위해 사용될 수 있다. 이 포맷을 사용하는 사양은 URI 값, 및 연관된 이진 샘플 포맷 및 초기화 포맷을 정의해야할 것이다. 또한 어떤 샘플들이 동기화 샘플인지를 표시해야할 것이다. HTML-5 환경에서, TextTrack 인터페이스를 통해 소비되는 경우, 이러한 트랙은 통상적으로 DataCue들을 갖는 TextTrack 으로 매핑될 것이다. 이진 큐를 프로세싱하는데 필요한 HTML 페이지와 특히 JavaScript 는 가능하면 간단한 텍스트 트랙 접근방식을 사용하거나 또는 '메타' 박스에서의 아이템으로 트랙 외부로 전달된다.

ISOBMFF 는 "메타" 박스를 정의하고, 이는 가능하게는 오디오 및 비디오 시퀀스와 함께, 박스 구조의 파일들에 타이밍되지 않은 (untimed) 데이터를 저장하는 것을 허용한다. 따라서, 상호작용 데이터가 타이밍되지 않거나 또는 타이밍된 데이터 청크로 저장될 필요가 없을 때, 상호작용 데이터는 아이템에 저장될 수 있다. 이러한 아이템들은 옵션적 명칭 및 MIME 타입을 제공함으로써 저장될 수 있다.

웹 데이터의 경우, 상이한 아이템들을 사용하여, 기본 아이템인 HTML 페이지로, 및 정규 트랙들로서 오디오/비디오 리소스들로, HTML 페이지 및 연관된 리소스들, 예컨대 CSS 및 JS 를 저장하는 것이 가능하다. "메타" 를 인식하지 못하는 플레이어는 이 파일을 간단한 오디오/비디오 파일인 것처럼 간단하게 재생하는 반면, "메타" 를 인식하는 플레이어는 HTML 및 연관된 리소스를 로딩한 다음, 이 페이지의 컨텍스트에서 오디오/비디오를 로딩함으로써 시작한다.

도 1 은 네트워크를 통해 미디어 데이터를 스트리밍하기 위한 기술들을 구현하는 예시적인 시스템 (10) 을 도시하는 블록도이다. 이 예에서, 시스템 (10) 은 콘텐츠 준비 디바이스 (20), 서버 디바이스 (60), 및 클라이언트 디바이스 (40) 를 포함한다. 클라이언트 디바이스 (40) 및 서버 디바이스 (60) 는, 인터넷을 포함할 수도 있는 네트워크 (74) 에 의해 통신가능하게 커플링된다. 일부 예들에 있어서, 컨텐츠 준비 디바이스 (20) 및 서버 디바이스 (60) 는 또한, 네트워크 (74) 또는 다른 네트워크에 의해 커플링될 수도 있거나, 또는 직접 통신가능하게 커플링될 수도 있다. 일부 예들에 있어서, 컨텐츠 준비 디바이스 (20) 및 서버 디바이스 (60) 는 동일한 디바이스를 포함할 수도 있다.

콘텐츠 준비 디바이스 (20) 는, 도 1 의 예에서, 오디오 소스 (22) 및 비디오 소스 (24) 를 포함한다. 오디오 소스 (22) 는, 예를 들어, 오디오 인코더 (26) 에 의해 인코딩될 캡처된 오디오 데이터를 나타내는 전기적 신호들을 생성하는 마이크로폰을 포함할 수도 있다. 대안적으로, 오디오 소스 (22) 는 이전에 레코딩된 오디오 데이터를 저장하는 저장 매체, 컴퓨터화된 합성기와 같은 오디오 데이터 생성기, 또는 오디오 데이터의 임의의 다른 소스를 포함할 수도 있다. 비디오 소스 (24) 는 비디오 인코더 (28) 에 의해 인코딩될 비디오 데이터를 생성하는 비디오 카메라, 이전에 레코딩된 비디오 데이터로 인코딩된 저장 매체, 컴퓨터 그래픽스 소스와 같은 비디오 데이터 생성 유닛, 또는 비디오 데이터의 임의의 다른 소스를 포함할 수도 있다. 컨텐츠 준비 디바이스 (20) 는 모든 예들에서 서버 디바이스 (60) 에 통신가능하게 커플링될 필요는 없지만, 서버 디바이스 (60) 에 의해 판독되는 별도의 매체에 멀티미디어 컨텐츠를 저장할 수도 있다.

원시 (raw) 오디오 및 비디오 데이터는 아날로그 또는 디지털 데이터를 포함할 수도 있다. 아날로그 데이터는 오디오 인코더 (26) 및/또는 비디오 인코더 (28) 에 의해 인코딩되기 전에 디지털화될 수도 있다. 오디오 소스 (22) 는 발화 (speaking) 참가자가 말하는 동안 발화 참가자로부터 오디오 데이터를 획득할 수도 있고, 비디오 소스 (24) 는 동시에, 발화 참가자의 비디오 데이터를 획득할 수도 있다. 다른 예들에서, 오디오 소스 (22) 는 저장된 오디오 데이터를 포함하는 컴퓨터 판독가능 저장 매체를 포함할 수도 있고, 비디오 소스 (24) 는 저장된 비디오 데이터를 포함하는 컴퓨터 판독가능 저장 매체를 포함할 수도 있다. 이런 방식으로, 본 개시에서 설명된 기법들은 라이브, 스트리밍, 실시간 오디오 및 비디오 데이터에 또는 아카이브된 (archived), 미리 레코딩된 오디오 및 비디오 데이터에 적용될 수도 있다.

비디오 프레임들에 대응하는 오디오 프레임들은 일반적으로 비디오 프레임들 내에 포함되는 비디오 소스 (24) 에 의해 캡처된 (또는 생성된) 비디오 데이터와 동시에 오디오 소스 (22) 에 의해 캡처되었던 (또는 생성되었던) 오디오 데이터를 포함하는 오디오 프레임들이다. 예를 들어, 말하는 참가자가 일반적으로 말하는 것에 의해 오디오 데이터를 생성하는 동안, 오디오 소스 (22) 는 오디오 데이터를 캡처하고, 비디오 소스 (24) 는 동시에, 다시 말하면, 오디오 소스 (22) 가 오디오 데이터를 캡처하고 있는 동안, 말하는 참가자의 비디오 데이터를 캡처한다. 그래서, 오디오 프레임이 하나 이상의 특정 비디오 프레임들에 시간적으로 대응할 수도 있다. 따라서, 비디오 프레임에 대응하는 오디오 프레임은 일반적으로, 오디오 데이터 및 비디오 데이터가 동시에 캡처되었고 오디오 프레임 및 비디오 프레임이 각각, 동시에 캡처된 오디오 데이터 및 비디오 데이터를 포함하는 상황에 대응한다.

일부 예들에서, 오디오 인코더 (26) 는, 인코딩된 오디오 프레임에 대한 오디오 데이터가 레코딩된 시간을 나타내는 각 인코딩된 오디오 프레임에서 타임스탬프를 인코딩할 수도 있고, 마찬가지로, 비디오 인코더 (28) 는, 인코딩된 비디오 프레임에 대한 비디오 데이터가 레코딩된 시간을 나타내는 각 인코딩된 비디오 프레임에서 타임스탬프를 인코딩할 수도 있다. 이러한 예들에서, 비디오 프레임에 대응하는 오디오 프레임은 타임스탬프를 포함하는 오디오 프레임 및 동일한 타임스탬프를 포함하는 비디오 프레임을 포함할 수도 있다. 콘텐츠 준비 디바이스 (20) 는 내부 클록을 포함할 수도 있고, 그 내부 클록으로부터 오디오 인코더 (26) 및/또는 비디오 인코더 (28) 는 타임스탬프들을 생성할 수도 있거나, 또는, 오디오 소스 (22) 및 비디오 소스 (24) 는 오디오 및 비디오 데이터를 각각 타임스탬프와 연관시키기 위해 이용할 수도 있다.

일부 예들에서, 오디오 소스 (22) 는 오디오 데이터가 레코딩된 시간에 대응하는 데이터를 오디오 인코더 (26) 에 전송할 수도 있고, 비디오 소스 (24) 는 비디오 데이터가 레코딩된 시간에 대응하는 데이터를 비디오 인코더 (28) 에 전송할 수도 있다. 일부 예들에서, 오디오 인코더 (26) 는, 인코딩된 오디오 데이터의 상대적인 시간 순서화를 나타내지만 오디오 데이터가 레코딩된 절대 시간을 반드시 나타낼 필요는 없는 인코딩된 오디오 데이터에서 시퀀스 식별자를 인코딩할 수도 있고, 유사하게, 비디오 인코더 (28) 는 또한, 시퀀스 식별자를 사용하여 인코딩된 비디오 데이터의 상대적인 시간 순서화를 나타낼 수도 있다. 유사하게, 일부 예들에서, 시퀀스 식별자는 타임스탬프로 맵핑되거나 또는 그렇지 않으면 타임스탬프와 상관될 수도 있다.

오디오 인코더 (26) 는 일반적으로 인코딩된 오디오 데이터의 스트림을 생성하는 한편, 비디오 인코더 (28) 는 인코딩된 비디오 데이터의 스트림을 생성한다. 데이터 (오디오든 비디오든) 의 각각의 개별 스트림은 기본 스트림 (elementary stream) 으로서 지칭될 수도 있다. 기본 스트림은 레프리젠테이션의 단일의, 디지털로 코딩된 (가능하게는 압축된) 컴포넌트이다. 예를 들어, 레프리젠테이션의 코딩된 비디오 또는 오디오 부분은 기본 스트림일 수 있다. 기본 스트림은 비디오 파일 내에서 캡슐화되기 전에 패킷화된 기본 스트림 (PES) 으로 변환될 수도 있다. 동일한 레프리젠테이션 내에서, 스트림 ID 는 하나의 기본 스트림에 속하는 PES 패킷들을 다른 것으로부터 구별하는데 사용될 수도 있다. 기본 스트림의 데이터의 기본 단위는 패킷화된 기본 스트림 (PES) 패킷이다. 따라서, 코딩된 비디오 데이터는 일반적으로 기본 비디오 스트림들에 대응한다. 유사하게는, 오디오 데이터는 하나 이상의 각각의 기본 스트림들에 대응한다.

ITU-T H.264/AVC 및 도래하는 고효율 비디오 코딩 (HEVC) 표준과 같은 많은 비디오 코딩 표준들은, 에러 없는 비트스트림들을 위한 신택스, 시맨틱스, 및 디코딩 프로세스를 정의하고, 그것들 중의 어떤 것은 특정 프로파일 또는 레벨을 따른다. 비디오 코딩 표준들은 통상적으로 인코더를 특정하지 않지만, 인코더는 생성된 비트스트림들이 디코더에 부합하는 표준이라는 것을 보장하는 임무가 주어진다. 비디오 코딩 표준들의 맥락에서, "프로파일” 은 알고리즘들, 특징부들, 또는 툴들 및 그것들에 적용되는 제약들의 서브세트에 대응한다. H.264 표준에 의해 정의된 바와 같이, 예를 들어, "프로파일" 은 H.264 표준에 의해 명시되는 전체 비트스트림 신택스의 서브세트이다. "레벨" 은 예를 들어, 디코더 메모리 및 컴퓨테이션과 같은 디코더 리소스 소비의 한계들에 대응하며, 이 한계들은 화상들의 해상도, 비트 레이트, 및 블록 프로세싱 레이트에 관련된다. 프로파일은 profile_idc (프로파일 표시자) 값으로 시그널링될 수도 있는 한편, 레벨은 level_idc (레벨 표시자) 값으로 시그널링될 수도 있다.

H.264 표준은, 예를 들어, 주어진 프로파일의 신택스에 의해 부과된 경계들 내에서, 디코딩된 픽처들의 명시된 사이즈와 같이 비트스트림에서의 신택스 엘리먼트들에 의해 취해진 값들에 의존하여 인코더들 및 디코더들의 성능에서의 큰 변동을 요구하는 것이 여전히 가능하다는 것을 인식한다. H.264 표준은, 다수의 어플리케이션들에 있어서, 특정 프로파일 내에서 신택스의 모든 가설적 사용들을 다루는 것이 가능한 디코더를 구현하는 것이 실용적이지도 않고 경제적이지도 않다는 것을 추가로 인식한다. 이에 따라, H.264 표준은, 비트스트림에서 신택스 엘리먼트들의 값들에 부과된 제약들의 명시된 세트로서 "레벨" 을 정의한다. 이들 제약들은 값들에 관한 간단한 제한들일 수도 있다. 대안적으로, 이들 제약들은 값들의 산술적 조합들 (예컨대, 픽처 폭 곱하기 픽처 높이 곱하기 초당 디코딩된 픽처들의 수) 에 관한 제약들의 형태를 취할 수도 있다. H.264 표준은, 개별 구현들이 각각의 지원된 프로파일에 대해 상이한 레벨을 지원할 수도 있음을 추가로 제공한다.

프로파일에 부합하는 디코더는 보통, 프로파일에서 정의된 모든 특징들을 지원한다. 예를 들어, 코딩 특징으로서, B-픽처 코딩은 H.264/AVC 의 베이스라인 프로파일에서 지원되지 않지만 H.264/AVC 의 다른 프로파일들에서 지원된다. 레벨에 부합하는 디코더는, 그 레벨에서 정의된 한계들을 너머 리소스들을 요구하지 않는 임의의 비트스트림을 디코딩하는 것이 가능해야 한다. 프로파일들 및 레벨들의 정의들은 해석 가능성 (interpretability) 에 도움이 될 수도 있다. 예를 들어, 비디오 송신 동안, 프로파일 및 레벨 정의들의 쌍은 전체 송신 세션 동안 협상되고 합의될 수도 있다. 더 구체적으로, H.264/AVC 에 있어서, 레벨은, 프로세싱될 필요가 있는 매크로블록들의 수, 디코딩된 픽처 버퍼 (DPB) 사이즈, 코딩된 픽처 버퍼 (CPB) 사이즈, 수직 모션 벡터 범위, 2개의 연속적인 MB들 당 모션 벡터들의 최대 수, 및 B-블록이 8x8 픽셀들 미만의 서브-매크로블록 파티션들을 가질 수 있는지의 여부에 관한 제한들을 정의할 수도 있다. 이러한 방식으로, 디코더는, 디코더가 비트스트림을 적절히 디코딩하는 것이 가능한지의 여부를 결정할 수도 있다.

도 1 의 예에서, 콘텐츠 준비 디바이스 (20) 의 캡슐화 유닛 (30) 은 코딩된 비디오 데이터를 포함하는 기본 스트림들을 비디오 인코더 (28) 로부터 그리고 코딩된 오디오 데이터를 포함하는 기본 스트림들을 오디오 인코더 (26) 로부터 수신한다. 일부 예들에서, 비디오 인코더 (28) 및 오디오 인코더 (26) 는 각각, 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기들을 포함할 수도 있다. 다른 예들에 있어서, 비디오 인코더 (28) 및 오디오 인코더 (26) 는 각각, 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 개별 패킷화기들과 인터페이싱할 수도 있다. 또 다른 예들에 있어서, 캡슐화 유닛 (30) 은, 인코딩된 오디오 및 비디오 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기들을 포함할 수도 있다.

비디오 인코더 (28) 는 멀티미디어 컨텐츠의 비디오 데이터를 다양한 방식들로 인코딩하여, 다양한 비트레이트들에서 그리고 다양한 특성들, 예컨대, 픽셀 해상도들, 프레임 레이트들, 다양한 코딩 표준들에 대한 부합, 다양한 코딩 표준들을 위한 다양한 프로파일들 및/또는 프로파일들의 레벨들에 대한 부합, (예컨대, 2차원 또는 3차원 재생을 위한) 하나 또는 다중의 뷰들을 갖는 레프리젠테이션들, 또는 다른 그러한 특성들을 갖는 멀티미디어 컨텐츠의 상이한 레프리젠테이션들을 생성할 수도 있다. 레프리젠테이션은, 본 개시에서 사용된 바와 같이, 오디오 데이터, 비디오 데이터, (예컨대, 폐쇄된 캡션들을 위한) 텍스트 데이터, 또는 다른 그러한 데이터 중 하나를 포함할 수도 있다. 레프리젠테이션은 오디오 기본 스트림 또는 비디오 기본 스트림과 같은 기본 스트림을 포함할 수도 있다. 각각의 PES 패킷은, PES 패킷이 속한 기본 스트림을 식별하는 stream_id 를 포함할 수도 있다. 캡슐화 유닛 (30) 은 기본 스트림들을 다양한 레프리젠테이션들의 비디오 파일들 (예컨대, 세그먼트들) 로 어셈블링하는 것을 담당한다.

캡슐화 유닛 (30) 은 오디오 인코더 (26) 및 비디오 인코더 (28) 로부터 레프리젠테이션의 기본 스트림들에 대한 PES 패킷들을 수신하고, PES 패킷들로부터 대응하는 네트워크 추상화 계층 (NAL) 유닛들을 형성한다. 코딩된 비디오 세그먼트는 NAL 유닛들로 조직될 수도 있고, 이들은 비디오 전화, 스토리지, 브로드캐스트, 또는 스트리밍과 같은 애플리케이션들을 다루는 "네트워크 친화적" 비디오 레프리젠테이션을 제공한다. NAL 유닛들은 비디오 코딩 계층 (Video Coding Layer; VCL) NAL 유닛들 및 비-VCL NAL 유닛들로 분류될 수 있다. VCL 유닛들은 코어 압축 엔진을 포함할 수도 있고 블록, 매크로블록, 및/또는 슬라이스 레벨 데이터를 포함할 수도 있다. 다른 NAL 유닛들은 비-VCL NAL 유닛들일 수도 있다. 일부 예들에 있어서, 프라이머리 코딩된 픽처로서 통상 제시되는 일 시간 인스턴스에서의 코딩된 픽처는, 하나 이상의 NAL 유닛들을 포함할 수도 있는 액세스 유닛에 포함될 수도 있다.

비-VCL NAL 유닛들은, 다른 것들 중에서, 파라미터 세트 NAL 유닛들 및 SEI NAL 유닛들을 포함할 수도 있다. 파라미터 세트들은 (시퀀스 파라미터 세트들 (SPS) 에서) 시퀀스-레벨 헤더 정보 및 (픽처 파라미터 세트들 (PPS) 에서) 드물게 변하는 픽처-레벨 헤더 정보를 포함할 수도 있다. 파라미터 세트들 (예컨대, PPS 및 SPS) 에 있어서, 드물게 변하는 정보는 각각의 시퀀스 또는 픽처에 대해 반복될 필요가 없고, 따라서, 코딩 효율이 개선될 수도 있다. 더욱이, 파라미터 세트들의 사용은 중요한 헤더 정보의 대역외 송신을 가능하게 할 수도 있어서, 에러 내성을 위한 리던던트 송신들에 대한 필요성을 회피시킬 수도 있다. 대역외 송신 예들에 있어서, 파라미터 세트 NAL 유닛들은 SEI NAL 유닛들과 같은 다른 NAL 유닛들과는 상이한 채널 상에서 송신될 수도 있다.

보충 강화 정보 (SEI) 는, VCL NAL 유닛들로부터 코딩된 픽처 샘플들을 디코딩할 필요는 없지만 디코딩, 디스플레이, 에러 내성, 및 다른 목적들과 관련된 프로세스들을 보조할 수도 있는 정보를 포함할 수도 있다. SEI 메시지들은 비-VCL NAL 유닛들에 포함될 수도 있다. SEI 메시지들은 일부 표준 사양들의 정규 부분이고, 따라서, 표준 호환성 디코더 구현에 항상 필수적인 것은 아니다. SEI 메시지들은 시퀀스 레벨 SEI 메시지들 또는 픽처 레벨 SEI 메시지들일 수도 있다. 일부 시퀀스 레벨 정보는 SVC 의 예에서의 스케일가능성 정보 SEI 메시지들 및 MVC 에서의 뷰 스케일가능성 정보 SEI 메시지들과 같은 SEI 메시지들에 포함될 수도 있다. 이들 예시적인 SEI 메시지들은, 예컨대, 동작 포인트들의 추출 및 동작 포인트들의 특성들에 관한 정보를 전달할 수도 있다. 부가적으로, 캡슐화 유닛 (30) 은 레프리젠테이션들의 특성들을 기술하는 미디어 프리젠테이션 디스크립터 (MPD) 와 같은, 매니페스트 파일을 형성할 수도 있다. 캡슐화 유닛 (30) 은 확장성 마크업 언어 (XML) 에 따라 MPD 를 포맷화할 수도 있다.

캡슐화 유닛 (30) 은 멀티미디어 컨텐츠의 하나 이상의 레프리젠테이션들에 대한 데이터를 매니페스트 파일 (예컨대, MPD) 과 함께 출력 인터페이스 (32) 에 제공할 수도 있다. 출력 인터페이스 (32) 는 네트워크 인터페이스 또는 저장 매체에 기입하기 위한 인터페이스, 예컨대, 범용 직렬 버스 (USB) 인터페이스, CD 또는 DVD 라이터 또는 버너 (burner), 자기적 또는 플래시 저장 매체들에 대한 인터페이스, 또는 미디어 데이터를 저장하거나 송신하기 위한 다른 인터페이스들을 포함할 수도 있다. 캡슐화 유닛 (30) 은 멀티미디어 컨텐츠의 레프리젠테이션들의 각각의 데이터를 출력 인터페이스 (32) 에 제공할 수도 있으며, 그 출력 인터페이스 (32) 는 그 데이터를 네트워크 송신 또는 저장 매체들을 통해 서버 디바이스 (60) 로 전송할 수도 있다. 도 1 의 예에서, 서버 디바이스 (60) 는 각기의 매니페스트 파일 (66) 및 하나 이상의 레프리젠테이션들 (68A-68N) (레프리젠테이션들 (68)) 을 각각 포함하는 다양한 멀티미디어 콘텐츠 (64) 를 저장하는 저장 매체 (62) 를 포함한다. 일부 예들에서, 출력 인터페이스 (32) 는 또한 데이터를 직접 네트워크 (74) 에 전송할 수도 있다.

일부 예들에 있어서, 레프리젠테이션들 (68) 은 적응 세트들로 분리될 수도 있다. 즉, 레프리젠테이션들 (68) 의 다양한 서브세트들은 특성들의 개별 공통 세트들, 이를테면, 코덱, 프로파일 및 레벨, 해상도, 뷰들의 수, 세그먼트들에 대한 파일 포맷, 디코딩되고 예컨대 스피커들에 의해 제시될 오디오 데이터 및/또는 레프리젠테이션으로 디스플레이될 텍스트의 언어 또는 다른 특성들을 식별할 수도 있는 텍스트 타입 정보, 적응 세트에서 레프리젠테이션들에 대한 장면의 카메라 각도 또는 실세계 카메라 퍼스펙티브 (camera perspective) 를 기술할 수도 있는 카메라 각도 정보, 특정 청중들에 대한 컨텐츠 적합성 (suitability) 을 기술하는 등급 정보 등을 포함할 수도 있다.

매니페스트 파일 (66) 은 특정한 적응 세트들, 및 적응 세트들을 위한 공통 특성들에 대응하는 레프리젠테이션들 (68) 의 서브세트들을 나타내는 데이터를 포함할 수도 있다. 매니페스트 파일 (66) 은 또한 적응 세트들의 개개의 레프리젠테이션들에 대한, 비트레이트와 같은, 개개의 특성들을 나타내는 데이터를 포함할 수도 있다. 이런 방식으로, 적응 세트는 단순화된 네트워크 대역폭 적응을 제공할 수도 있다. 적응 세트에서의 레프리젠테이션들은 매니페스트 파일 (66) 의 적응 세트 요소의 자식 (child) 요소들을 이용하여 나타내어질 수도 있다.

서버 디바이스 (60) 는 요청 프로세싱 유닛 (70) 과 네트워크 인터페이스 (72) 를 포함한다. 일부 예들에서, 서버 디바이스 (60) 는 복수의 네트워크 인터페이스들을 포함할 수도 있다. 더욱이, 서버 디바이스 (60) 의 특징들의 임의의 것 또는 모두는 콘텐츠 전달 네트워크의 다른 디바이스들, 이를테면 라우터들, 브릿지들, 프록시 디바이스들, 스위치들, 또는 다른 디바이스들 상에서 구현될 수도 있다. 일부 예들에서, 콘텐츠 전달 네트워크의 중간 디바이스들은 멀티미디어 콘텐츠 (64) 의 데이터를 캐싱하고, 서버 디바이스 (60) 의 그것들에 실질적으로 부합하는 컴포넌트들을 포함할 수도 있다. 일반적으로, 네트워크 인터페이스 (72) 는 네트워크 (74) 를 통해 데이터를 전송하고 수신하도록 구성된다.

요청 프로세싱 유닛 (70) 은, 저장 매체 (62) 의 데이터에 대한, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스들로부터 네트워크 요청들을 수신하도록 구성된다. 예를 들어, 요청 프로세싱 유닛 (70) 은, R. Fielding 등의 RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1", Network Working Group, IETF, 1999 년 6 월에서 기술된 바와 같이, 하이퍼텍스트 전송 프로토콜 (HTTP) 버전 1.1 을 구현할 수도 있다. 즉, 요청 프로세싱 유닛 (70) 은 HTTP GET 또는 부분 GET 요청들을 수신하고 그 요청들에 응답하여 멀티미디어 컨텐츠 (64) 의 데이터를 제공하도록 구성될 수도 있다. 요청들은 레프리젠테이션들 (68) 중 하나의 레프리젠테이션의 세그먼트를, 예컨대, 그 세그먼트의 URL 을 이용하여 명시할 수도 있다. 일부 예들에 있어서, 요청들은 또한, 세그먼트의 하나 이상의 바이트 범위들을 명시할 수도 있고, 따라서, 부분 GET 요청들을 포함할 수도 있다. 요청 프로세싱 유닛 (70) 은 추가로, 레프리젠테이션들 (68) 중 하나의 레프리젠테이션의 세그먼트의 헤더 데이터를 제공하기 위해 HTTP HEAD 요청들을 서비스하도록 구성될 수도 있다. 어느 경우든, 요청 프로세싱 유닛 (70) 은 요청된 데이터를 클라이언트 디바이스 (40) 와 같은 요청 디바이스에 제공하기 위해 요청들을 프로세싱하도록 구성될 수도 있다.

부가적으로 또는 대안적으로, 요청 프로세싱 유닛 (70) 은 eMBMS 와 같은 브로드캐스트 또는 멀티캐스트 프로토콜을 통해 미디어 데이터를 전달하도록 구성될 수도 있다. 컨텐츠 준비 디바이스 (20) 는 기술된 바와 실질적으로 동일한 방식으로 DASH 세그먼트들 및/또는 서브-세그먼트들을 생성할 수도 있지만, 서버 디바이스 (60) 는 eMBMS 또는 다른 브로드캐스트 또는 멀티캐스트 네트워크 전송 프로토콜을 이용하여 이들 세그먼트들 또는 서브-세그먼트들을 전달할 수도 있다. 예를 들어, 요청 프로세싱 유닛 (70) 은 클라이언트 디바이스 (40) 로부터 멀티캐스트 그룹 참여 요청을 수신하도록 구성될 수도 있다. 즉, 서버 디바이스 (60) 는, 특정 미디어 컨텐츠 (예컨대, 라이브 이벤트의 브로드캐스트) 와 연관된, 클라이언트 디바이스 (40) 를 포함한 클라이언트 디바이스들에 멀티캐스트 그룹과 연관된 인터넷 프로토콜 (IP) 어드레스를 광고할 수도 있다. 클라이언트 디바이스 (40) 는, 차례로, 멀티캐스트 그룹에 참여하기 위한 요청을 제출할 수도 있다. 이 요청은 네트워크 (74), 예컨대, 네트워크 (74) 를 구성하는 라우터들 전반에 걸쳐 전파될 수도 있어서, 그 라우터들은 클라이언트 디바이스 (40) 와 같은 가입 클라이언트 디바이스들에 멀티캐스트 그룹과 연관된 IP 어드레스 행으로 정해진 트래픽을 지시하도록 야기된다.

도 1 의 예에서 도시된 바와 같이, 멀티미디어 콘텐츠 (64) 는, 미디어 프리젠테이션 디스크립션 (MPD) 에 대응할 수도 있는 매니페스트 파일 (66) 을 포함한다. 매니페스트 파일 (66) 은 상이한 대안적인 레프리젠테이션들 (68) (예컨대, 상이한 품질들을 갖는 비디오 서비스들) 의 디스크립션들을 포함할 수도 있고, 그 디스크립션은, 예컨대, 코덱 정보, 프로파일 값, 레벨 값, 비트레이트, 및 레프리젠테이션들 (68) 의 다른 서술적 특성들을 포함할 수도 있다. 클라이언트 디바이스 (40) 는 미디어 프리젠테이션의 MPD 를 취출하여 레프리젠테이션들 (68) 의 세그먼트들에 어떻게 액세스할 지를 결정할 수도 있다.

특히, 취출 유닛 (52) 은 클라이언트 디바이스 (40) 의 구성 데이터 (도시 안됨) 를 취출하여 비디오 디코더 (48) 의 디코딩 능력들 및 비디오 출력부 (44) 의 렌더링 능력들을 결정할 수도 있다. 구성 데이터는 또한, 클라이언트 디바이스 (40) 의 사용자에 의해 선택된 언어 선호도, 클라이언트 디바이스 (40) 의 사용자에 의해 설정된 심도 선호도들에 대응하는 하나 이상의 카메라 퍼스펙티브들, 및/또는 클라이언트 디바이스 (40) 의 사용자에 의해 선택된 등급 선호도 중 임의의 것 또는 그 모두를 포함할 수도 있다. 취출 유닛 (52) 은, 예를 들어, HTTP GET 및 부분 GET 요청들을 제출하도록 구성된 미디어 클라이언트 또는 웹 브라우저를 포함할 수도 있다. 취출 유닛 (52) 은 클라이언트 디바이스 (40) 의 하나 이상의 프로세서들 또는 프로세싱 유닛들 (도시 안됨) 에 의해 실행된 소프트웨어 명령들에 대응할 수도 있다. 일부 예들에 있어서, 취출 유닛 (52) 에 대하여 기술된 기능의 모두 또는 그 부분들은 하드웨어에서, 또는 하드웨어, 소프트웨어, 및/또는 펌웨어의 조합에서 구현될 수도 있으며, 여기서, 필요한 하드웨어는 소프트웨어 또는 펌웨어에 대한 명령들을 실행하기 위해 제공될 수도 있다.

취출 유닛 (52) 은 클라이언트 디바이스 (40) 의 디코딩 및 렌더링 능력들을, 매니페스트 파일 (66) 의 정보에 의해 표시된 레프리젠테이션들 (68) 의 특성들과 비교할 수도 있다. 취출 유닛 (52) 은 처음에 적어도 매니페스트 파일 (66) 의 일부를 취출하여 레프리젠테이션들 (68) 의 특성들을 결정할 수도 있다. 예를 들어, 취출 유닛 (52) 은, 하나 이상의 적응 세트들의 특성들을 기술하는 매니페스트 파일 (66) 일부를 요청할 수도 있다. 취출 유닛 (52) 은 클라이언트 디바이스 (40) 의 코딩 및 렌더링 능력들에 의해 만족될 수 있는 특성들을 갖는 레프리젠테이션들 (68) (예컨대, 적응 세트) 의 서브세트를 선택할 수도 있다. 취출 유닛 (52) 은 그 다음, 적응 세트 내의 레프리젠테이션들에 대한 비트레이트들을 결정하고, 네트워크 대역폭의 현재 이용가능한 양을 결정하며, 그리고 네트워크 대역폭에 의하여 만족될 수 있는 비트레이트를 가지는 레프리젠테이션들 중 하나로부터 세그먼트들을 취출할 수도 있다.

일반적으로, 더 높은 비트레이트 레프리젠테이션들은 더 높은 품질의 비디오 재생을 산출할 수도 있는 한편, 더 낮은 비트레이트 레프리젠테이션들은 가용 네트워크 대역폭이 감소할 때 충분한 품질의 비디오 재생을 제공할 수도 있다. 이에 따라, 가용 네트워크 대역폭이 상대적으로 높은 경우에는, 취출 유닛 (52) 은 데이터를 상대적으로 높은 비트레이트 레프리젠테이션들로부터 취출할 수도 있는 반면에, 가용 네트워크 대역폭이 낮은 경우에는, 취출 유닛 (52) 은 데이터를 상대적으로 낮은 비트레이트 레프리젠테이션들로부터 취출할 수도 있다. 이러한 방식으로, 클라이언트 디바이스 (40) 는 네트워크 (74) 의 변동하는 네트워크 대역폭 이용가능성에 적응하면서도 멀티미디어 데이터를 네트워크 (74) 를 통해 스트리밍할 수도 있다.

추가적으로 또는 대안적으로, 취출 유닛 (52) 은 eMBMS 또는 IP 멀티캐스트와 같은, 브로드캐스트 또는 멀티캐스트 네트워크 프로토콜에 따라 데이터를 수신하도록 구성될 수도 있다. 이러한 예들에서, 취출 유닛 (52) 은 특정 미디어 콘텐츠와 연관된 멀티캐스트 네트워크 그룹에 참여하기 위한 요청을 제출할 수도 있다. 멀티캐스트 그룹에 참여한 후에, 취출 유닛 (52) 은 서버 디바이스 (60) 또는 콘텐츠 준비 디바이스 (20) 에 발행된 추가적인 요청들 없이 멀티캐스트 그룹의 데이터를 수신할 수도 있다. 취출 유닛 (52) 은, 멀티캐스트 그룹의 데이터가 더 이상 필요 없을 때 멀티캐스트 그룹을 떠나기 위한, 예컨대 다른 멀티캐스트 그룹으로 채널들을 변경하거나 재생을 중지하기 위한 요청을 제출할 수도 있다.

네트워크 인터페이스 (54) 는, 선택된 레프리젠테이션의 세그먼트들의 데이터를 수신하고 취출 유닛 (52) 에 제공할 수도 있고, 이 취출 유닛 (52) 은 차례로 그 세그먼트들을 탈캡슐화 (decapsulation) 유닛 (50) 에 제공할 수도 있다. 탈캡슐화 유닛 (50) 은 비디오 파일의 엘리먼트들을 구성 PES 스트림들로 탈캡슐화하고, PES 스트림들을 탈패킷화하여 인코딩된 데이터를 취출하고, 예컨대, 스트림의 PES 패킷 헤더들에 의해 표시된 바와 같이, 인코딩된 데이터가 오디오 스트림의 부분인지 또는 비디오 스트림의 부분인지에 의존하여, 인코딩된 데이터를 오디오 디코더 (46) 또는 비디오 디코더 (48) 중 어느 하나에 전송할 수도 있다. 오디오 디코더 (46) 는 인코딩된 오디오 데이터를 디코딩하고 디코딩된 오디오 데이터를 오디오 출력부 (42) 에 전송하는 한편, 비디오 디코더 (48) 는 인코딩된 비디오 데이터를 디코딩하고 스트림의 복수의 뷰들을 포함할 수도 있는 디코딩된 비디오 데이터를 비디오 출력부 (44) 에 전송한다.

비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), 캡슐화 유닛 (30), 취출 유닛 (52), 및 탈캡슐화 유닛 (50) 각각은 적용가능한 경우에 다양한 적합한 처리 회로들, 예컨대 하나 이상의 마이크로프로세서들, 디지털 신호 프로세서 (DSP) 들, 주문형 집적회로 (ASIC) 들, 필드 프로그래밍가능 게이트 어레이 (FPGA) 들, 이산 로직 회로, 소프트웨어, 하드웨어, 펌웨어 또는 임의의 이들의 조합들 중 임의의 것으로서 구현될 수도 있다. 비디오 인코더 (28) 및 비디오 디코더 (48) 각각은 하나 이상의 인코더들 또는 디코더들 내에 포함될 수도 있는데, 이들 중 어느 것도 결합된 비디오 인코더/디코더 (CODEC) 의 일부로서 통합될 수도 있다. 마찬가지로, 오디오 인코더 (26) 및 오디오 디코더 (46) 의 각각은 하나 이상의 인코더들 또는 디코더들에 포함될 수도 있는데, 이들 중 어느 것도 결합된 CODEC 의 부분으로서 통합될 수도 있다. 비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), 캡슐화 유닛 (30), 취출 유닛 (52), 및/또는 탈캡슐화 유닛 (50) 을 포함하는 장치는 집적 회로, 마이크로프로세서, 및/또는 무선 통신 디바이스, 예컨대 셀룰러 전화기를 포함할 수도 있다.

클라이언트 디바이스 (40), 서버 디바이스 (60), 및/또는 콘텐츠 준비 디바이스 (20) 는 본 개시의 기법들에 따라 동작하도록 구성될 수도 있다. 예시를 위해, 본 개시는 클라이언트 디바이스 (40) 와 서버 디바이스 (60) 에 대해 이들 기법들을 기술한다. 하지만, 콘텐츠 준비 디바이스 (20) 가 서버 디바이스 (60) 대신에 (또는 추가적으로) 이들 기법들을 수행하도록 구성될 수도 있다.

캡슐화 유닛 (30) 은, NAL 유닛이 속하는 프로그램을 식별하는 헤더와, 예컨대, 오디오 데이터, 비디오 데이터, 또는 NAL 유닛이 대응하는 전송 또는 프로그램 스트림을 기술하는 데이터와 같은 페이로드를 포함하는 NAL 유닛들을 형성할 수도 있다. 예를 들어, H.264/AVC 에서, NAL 유닛은 1-바이트 헤더 및 가변 사이즈의 페이로드를 포함한다. 페이로드에 비디오 데이터를 포함하는 NAL 유닛은 다양한 입도 레벨들 (granularity levels) 의 비디오 데이터를 포함할 수도 있다. 예를 들어, NAL 유닛은 비디오 데이터의 블록, 복수의 블록들, 비디오 데이터의 슬라이스, 또는 비디오 데이터의 전체 화상을 포함할 수도 있다. 캡슐화 유닛 (30) 은 기본 스트림들의 PES 패킷들의 형태로 비디오 인코더 (28) 로부터 인코딩된 비디오 데이터를 수신할 수도 있다. 캡슐화 유닛 (30) 은 각각의 기본 스트림을 대응하는 프로그램과 연관시킬 수도 있다.

캡슐화 유닛 (30) 은 또한, 복수의 NAL 유닛들로부터 액세스 유닛들을 어셈블링할 수도 있다. 일반적으로, 액세스 유닛은 비디오 데이터의 프레임, 및 오디오 데이터가 이용가능할 때 그 프레임에 대응하는 그러한 오디오 데이터를 나타내기 위한 하나 이상의 NAL 유닛들을 포함할 수도 있다. 액세스 유닛은 일반적으로, 일 출력 시간 인스턴스에 대한 모든 NAL 유닛들, 예컨대, 일 시간 인스턴스에 대한 모든 오디오 및 비디오 데이터를 포함한다. 예를 들어, 각각의 뷰가 20 의 초당 프레임 (fps) 의 프레임 레이트를 가지면, 각각의 시간 인스턴스는 0.05 초의 시간 인터벌에 대응할 수도 있다. 이 시간 인터벌 동안, 동일한 액세스 유닛 (동일한 시간 인스턴스) 의 모든 뷰들에 대한 특정 프레임들이 동시에 렌더링될 수도 있다. 일 예에 있어서, 액세스 유닛은 일 시간 인스턴스에서 코딩된 픽처를 포함할 수도 있으며, 이는 프라이머리 코딩된 픽처로서 제시될 수도 있다.

이에 따라, 액세스 유닛은 공통 시간 인스턴스의 모든 오디오 및 비디오 프레임들, 예컨대, 시간 X 에 대응하는 모든 뷰들을 포함할 수도 있다. 본 개시는 또한, 특정 뷰의 인코딩된 픽처를 "뷰 컴포넌트" 로서 지칭한다. 즉, 뷰 컴포넌트는 특정 시간에 특정 뷰에 대한 인코딩된 픽처 (또는 프레임) 를 포함할 수도 있다. 이에 따라, 액세스 유닛은 공통 시간 인스턴스의 모든 뷰 컴포넌트들을 포함하는 것으로서 정의될 수도 있다. 액세스 유닛들의 디코딩 순서는 반드시 출력 또는 디스플레이 순서와 동일할 필요는 없다.

미디어 프리젠테이션은, 상이한 대안적인 레프리젠테이션들 (예컨대, 상이한 품질들을 갖는 비디오 서비스들) 의 디스크립션들을 포함할 수도 있는 미디어 프리젠테이션 디스크립션 (MPD) 을 포함할 수도 있고, 그 디스크립션은, 예컨대, 코덱 정보, 프로파일 값, 및 레벨 값을 포함할 수도 있다. MPD 는 매니페스트 파일 (66) 과 같은 매니페스트 파일의 일례이다. 클라이언트 디바이스 (40) 는 어떻게 다양한 프리젠테이션들의 무비 프래그먼트들에 액세스할지를 결정하기 위해 미디어 프리젠테이션의 MPD 를 취출할 수도 있다. 무비 프래그먼트들은 비디오 파일들의 무비 프래그먼트 박스들 (moof boxes) 에 로케이팅될 수도 있다.

매니페스트 파일 (66) (이는, 예를 들어, MPD를 포함할 수도 있음) 이 레프리젠테이션들 (68) 의 세그먼트들의 가용성을 광고할 수도 있다. 즉, MPD 는, 레프리젠테이션들 (68) 중 하나의 레프리젠테이션의 제 1 세그먼트가 이용가능하게 되는 벽시계 (wall-clock) 시간을 표시하는 정보 뿐 아니라 레프리젠테이션들 (68) 내의 세그먼트들의 지속기간들을 표시하는 정보를 포함할 수도 있다. 이런 방식으로, 클라이언트 디바이스 (40) 의 취출 유닛 (52) 은 특정 세그먼트에 선행하는 세그먼트들의 시작 시간뿐만 아니라 지속시간들에 기초하여, 각각의 세그먼트가 이용가능한 때를 결정할 수도 있다.

캡슐화 유닛 (30) 이 수신된 데이터에 기초하여 NAL 유닛들 및/또는 액세스 유닛들을 비디오 파일로 어셈블링한 이후, 캡슐화 유닛 (30) 은 비디오 파일을 출력을 위해 출력 인터페이스 (32) 로 전달한다. 일부 예들에서, 캡슐화 유닛 (30) 은 비디오 파일을 로컬로 (locally) 저장할 수도 있거나, 또는, 비디오 파일을 직접 클라이언트 디바이스 (40) 에 전송하기보다는 비디오 파일을 출력 인터페이스 (32) 를 통해 원격 서버에 전송할 수도 있다. 출력 인터페이스 (32) 는, 예를 들어, 송신기, 트랜시버, 예컨대 광학 드라이브, 자기 매체 드라이브 (예컨대, 플로피 드라이브) 와 같은 컴퓨터 판독가능 매체에 데이터를 기록하기 위한 디바이스, 범용 직렬 버스 (USB) 포트, 네트워크 인터페이스, 또는 다른 출력 인터페이스를 포함할 수도 있다. 출력 인터페이스 (32) 는 비디오 파일을, 예를 들어 송신 신호, 자기 매체, 광학 매체, 메모리, 플래시 드라이브, 또는 다른 컴퓨터 판독가능 매체와 같은 컴퓨터 판독가능 매체에 출력한다.

네트워크 인터페이스 (54) 는 네트워크 (74) 를 통해 NAL 유닛 또는 액세스 유닛을 수신하고 그 NAL 유닛 또는 액세스 유닛을 취출 유닛 (52) 을 통해 탈캡슐화 유닛 (50) 에 제공한다. 탈캡슐화 유닛 (50) 은 비디오 파일의 엘리먼트들을 구성 PES 스트림들로 탈캡슐화하고, PES 스트림들을 탈패킷화하여 인코딩된 데이터를 취출하고, 예컨대, 스트림의 PES 패킷 헤더들에 의해 표시된 바와 같이, 인코딩된 데이터가 오디오 스트림의 부분인지 또는 비디오 스트림의 부분인지에 의존하여, 인코딩된 데이터를 오디오 디코더 (46) 또는 비디오 디코더 (48) 중 어느 하나에 전송할 수도 있다. 오디오 디코더 (46) 는 인코딩된 오디오 데이터를 디코딩하고 디코딩된 오디오 데이터를 오디오 출력부 (42) 에 전송하는 한편, 비디오 디코더 (48) 는 인코딩된 비디오 데이터를 디코딩하고 스트림의 복수의 뷰들을 포함할 수도 있는 디코딩된 비디오 데이터를 비디오 출력부 (44) 에 전송한다.

도 2 는 도 1 의 취출 유닛 (52) 의 컴포넌트들의 예시적인 세트를 더 상세히 설명하는 블록도이다. 이 예에서, 취출 유닛 (52) 은 eMBMS 미들웨어 유닛 (100), DASH 클라이언트 (110) 및 미디어 애플리케이션 (112) 을 포함한다.

이 예에서, eMBMS 미들웨어 유닛 (100) 은 eMBMS 수신 유닛 (106), 캐시 (104), 및 서버 유닛 (102) 을 더 포함한다. 이 예에서, eMBMS 수신 유닛 (106) 은 예컨대, FLUTE (File Delivery over Unidirectional Transport) 에 따라 eMBMS 를 통해 데이터를 수신하도록 구성되고, 이는 http://tools.ietf.org/html/rfc6726 에서 입수가능한 T. Paila 등의 "FLUTE-File Delivery over Unidirectional Transport", Network Working Group, RFC 6726, Nov. 2012 에 기술되어 있다. 즉, eMBMS 수신 유닛 (106) 은 예를 들어 BM-SC 의 역할을 할 수도 있는 서버 디바이스 (60) 로부터 브로드캐스트를 통해 파일들을 수신할 수도 있다.

eMBMS 미들웨어 유닛 (100) 이 파일들에 대한 데이터를 수신할 때, eMBMS 미들웨어 유닛은 수신된 데이터를 캐시 (104) 에 저장할 수도 있다. 캐시 (104) 는 플래시 메모리, 하드 디스크, RAM, 또는 임의의 다른 적절한 저장 매체와 같은 컴퓨터-판독가능 저장 매체를 포함할 수도 있다.

로컬 서버 유닛 (102) 은 DASH 클라이언트 (110) 를 위한 서버로서 작용할 수도 있다. 예를 들어, 로컬 서버 유닛 (102) 은 DASH 클라이언트 (110) 에 MPD 파일 또는 다른 매니페스트 파일을 제공할 수도 있다. 로컬 서버 유닛 (102) 은 세그먼트들이 취출될 수 있는 하이퍼링크들뿐만 아니라, MPD 파일 내의 세그먼트들에 대한 가용 시간들을 광고할 수도 있다. 이들 하이퍼링크들은 클라이언트 디바이스 (40) 에 대응하는 로컬호스트 어드레스 프리픽스 (예를 들어, IPv4 의 경우 127.0.0.1) 를 포함할 수도 있다. 이러한 방식으로, DASH 클라이언트 (110) 는 HTTP GET 또는 부분 GET 요청들을 사용하여 로컬 서버 유닛 (102) 으로부터 세그먼트들을 요청할 수도 있다. 예를 들어, 링크 http://127.0.0.1/rep1/seg3 에서 입수가능한 세그먼트의 경우, DASH 클라이언트 (110) 는 http://127.0.0.1/rep1/seg3 에 대한 요청을 포함하는 HTTP GET 요청을 구성하고 그 요청을 로컬 서버 유닛 (102) 에 제출한다. 로컬 서버 유닛 (102) 은 캐시 (104) 로부터 요청된 데이터를 취출하고, 그러한 요청들에 응답하여 데이터를 DASH 클라이언트 (110) 에 제공할 수도 있다.

도 3 은 본 개시의 기술에 따른 예시적인 웹 상호작용 트랙을 도시한 개념도이다. 대부분의 경우에, 웹 페이지 상호작용은 브라우저에서뿐만 아니라, 자립형 애플리케이션에서도 제공되어야 한다. 본 개시는 ISO BMFF 트랙 레벨에서 상호동작가능한 솔루션을 제공하는 것에 대한 예측되는 이점을 인식한다. 도 3 의 컴포넌트들은 일반적으로 도 1 의 클라이언트 디바이스 (40) 의 유사한 명칭의 컴포넌트들에 대응할 수도 있다.

ISO BMFF에 따라 파일 포맷 정보에서 일관된 방식으로 JavaScript 및 다른 동적 웹 데이터뿐만 아니라 HTML-5 데이터의 캐리지를 가능하게 함으로써, 가능한 솔루션이 제공될 수도 있다. 이러한 일관성은 상이한 사용 케이스들을 지원하고 더 광범위의 상호동작가능성을 제공할 것이다. 기본 개념이 도 3 에 도시된다. 트랙은 파일 포맷 정보로 캡슐화되어 웹 엔진에서 종료할 수도 있다. 이벤트들의 미디어로의 동기화를 가능하게 하기 위해, 이벤트들이 웹 엔진에 제공될 수도 있다.

트랙은 HTML-5 엔트리 페이지 (RAP/sync 샘플과 같은 것) 및 가능하게는 동기화되는 동적 이벤트를 포함할 수도 있다. 도 3 은 이를 핸들링하기 위한 하나의 예시적인 구현을 도시한다. 다른 예에서, ISO BMFF 는 브라우저에서 종료할 수도 있다. 자바스크립트 기반 파서는 HTML-5 데이터를 추출하고 역학관계 (dynamics) 를 제공할 수도 있는 반면, 비디오 및 오디오 트랙은 비디오 및 오디오 태그를 사용하여 핸들링될 수도 있다. DASH 및 CMAF 와의 사용은 웹 상호작용 트랙의 프래그먼트화된/세그먼트화된 버전을 제공하는 것에 의존할 수도 있다.

트랙은 HTML-5 및 JS 데이터로 제한될 수도 있으며, 모델은 특정 미디어 시간에, HTML-5 페이지가 렌더링되거나 또는 JavaScript 코드의 결과가 실행되는 것일 수도 있다. 각 이벤트에는 프리젠테이션 시간이 할당되며, 그 시간은 DOM (Document Object Model) 수정이 활성인 시간과 연관된다. 이는 또한 HTML-5 환경이 시작될 필요는 없지만, 클라이언트 디바이스가 웹 상호작용을 지원하지 않는 경우에 클라이언트 디바이스가 오직 비디오 및 오디오만을 제공할 수도 있는 것을 의미한다. 자립형 플레이어는 웹 상호작용 컨텐츠를 프로세싱하기 위해 웹 엔진으로 구성될 수도 있다. 제한된 세트의 피처들 및 API들 (Application Programming Interfaces) 은 웹 상호작용 컨텐츠를 제시하기에 충분할 수도 있다.

이러한 기술을 구현할 때 특정 문제가 고려될 수도 있다:

1) 웹 페이지와 비디오 사이에 바인딩 (binding) 이 있을 수도 있다. 즉, 비디오/오디오 태그를 비디오 트랙에 연결하는 HTML-5 비디오 (및 오디오) 태그가 웹 페이지 및 데이터에 있을 수도 있다. 이러한 연결은 트랙 참조들에 의해 실행될 수도 있다. 예를 들어, "<video src="trackid://<trackid>">" 와 같은 데이터가 제공될 수도 있다.

2) 예를 들어, 클라이언트 디바이스가 프래그먼트별로 작업하는 경우, 미디어 소스 확장 (MSE) 버퍼가 추가될 수도 있다. MSE 버퍼는 애플리케이션에 따라 달라질 수도 있지만, 그 바인딩은 파일로부터의 ISO BMFF 프래그먼트들이 MSE 버퍼에 부가될 수 있게 할 수도 있다.

3) 일부 예에서, 다수의 HTML-5 트랙들이 있을 수도 있다. 이러한 예에서, 다양한 HTML-5 트랙들이 상이한 기능성들에 전용될 수도 있다. 이러한 예에서, 타입은 각각의 HTML-5 트랙들에 대해서도 설명될 수도 있다.

4) 웹 엔진은 HTML-5 트랙을 사용하기 위한 다양한 기능 및 성능을 제공할 수도 있다. HTML-5 트랙은 상이한 API 및 기능을 사용할 수도 있으며 상호작용 트랙을 렌더링하는데 필요한 웹 엔진 성능을 시그널링하기 위한 데이터가 있을 수도 있다.

5) 동기 샘플, 랜덤 액세스 포인트 등과 같은 전형적인 ISO BMFF 기능들이 추가로 정의될 수도 있다.

6) 상기 예는 시각적 양태들로 제한되지만, HTML-5 제어 API들에 기초한 오디오 엘리먼트와의 상호작용을 허용하기 위해 유사한 기술이 수행될 수도 있다.

7) 환경은 또한 추가로 정의될 수도 있다. 2 가지 예시적인 모델들은 브라우저에서 재생하는 것, 및 웹 도구들을 포함하는 애플리케이션에서 재생하는 것을 포함한다. 실용적이고 조정적인 한계들이 있다 (예를 들어, MSE 는 인식되지 않은 트랙들을 갖는 프리젠테이션들이 무시된다고 주장한다).

8) Javascript 가 사용하는 리소스들이 또한 정의될 수도 있으며, 이러한 리소스들을 참조하는 규범적인 방식도 정의될 수도 있다. 이러한 정의들에 대해 웹 아카이브 블롭들이 사용될 수도 있다.

도 4 는 예시적인 멀티미디어 콘텐츠 (120) 의 엘리먼트들을 도시하는 개념도이다. 멀티미디어 콘텐츠 (120) 는 멀티미디어 콘텐츠 (64) (도 1), 또는 저장 매체 (62) 에 저장된 다른 멀티미디어 콘텐츠에 대응할 수도 있다. 도 4 의 예에서는, 멀티미디어 콘텐츠 (120) 는 미디어 프리젠테이션 디스크립션 (MPD) (122) 및 복수의 레프리젠테이션들 (124A-124N) (레프리젠테이션들 (124)) 을 포함한다. 레프리젠테이션 (124A) 은 옵션의 헤더 데이터 (126) 및 세그먼트들 (128A-128N) (세그먼트들 (128)) 을 포함하는 한편, 레프리젠테이션 (124N) 은 옵션의 헤더 데이터 (130) 및 세그먼트들 (132A-132N) (세그먼트들 (132)) 을 포함한다. 문자 N 은, 편의 상, 레프리젠테이션들 (124) 의 각각에서 마지막 무비 프래그먼트를 지정하는데 사용된다. 일부 예들에 있어서, 레프리젠테이션들 (124) 사이에 상이한 수들의 무비 프래그먼트들이 존재할 수도 있다.

MPD (122) 는 레프리젠테이션들 (124) 로부터 별개인 데이터 구조를 포함할 수도 있다. MPD (122) 는 도 1 의 매니페스트 파일 (66) 에 대응할 수도 있다. 마찬가지로, 레프리젠테이션들 (124) 은 도 2 의 레프리젠테이션들 (68) 에 대응할 수도 있다. 일반적으로, MPD (122) 는 레프리젠테이션들 (124) 의 특성들을 일반적으로 기술하는 데이터, 예컨대 코딩 및 렌더링 특성들, 적응 세트들, MPD (122) 가 대응하는 프로파일, 텍스트 타입 정보, 카메라 각도 정보, 등급 정보, 트릭 모드 정보 (예를 들어, 시간적 서브-시퀀스들을 포함하는 레프리젠테이션들을 표시하는 정보) 및/또는 원격 주기들을 취출하기 위한 (예를 들어, 재생 도중에 미디어 콘텐츠 내로의 타겟화된 광고 삽입을 위한) 정보를 포함할 수도 있다.

존재할 경우에, 헤더 데이터 (126) 는 세그먼트들 (128) 의 특성들, 예를 들어, 랜덤 액세스 포인트들 (RAP) 들 (스트림 액세스 포인트 (SAP) 이라고도 지칭됨) 의 시간적 로케이션들, 세그먼트들 (128) 중 어느 것이 랜덤 액세스 포인트들을 포함하는지, 세그먼트들 (128) 내의 랜덤 액세스 포인트들에 대한 바이트 오프셋들, 세그먼트들 (128) 의 URL (uniform resource locator) 들, 또는 세그먼트들 (128) 의 다른 양태들을 기술할 수도 있다. 존재할 경우에, 헤더 데이터 (130) 는 세그먼트들 (132) 에 대한 유사한 특성들을 기술할 수도 있다. 추가적으로 또는 대안적으로, 이러한 특성들은 MPD (122) 내에 완전하게 포함될 수도 있다.

세그먼트들 (128, 132) 은 하나 이상의 코딩된 비디오 샘플들을 포함하는데, 이들 각각은 비디오 데이터의 프레임들 또는 슬라이스들을 포함할 수도 있다. 세그먼트들 (128) 의 코딩된 비디오 샘플들 각각은 유사한 특성들, 예를 들어, 높이, 폭, 및 대역폭 요건들을 가질 수도 있다. 비록 이러한 데이터가 도 4 의 예에서는 예시되지 않지만, 이러한 특성들은 MPD (122) 의 데이터에 의하여 기술될 수도 있다. MPD (122) 는, 본 개시에서 기술되는 시그널링된 정보 중 임의의 것 또는 전부가 추가된, 3GPP 명세에 의하여 기술되는 바와 같은 특성들을 포함할 수도 있다.

세그먼트들 (128, 132) 의 각각은 고유한 URL (uniform resource locator) 와 연관될 수도 있다. 따라서, 세그먼트들 (128, 132) 의 각각은 DASH 와 같은 스트리밍 네트워크 프로토콜을 이용하여 독립적으로 취출가능할 수도 있다. 이러한 방식으로, 클라이언트 디바이스 (40) 와 같은 목적지 디바이스는, HTTP GET 요청을 이용하여 세그먼트들 (128 또는 132) 을 취출할 수도 있다. 일부 예들에 있어서, 클라이언트 디바이스 (40) 는 HTTP 부분 GET 요청들을 이용하여 세그먼트들 (128 또는 132) 의 특정 바이트 범위들을 취출할 수도 있다.

도 5 는 레프리젠테이션의 세그먼트, 이를테면 도 4 의 세그먼트들 (114, 124) 중 하나의 세그먼트에 대응할 수도 있는, 예시적인 비디오 파일 (150) 의 엘리먼트들을 도시하는 블록도이다. 세그먼트들 (128, 132) 의 각각은 도 5 의 예에서 도시된 데이터의 배열에 실질적으로 부합하는 데이터를 포함할 수도 있다. 비디오 파일 (150) 은 세그먼트를 캡슐화하는 것으로 말해질 수도 있다. 상기 설명된 바와 같이, ISO 베이스 미디어 파일 포맷 및 그 확장들에 따른 비디오 파일들은 "박스들" 로서 지칭되는 일련의 오브젝트들에 데이터를 저장한다. 도 5 의 예에서, 비디오 파일 (150) 은 파일 타입 (FTYP) 박스 (152), 무비 (MOOV) 박스 (154), 세그먼트 인덱스 (sidx) 박스 (162), 무비 프래그먼트 (MOOF) 박스 (164) 및 무비 프래그먼트 랜덤 액세스 (MFRA) 박스 (166) 를 포함한다. 도 5 가 비디오 파일의 일 예를 나타내지만, 다른 미디어 파일들이 ISO 기본 미디어 파일 포맷 및 그것의 확장에 따른, 비디오 파일 (150) 의 데이터와 유사하게 구조화된 다른 타입들의 미디어 데이터 (예컨대, 오디오 데이터, 타이밍된 텍스트 데이터 등) 을 포함할 수도 있다는 것이 이해되어야 한다.

파일 타입 (FTYP) 박스 (152) 는 비디오 파일 (150) 에 대한 파일 타입을 일반적으로 기술한다. 파일 타입 박스 (152) 는, 비디오 파일 (150) 을 위한 최상의 이용을 기술하는 사양을 식별하는 데이터를 포함할 수도 있다. 파일 타입 박스 (152) 는 대안적으로, MOOV 박스 (154), 무비 프래그먼트 박스들 (164), 및/또는 MFRA 박스 (166) 전에 배치될 수도 있다.

일부 예들에 있어서, 비디오 파일 (150) 과 같은 세그먼트는, FTYP 박스 (152) 전에 MPD 업데이트 박스 (도시 안됨) 를 포함할 수도 있다. MPD 업데이트 박스는, 비디오 파일 (150) 을 포함하는 레프리젠테이션에 대응하는 MPD 가 그 MPD 를 업데이트하기 위한 정보와 함께 업데이트될 것임을 표시하는 정보를 포함할 수도 있다. 예를 들어, MPD 업데이트 박스는 MPD 를 업데이트하는데 사용될 리소스에 대한 URI 또는 URL 을 제공할 수도 있다. 다른 예로서, MPD 업데이트 박스는 MPD 를 업데이트하기 위한 데이터를 포함할 수도 있다. 일부 예들에서, MPD 업데이트 박스는 비디오 파일 (150) 의 세그먼트 타입 (STYP) 박스 (도시되지 않음) 를 바로 뒤따를 수도 있으며, 여기서 STYP 박스는 비디오 파일 (150) 에 대한 세그먼트 타입을 정의할 수도 있다. 이하 더 상세히 논의되는 도 7 은 MPD 업데이트 박스에 대한 추가의 정보를 제공한다.

MOOV 박스 (154) 는, 도 5 의 예에서, 무비 헤더 (MVHD) 박스 (156), 트랙 (TRAK) 박스 (158), 및 하나 이상의 무비 확장 (MVEX) 박스들 (160) 을 포함한다. 일반적으로, MVHD 박스 (156) 는 비디오 파일 (150) 의 일반 특성들을 기술할 수도 있다. 예를 들어, MVHD 박스 (156) 는 비디오 파일 (150) 이 원래 생성되었을 때, 비디오 파일 (150) 이 마지막으로 수정되었을 때, 비디오 파일 (150) 에 대한 타임스케일, 비디오 파일 (150) 에 대한 재생의 지속기간을 기술하는 데이터, 또는 비디오 파일 (150) 을 일반적으로 기술하는 다른 데이터를 포함할 수도 있다.

TRAK 박스 (158) 는 비디오 파일 (150) 의 트랙에 대한 데이터를 포함할 수도 있다. TRAK 박스 (158) 는 TRAK 박스 (158) 에 대응하는 트랙의 특성들을 기술하는 트랙 헤더 (TKHD) 박스를 포함할 수도 있다. 일부 예들에 있어서, TRAK 박스 (158) 는 코딩된 비디오 픽처들을 포함할 수도 있는 한편, 다른 예들에 있어서, 트랙의 코딩된 비디오 픽처들은 TRAK 박스 (158) 및/또는 sidx 박스들 (162) 의 데이터에 의해 참조될 수도 있는 무비 프래그먼트들 (164) 에 포함될 수도 있다.

일부 예들에 있어서, 비디오 파일 (150) 은 1 초과의 트랙을 포함할 수도 있다. 이에 따라, MOOV 박스 (154) 는 비디오 파일 (150) 에 트랙들의 수와 동일한 수의 TRAK 박스들을 포함할 수도 있다. TRAK 박스 (158) 는 비디오 파일 (150) 의 대응하는 트랙의 특성들을 기술할 수도 있다. 예를 들어, TRAK 박스 (158) 는 대응하는 트랙에 대한 시간적 및/또는 공간적 정보를 기술할 수도 있다. MOOV 박스 (154) 의 TRAK 박스 (158) 에 유사한 TRAK 박스가, 캡슐화 유닛 (30) (도 4) 이 비디오 파일, 이를테면 비디오 파일 (150) 에 파라미터 세트 트랙을 포함시키는 경우, 파라미터 세트 트랙의 특성들을 기술할 수도 있다. 캡슐화 유닛 (30) 은, 파라미터 세트 트랙을 기술하는 TRAK 박스 내의 파라미터 세트 트랙에서 시퀀스 레벨 SEI 메시지들의 존재를 시그널링할 수도 있다.

MVEX 박스들 (160) 은, 예컨대, 비디오 파일 (150) 이, 만약 있다면, MOOV 박스 (154) 내에 포함된 비디오 데이터에 추가하여, 무비 프래그먼트들 (164) 을 포함한다는 것을 시그널링하기 위해, 대응하는 무비 프래그먼트들 (164) 의 특성들을 기술할 수도 있다. 비디오 데이터를 스트리밍하는 맥락에서, 코딩된 비디오 픽처들은 MOOV 박스 (154) 에 보다는 무비 프래그먼트들 (164) 에 포함될 수도 있다. 이에 따라, 모든 코딩된 비디오 샘플들은 MOOV 박스 (154) 에 보다는 무비 프래그먼트들 (164) 에 포함될 수도 있다.

MOOV 박스 (154) 는 비디오 파일 (150) 에서의 무비 프래그먼트들 (164) 의 수와 동일한 수의 MVEX 박스들 (160) 을 포함할 수도 있다. MVEX 박스들 (160) 의 각각은 무비 프래그먼트들 (164) 중 대응하는 무비 프래그먼트의 특성들을 기술할 수도 있다. 예를 들어, 각각의 MVEX 박스는, 무비 프래그먼트들 (164) 중 대응하는 무비 프래그먼트에 대한 시간적 지속기간을 기술하는 MEHD (movie extends header box) 박스를 포함할 수도 있다.

위에서 언급된 바와 같이, 캡슐화 유닛 (30) 은 실제 코딩된 비디오 데이터를 포함하지 않는 비디오 샘플에 시퀀스 데이터 세트를 저장할 수도 있다. 비디오 샘플은 특정 시간 인스턴스에서의 코딩된 픽처의 레프리젠테이션인 액세스 유닛에 일반적으로 대응할 수도 있다. AVC 의 맥락에서, 코딩된 픽처는 액세스 유닛의 모든 화소들을 구축하기 위한 정보를 포함하는 하나 이상의 VCL NAL 유닛들과, 다른 연관된 비-VCL NAL 유닛들, 이를테면 SEI 메시지들을 포함한다. 따라서, 캡슐화 유닛 (30) 은 시퀀스 레벨 SEI 메시지들을 포함할 수도 있는 시퀀스 데이터 세트를 무비 프래그먼트들 (164) 중 하나의 무비 프래그먼트에 포함시킬 수도 있다. 캡슐화 유닛 (30) 은, 무비 프래그먼트들 (164) 중 하나의 무비 프래그먼트에 대응하는 MVEX 박스들 (160) 중 하나의 MVEX 박스 내에서 무비 프래그먼트들 (164) 중 하나의 무비 프래그먼트에 존재하는 것으로서의 시퀀스 데이터 세트 및/또는 시퀀스 레벨 SEI 메시지들의 존재를 추가로 시그널링할 수도 있다.

SIDX 박스들 (162) 은 비디오 파일 (150) 의 옵션적 엘리먼트들이다. 다시 말하면, 3GPP 파일 포맷, 또는 다른 이러한 파일 포맷들에 부합하는 비디오 파일들은 반드시 SIDX 박스들 (162) 을 포함하는 것은 아니다. 3GPP 파일 포맷의 예에 따라, SIDX 박스는 세그먼트 (예컨대, 비디오 파일 (150) 내에 포함된 세그먼트) 의 서브-세그먼트를 식별하는데 사용될 수도 있다. 3GPP 파일 포맷은 서브-세그먼트를 "대응하는 미디어 데이터 박스(들)를 갖는 하나 이상의 연속적인 무비 프래그먼트 박스들 박스들의 독립식 세트 및 무비 프래그먼트 박스에 의해 참조되는 데이터를 포함하는 미디어 데이터 박스가 그 무비 프래그먼트 박스를 뒤따라야만 하고 동일한 트랙에 관한 정보를 포함하는 다음 무비 프래그먼트 박스에 선행해야만 하는 것" 으로서 정의한다. 3GPP 파일 포맷은 SIDX 박스가 "박스에 의해 문서화된 (서브)세그먼트의 참조들 대 서브세그먼트들의 시퀀스를 포함한다" 는 것을 또한 표시한다. 참조된 서브세그먼트들은 프리젠테이션 시간에서 연속적이다. 유사하게, 세그먼트 인덱스 박스에 의해 참조되는 바이트들은 세그먼트 내에서 항상 인접한다. 참조된 사이즈는 참조된 자료에서의 바이트들의 수의 카운트를 제공한다.

SIDX 박스들 (162) 은 일반적으로, 비디오 파일 (150) 에 포함된 세그먼트의 하나 이상의 서브-세그먼트들을 나타내는 정보를 제공한다. 예를 들면, 그러한 정보는 서브-세그먼트들이 시작하고/하거나 종료하는 재생 시간들, 서브-세그먼트들에 대한 바이트 오프셋들, 서브-세그먼트들이 스트림 액세스 포인트 (SAP) 를 포함하는지 (예컨대 그 SAP 로 시작하는지) 의 여부, SAP 에 대한 타입 (예컨대, SAP 가 순시 디코더 리프레시 (IDR) 픽처인지, 클린 랜덤 액세스 (CRA) 픽처인지, 브로큰 링크 액세스 (BLA) 픽처인지 등), 서브-세그먼트에서의 (재생 시간 및/또는 바이트 오프셋의 관점에서의) SAP 의 포지션 등을 포함할 수도 있다.

무비 프래그먼트들 (164) 은 하나 이상의 코딩된 비디오 픽처들을 포함할 수도 있다. 일부 예들에 있어서, 무비 프래그먼트들 (164) 은 하나 이상의 픽처 그룹들 (GOP들) 을 포함할 수도 있으며, 그 GOP들의 각각은 다수의 코딩된 비디오 픽처들, 예컨대, 프레임들 또는 픽처들을 포함할 수도 있다. 부가적으로, 상기 설명된 바와 같이, 무비 프래그먼트들 (164) 은 일부 예들에 있어서 시퀀스 데이터 세트들을 포함할 수도 있다. 무비 프래그먼트들 (164) 의 각각은 무비 프래그먼트 헤더 박스 (MFHD, 도 5 에는 도시되지 않음) 를 포함할 수도 있다. MFHD 박스는 대응하는 무비 프래그먼트 박스들의 특성들, 이를테면 무비 프래그먼트 박스들에 대한 시퀀스 번호를 기술할 수도 있다. 무비 프래그먼트들 (164) 은 비디오 파일 (150) 에서 시퀀스 번호의 순서로 포함될 수도 있다.

MFRA 박스 (166) 는 비디오 파일 (150) 의 무비 프래그먼트들 (164) 내의 랜덤 액세스 포인트들을 기술할 수도 있다. 이는 비디오 파일 (150) 에 의해 캡슐화된 세그먼트 내에서 특정 시간적 위치들 (즉, 재생 시간들) 에 대한 탐색들을 수행하는 것과 같은, 트릭 모드들을 수행하는 것을 보조할 수도 있다. MFRA 박스 (166) 는 일반적으로 옵션적이며, 일부 예들에 있어서, 비디오 파일들에 포함될 필요가 없다. 마찬가지로, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스는, 비디오 파일 (150) 의 비디오 데이터를 정확하게 디코딩하고 디스플레이하기 위해 MFRA 박스 (166) 를 반드시 참조할 필요는 없다. MFRA 박스 (166) 는 비디오 파일 (150) 의 트랙들의 수와 동일한, 또는 일부 예들에 있어서, 비디오 파일 (150) 의 미디어 트랙들 (예컨대, 비-힌트 트랙들) 의 수와 동일한 수의 트랙 프래그먼트 랜덤 액세스 (TFRA) 박스들 (도시 안됨) 을 포함할 수도 있다.

일부 예들에 있어서, 무비 프래그먼트들 (164) 은 IDR 픽처들과 같은 하나 이상의 스트림 액세스 포인트들 (SAP들) 을 포함할 수도 있다. 마찬가지로, MFRA 박스 (166) 는 SAP들의 비디오 파일 (150) 내의 위치들의 표시들을 제공할 수도 있다. 따라서, 비디오 파일 (150) 의 시간적 서브-시퀀스가 비디오 파일 (150) 의 SAP들로부터 형성될 수도 있다. 시간적 서브-시퀀스는 SAP들에 의존하는 P-프레임들 및/또는 B-프레임들과 같은 다른 화상들을 또한 포함할 수도 있다. 시간적 서브-시퀀스의 프레임들 및/또는 슬라이스들은 서브-시퀀스의 다른 프레임들/슬라이스들에 의존하는 시간적 서브-시퀀스의 프레임들/슬라이스들이 적절히 디코딩될 수 있도록 세그먼트들 내에 배열될 수도 있다. 예를 들어, 데이터의 계층적 배열에서, 다른 데이터에 대한 예측을 위해 사용되는 데이터가 시간적 서브-시퀀스에 또한 포함될 수도 있다.

도 6 은 본 개시의 기술에 따른 예시적인 수신기 데이터 프로세싱 모델을 도시하는 개념도이다. 특히, 도 6 은 예를 들어, ISOBMFF 파일, CMAF 프리젠테이션, 또는 DASH 미디어 프리젠테이션을 나타낼 수도 있는 미디어 컨텐츠 (180) 에 대한 예시적인 데이터 프로세싱 모델을 도시한다. 이 예에서, 미디어 컨텐츠 (180) 는 오디오 트랙 (182), 비디오 트랙 (184), 및 웹 컨텐츠 트랙 (186) 을 포함하는 복수의 트랙들을 포함한다. 집합적으로, 오디오 트랙 (182) 및 비디오 트랙 (184) 은 오디오/비디오 (AV) 트랙들로 지칭될 수도 있다. 웹 컨텐츠 트랙 (186) 은 오디오 트랙 (182) 및 비디오 트랙 (184) 의 오디오 및/또는 비디오 데이터와 시간 동기화된 웹 컨텐츠를 포함하는 웹/html-5 트랙에 대응할 수도 있다. 또한, 웹 컨텐츠 트랙 (186) 은 AV 트랙들과의 동기화 정보를 나타내는 데이터를 포함할 수도 있다. 이 모델은 본 개시의 기술에 따라 웹 트랙을 어드레싱하고 제공하는데 사용될 수도 있다.

도 1 의 클라이언트 디바이스 (40) 는 도 6 의 클라이언트 디바이스 (190) 의 예시적인 모델에 따라 구성될 수도 있고, 및/또는 다른 유사한 클라이언트 디바이스들이 이 모델에 따라 구성될 수도 있다. 특히, 이 예에서, 클라이언트 디바이스 (190) 는 오디오 트랙 핸들러 (192), 비디오 트랙 핸들러 (194), 웹 컨텐츠 트랙 핸들러 (196), 오디오 디코더 (198), 비디오 디코더 (200), 웹 소켓 서버 (202), HTTP 서버 캐시 (204), HTML-5 프로세서 (210), 및 미디어 렌더러 (220) 를 포함한다. HTML-5 프로세서 (210) 는 웹 소켓 클라이언트 (212) 및 HTTP 클라이언트 (214) 를 포함한다. 웹 소켓 서버 (202) 및 웹 소켓 클라이언트 (212) 는 WebSocket API 접속 (216) 을 통해 통신가능하게 커플링되는 반면, HTTP 서버 캐시 (204) 및 HTTP 클라이언트 (214) 는 XML HTTP 요청 (XHR) 접속 (218) 을 통해 통신가능하게 커플링된다.

오디오 트랙 (182), 비디오 트랙 (184), 및 웹 컨텐츠 트랙 (186) (예를 들어, HTML-5 (htm5) 트랙) 이 ISO BMFF 파일, CMAF 프리젠테이션, 또는 DASH 미디어 프리젠테이션과 같은 미디어 컨텐츠 (180) 에서 제공된다고 가정하자. 이것은 트랙들이 시간 정렬되고, "프레젠테이션" 에서의 구성 및 프리젠테이션 시간 정보뿐만 아니라, 디코드 시간을 사용하여 "동기화된 방식" 으로 제시될 수도 있음을 의미한다. 모든 트랙들에 대해, 무비 헤더 및 트랙 헤더들에서의 정보는 적절한 트랙 핸들러 (예를 들어, 오디오 트랙 핸들러 (192), 비디오 트랙 핸들러 (194), 및 웹 컨텐츠 트랙 핸들러 (196)) 및 미디어 디코더 및 프로세서 (예를 들어, 오디오 디코더 (198), 비디오 디코더 (200), 웹 소켓 서버 (202), 및 HTML-5 프로세서 (210)) 를 초기화하는데 사용될 수도 있다. 오디오 및 비디오의 경우, 정규 프로세스가 적용될 수도 있다. 디코더 (예를 들어, 오디오 디코더 (198) 및 비디오 디코더 (200)) 를 개시함으로써, 통지된 디코드 시간에 샘플을 디코더로 제공할 수 있게 하는 "소켓" 이 가능할 수도 있다.

디코더는 대응하는 미디어 샘플 (예를 들어, 오디오 샘플 또는 비디오 샘플) 을 디코딩하기 위해 디코드 시간의 스케줄링을 사용할 수도 있다. 프리젠테이션 및 구성 시간에 대한 정보는 미디어의 정확한 프리젠테이션을 위해 사용될 수 있다. 프리젠테이션은 미디어 시간들에서 모든 시간을 기술할 수도 있고, 프리젠테이션 환경의 엘리먼트들에 의해 실시간으로의 재생 및 매핑이 수행될 수도 있다. 프로세싱 모델은 ISO BMFF 에 포함된 미디어 시간에 의해 가이드될 수도 있다.

오디오 트랙 (182) 및 비디오 트랙 (184) 은 웹 컨텐츠 트랙 (186) 을 무시하고, 정규 AV 프리젠테이션으로서 자립형으로 사용될 수도 있다. 그러나, 가능한 디바이스는 또한 웹 컨텐츠 트랙 (186) (예를 들어, htm5 트랙) 을 사용할 수도 있다. 위에서 논의된 바와 같이, 상이한 플레이어 및 서비스 모델들이 고려될 수도 있으며, 즉, AV 프리젠테이션이 시작되고 그 후에 htm5 트랙이 추가될 수도 있거나, 또는 웹 컨텐츠 트랙 (186) 이 시작 시에 사용될 수도 있고 AV 트랙들을 통합할 수도 있다. ISO BMFF 의 디스크립션은 이것과 독립적이지만, 간결성을 위해, 지금부터 웹 컨텐츠 트랙 (186) (예를 들어, HTML-5 프리젠테이션) 은 마스터 트랙이고, 먼저 시작되고, HTML-5 에서 비디오 및 오디오 엘리먼트들을 사용함으로써 모든 포함된 AV 트랙들에 대한 연관을 제공한다고 가정된다. 웹 컨텐츠 트랙 (186) 은 트랙을 샘플 엔트리를 포함하는 htm5 트랙으로서 식별하는 데이터를 포함할 수도 있다. 또한, HTML-5 에서 오디오 및 비디오 엘리먼트들에 대한 AV 트랙들의 바인딩으로서 작용하는 데이터가 제공될 수도 있다. 자막 등과 같은 다른 미디어 엘리먼트들뿐만 아니라 다수의 오디오 및 비디오 소스들에 대한 추가 트랙 바인딩들이 존재할 수도 있다.

웹 컨텐츠 트랙 (186) 에 대해 3 가지 예시적인 데이터 타입들이 중요할 수도 있다:

1) 잠재적으로 JavaScript 등과 같은 동적 양태들을 포함하는, HTML-5 페이지의 초기 시작. 이 정보는 정적일 수도 있거나 (비-타이밍된 아이템) 또는 프레젠테이션 시간 0 에서의 샘플로 간주될 수도 있다. 비디오 및 오디오 프리젠테이션은, 예를 들어, HTML-5 페이지보다 이후에 미디어 타임 델타 방식으로 시작될 수도 있다. 편집 리스트 통해 오디오 및 비디오의 프리젠테이션의 조정을 요구할 수도 있다.

2) 콘텐츠 작성자 스케줄에 기초하여 특정 미디어 시간에 HTML-5 프로세서로 "푸시"되는 임의의 데이터. 예를 들어, 이는 미디어의 재생과 동기화된 DOM 에서의 변경들을 트리거할 수도 있다. 특정 미디어 시간에 푸시된 이러한 데이터는 "특정 미디어 시간" 이 디코드 시간인, "샘플" 로 간주될 수도 있다.

3) HTML-5 프로세서에서 프로세싱을 위해 사용가능하지만, 오직 동적 DOM 업데이트들에 기초하여 프로세서에 의해 또는 상호작용에 의해 "요청"될 수도 있는 데이터. 이러한 데이터는 통상적으로 오직 프리젠테이션에서 특정 미디어 시간 주기 (또는 다수의 주기들) 내에서만 요청될 수도 있다. 이러한 미디어 시간 주기 이외에, 이러한 데이터는 관련이 없는 것으로 간주될 수도 있다.

HTML-5 프로세서 (210) 가 이러한 데이터를 취출하기 위해, 상이한 타입의 HTML-5 프로세스들 및 API들이 고려될 수도 있다. 상기 포인트 1 의 시작 페이지는 HTML-5 프로세서 (210) 를 시작하기 위한 데이터를 포함할 수도 있다. 이러한 정보는 웹 컨텐츠 트랙 (186) 의 트랙 헤더에서 비-타이밍된 아이템들 또는 초기 랜덤 액세스 샘플로서 사용가능할 수도 있다. 상기 포인트 2 의 모델을 따르는 데이터는 WebSocket API 접속 (216) 을 사용함으로써 쉽게 푸시될 수도 있다. HTML-5 프로세서 (210) 는 WebSocket 클라이언트, 예를 들어 웹 소켓 클라이언트 (212) 로서 작용할 수도 있고, 클라이언트 측 API 는 다음과 같이 간단할 수도 있다:

웹 컨텐츠 트랙 핸들러 (196) 는 전용 웹 소켓 어드레스, 예를 들어 "ws://ExampleLocalWebSocketServer" 소켓을 통해 액세스가능한 웹 소켓 서버, 예를 들어 웹 소켓 서버 (202) 를 에뮬레이트할 수도 있다. 예를 들어, "전송" 방법을 사용하여, 클라이언트 측에서 이를 핸들링하기 위해 상기 함수가 호출될 수도 있다. 디바이스에서 HTML-5 페이지와 WebSocketServer 간의 바인딩이 적절하게 핸들링되어야 한다.

상기 포인트 3 을 따르는 데이터는 WebSocket API 접속 (216) 에서 반드시 "푸시"될 필요는 없지만, 명확한 (well-defined) "http://" 라벨 (또는 "http-라벨") 을 통해 특정 시간부터 사용가능할 수도 있다. http-라벨을 사용함으로써, HTML-5 프로세서 (210) 는 XHR 접속 (218) 과 같은 XHR API들을 사용하여 데이터에 액세스할 수 있다. 데이터는 식별된 라벨에서 디코드 시간부터 HTML-5 프로세서가 액세스할 수 있는 샘플로 간주된다. 이는 샘플의 사용가능성이 즉각적인 경우를 제외하고, 즉 오브젝트가 전달된 후에, 3GPP 에 문서화된 FLUTE 동작과 유사하다. 파일 전달 테이블 (FDT) 은 라벨에 관한 정보뿐만 아니라, 컨텐츠 타입 등과 같은 다른 정보를 제공한다. 유사한 정보가 제공될 수도 있다. 궁극적으로, 미디어 렌더러 (220) 는 본 개시의 기술들에 따라, 오디오 트랙 (182), 비디오 트랙 (184), 및 웹 컨텐츠 트랙 (186) 의 오디오 및 비디오 데이터를 시간 동기화 방식으로 제시할 수도 있다.

이러한 방식으로, 도 6 은 미디어 데이터를 취출하기 위한 디바이스의 일 예를 나타내고, 상기 디바이스는 미디어 데이터를 저장하도록 구성된 메모리, 및 회로부에 구현된 하나 이상의 프로세서들을 포함하며, 상기 하나 이상의 프로세서들은, 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하고, 그리고 미디어 데이터 및 웹 컨텐츠를 제시하도록 구성되며, 상기 하나 이상의 프로세서들은 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하도록 구성된다.

도 7 은 본 개시의 기술에 따른 예시적인 프로세싱 모델을 도시하는 개념도이다. 특히, 도 7 은 예를 들어, ISOBMFF 파일, CMAF 프리젠테이션, 또는 DASH 미디어 프리젠테이션을 나타낼 수도 있는 미디어 컨텐츠 (230) 에 대한 예시적인 데이터 프로세싱 모델을 도시한다. 이 예에서, 미디어 컨텐츠 (230) 는 오디오 트랙 (232), 비디오 트랙 (234), 및 웹 컨텐츠 트랙 (236) 을 포함하는 복수의 트랙들을 포함한다. 집합적으로, 오디오 트랙 (232) 및 비디오 트랙 (234) 은 오디오/비디오 (AV) 트랙들로 지칭될 수도 있다. 웹 컨텐츠 트랙 (236) 은 오디오 트랙 (232) 및 비디오 트랙 (234) 의 오디오 및/또는 비디오 데이터와 시간 동기화된 웹 컨텐츠를 포함하는 웹/html-5 트랙에 대응할 수도 있다. 또한, 웹 컨텐츠 트랙 (236) 은 AV 트랙들과의 동기화 정보를 나타내는 데이터를 포함할 수도 있다.

클라이언트 디바이스 (40) 는 이러한 또는 유사한 프로세싱 모델을 사용하여 웹 컨텐츠 트랙 (236) 의 웹 트랙 데이터를 프로세싱하도록 구성될 수도 있다. 즉, 클라이언트 디바이스 (40) 는 도 7 의 클라이언트 디바이스 (240) 의 모델에 따라 구성될 수도 있다. 이 예에서, 클라이언트 디바이스 (240) 는 오디오 트랙 핸들러 (242), 비디오 트랙 핸들러 (244), 웹 컨텐츠 트랙 핸들러 (246), 오디오 디코더 (248), 비디오 디코더 (250), 인터프리터 (260), 및 미디어 렌더러 (270) 를 포함한다.

개념적 접근방식은 미디어 타이밍에 기초하여 논의되며, 즉, 데이터는 파일에 저장된다. 그러나, 이러한 타이밍 개념들은 예를 들어, DASH 에서 실행되는 것과 같이, 데이터가 스트리밍될 경우 실시간 타임라인에 놓일 수도 있다. 도 7 의 예시적인 모델은 모든 데이터가 트랙 핸들러, 예를 들어 웹 컨텐츠 트랙 핸들러 (246) 에 사용가능하다고 가정하면, 트랙 프로세싱에 집중한다. 전달 특정 양태들은 아래에서 더 자세히 논의된다.

요약하면, 도 7 과 관련하여, 3 가지 타입의 샘플 데이터는 하나의 트랙에서 또는 생성되고 구별될 수도 있는 다수의 트랙들에서 제공될 수도 있다:

1) 초기 시작 데이터 및 "전체" 및 "중복" 랜덤 액세스 데이터. 이러한 데이터는 HTML-5 프로세서를 시작할 수도 있거나 또는 이후 미디어 시간에 HTML-5 트랙에 랜덤하게 액세스하는데 사용될 수 있다. DOM 리로딩을 회피하기 위해, 랜덤 액세스는 중복될 수도 있다. 그러나, "에러 케이스" 를 해결하기 위해, 시작 데이터를 푸시하고, WebSocket 접속을 사용하지 않고 페이지 리로드를 시행하는 것이 설계시 고려될 수도 있다.

2) 디코드 시간에, 초기에 시작된 HTML-5 프로세싱 데이터의 부분인 확립된 WebSocketClient 로 푸시되는 샘플들. 샘플들은 푸시되는 것으로 식별되어야할 수도 있다. 다수의 WebSocket들이 생성될 수도 있다. 다수의 WebSocket들이 제공되는 경우, 바인딩이 또한 제공될 수도 있다.

3) 브라우저가 기존 XmlHttpRequest API들을 사용하여 오브젝트들을 수집하는 것을 허용할 때 명확한 "http://" 라벨에서 디코드 시간부터 오브젝트들로 사용가능한 샘플들. 캐싱을 최적화하기 위해 추가의 메타데이터가 제공될 수도 있다. 샘플들은 파일에 포함될 수도 있거나 외부 데이터 참조들이 사용될 수도 있음을 유의한다. 후자의 경우, XHR 요청은 "파일" 에서 종료하는 것이 아니라 네트워크로 포워딩될 것이다.

일반적으로, 완전한 DOM 리로드를 회피하기 위해, 오직 "중복" 동기 샘플들만이 제공되어야 한다.

전달이 포함되면, 샘플 디코드 시간은 전달 표시로서 기능할 뿐만 아니라, 오브젝트가 수신되어야 하는 (미디어 타임라인 상의) 최신 시간에 의해 정보를 제공할 수도 있다. 비디오 및 오디오 엘리먼트는 더 이상 단일 리소스를 가리킬 필요가 없지만, MSE 및 트랙 버퍼를 사용하여 미디어 세그먼트들을 트랙 버퍼에 부가할 수도 있다.

도 7 의 예에서, 웹 컨텐츠 트랙 핸들러 (246) 는 Javascript 에서 HTML-5 트랙 핸들러일 수도 있다. 도 7 의 웹 컨텐츠 트랙 핸들러 (246) 는 예를 들어, HTML-5 트랙 핸들러가 자연적으로 사용가능한 경우, 하나의 예시적인 구현이다. 이는 예를 들어, 간단한 HTML-5 정보가 전송되는 타입 1 클라이언트에 중요할 수도 있으며, 가능하게는 오직 시작 페이지 및 상호작용 데이터만이 푸시 메커니즘 없이 XHR 을 통해 액세스가능하다.

이 예에서, 웹 컨텐츠 트랙 핸들러 (246) (예를 들어, HTML-5 트랙 핸들러) 는 자바스크립트로 완전히 구현될 수도 있고, 서비스를 시작하기 위해 트랙에서 데이터를 사용할 수도 있다. 이 경우, Javascript 가 실행되어 ISO BMFF 데이터를 파싱하고, 트랙 데이터를 사용하여 제시된 페이지뿐만 아니라 동적 메타데이터를 시작한다. XHR 또는 WebSocketAPI들을 사용하지 않고 하나의 클라이언트에서 오브젝트 및 소켓 바인딩이 구현될 수도 있다. 트랙을 미디어 엘리먼트에 바인딩하기 위해 동일한 것이 제공될 수도 있다. 그러나, 양자의 경우에, 동일한 트랙 데이터가 사용될 수도 있으며, 클라이언트의 구현만이 상이할 수도 있다. 특히, 이 예에서, 웹 컨텐츠 트랙 핸들러 (246) 는 트랙 데이터 (262) 를 인터프리터 (260) 에 제공하는 반면, 오디오 디코더 (248) 및 비디오 디코더 (250) 는 오디오 및 비디오 엘리먼트들을 웹 컨텐츠와 연관시키는 데이터 (264) 를 인터프리터 (260) 에 제공한다.

이 예에서, 모든 데이터는 정규 HTML-5 데이터일 수도 있으므로, HTML-5 에서 사용가능한 것 이외에 어떤 특별한 미디어 프로세싱이 추가될 필요가 없다. 또한, 수신기는 임의의 특별한 모듈이 없는 정규 HTML-5 프로세서일 수도 있다.

또한 콘텐츠 생성이 관련된다. 오디오/비디오와의 HTML-5 세션은 예를 들어, 상이한 피스들 (시작 페이지, 요청 샘플들, 및 푸시 샘플들) 을 비-타이밍된 시작 페이지, 뿐만 아니라 사용가능한 (또는 미디어 시간에 HTML-5 장면에서 먼저 참조되는) 경우에 타이밍된 요청 샘플들을 갖는 파일 포맷으로 덤핑함으로써 "레코딩"/"생성"될 수도 있고, 푸시 샘플들에는 이들이 네트워크 상에서 푸시된 디코드 시간이 할당될 수도 있다.

이러한 방식으로, 도 7 은 미디어 데이터를 취출하기 위한 디바이스의 일 예를 나타내고, 상기 디바이스는 미디어 데이터를 저장하도록 구성된 메모리, 및 회로부에 구현된 하나 이상의 프로세서들을 포함하며, 상기 하나 이상의 프로세서들은, 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하고, 그리고 미디어 데이터 및 웹 컨텐츠를 제시하도록 구성되며, 상기 하나 이상의 프로세서들은 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하도록 구성된다.

도 8 은 본 개시의 기술에 따른 예시적인 이벤트 기반 모델을 도시하는 개념도이다. 도 8 의 예시적인 모델은 전술한 트랙 모델에 대한 대안으로서 사용될 수도 있다. 특히, 도 8 은 예를 들어, ISOBMFF 파일, CMAF 프리젠테이션, 또는 DASH 미디어 프리젠테이션을 나타낼 수도 있는 미디어 컨텐츠 (280) 에 대한 예시적인 데이터 프로세싱 모델을 도시한다. 이 예에서, 미디어 컨텐츠 (280) 는 오디오 트랙 (282) 및 비디오 및 이벤트 트랙 (184) 을 포함하는 복수의 트랙들을 포함한다. 비디오 및 이벤트 트랙 (284) 은 DASH 애플리케이션 이벤트와 같은 이벤트를 포함한다.

도 8 의 예에서, 클라이언트 디바이스 (290) 는 오디오 트랙 핸들러 (292), 비디오 트랙 및 이벤트 핸들러 (294), 오디오 디코더 (298), 비디오 디코더 (300), 웹 소켓 서버 (302), HTTP 서버 캐시 (304), HTML-5 프로세서 (310), 및 미디어 렌더러 (320) 를 포함한다. HTML-5 프로세서 (310) 는 웹 소켓 클라이언트 (312) 및 HTTP 클라이언트 (314) 를 포함한다. 웹 소켓 서버 (302) 및 웹 소켓 클라이언트 (312) 는 WebSocket API 접속 (316) 을 통해 통신가능하게 커플링되는 반면, HTTP 서버 캐시 (304) 및 HTTP 클라이언트 (314) 는 XML HTTP 요청 (XHR) 접속 (318) 을 통해 통신가능하게 커플링된다.

이 예에서, 비디오 트랙 및 이벤트 핸들러 (294) 는 비디오 및 이벤트 트랙 (284) 으로부터 DASH 애플리케이션 이벤트를 추출하고, DASH 이벤트를 적절한 애플리케이션으로 전달할 수도 있다. 예를 들어, 비디오 트랙 및 이벤트 핸들러 (294) 는 비디오 및 이벤트 트랙 (284) 으로부터 WebSocket 이벤트 (286) 를 추출하고, WebSocket 이벤트 (286) 를 웹 소켓 서버 (302) 에 전달할 수도 있다. 다른 예로서, 비디오 트랙 및 이벤트 핸들러 (294) 는 XHR 이벤트 (288) 를 추출하고, XHR 이벤트 (288) 를 HTTP 서버 캐시 (304) 에 전달할 수도 있다. 애플리케이션 및 웹 페이지는 미디어 컨텐츠 (280) 외부에 있는 원래의 페이지와 함께 다운로드되어야 할 수도 있다. 또한, 전용 WebSocket 이벤트 또는 XHR 이벤트를 정의할 수도 있지만, 바인딩 등에 대한 세부사항이 누락될 수도 있다. 미디어 컨텐츠 (280) (예컨대, ISO BMFF 프리젠테이션 또는 DASH/CMAF 컨텐츠) 는 추가로 확장될 수도 있다.

또 다른 접근방식에서, FLUTE 개념이 사용될 수도 있다. XHR 샘플은 FLUTE 에 의해 쉽게 해결될 수도 있지만, 타이밍이 반드시 미디어와 정렬될 필요는 없으며, 이는 적용가능성을 제한할 수도 있다. 데이터 프리젠테이션은 반드시 완전한 것은 아니다. WebSocket 접근방식은 종래의 구현들에서 현재 지원되지 않는 라벨링을 갖는 웹 소켓 푸시 데이터의 브로드캐스트를 사용할 수도 있다.

상기 논의에 기초하여, 본 개시의 기술은 하기에 논의되는 바와 같이, 웹 컨텐츠 캐리지에 대한 ISOBMFF 트랙들의 스트로맨 디자인 (strawman design) 을 사용할 수도 있다. 즉, 도 1 의 컨텐츠 준비 디바이스 (20), 서버 디바이스 (60), 및/또는 클라이언트 디바이스 (40) 는 예를 들어, 하기에 논의되는 바와 같이, 본 개시의 웹 컨텐츠 캐리지를 위해 ISOBMFF 트랙들의 스트로맨 디자인을 사용하도록 구성될 수도 있다. 스트로맨 디자인은 다음과 같이 요약된다:

● 핸들러 타입이 'text' 이고 MIME 타입이 'text / htm5' 인 텍스트 트랙을 사용한다.

● 샘플 엔트리 디자인

○ 샘플 엔트리 타입은 'htm5' 이다.

○ HTML5ConfigurationBox 가 정의되며, 이는 샘플 엔트리에 포함되어야 하며, 다음의 정보를 포함한다:

■ 개별 사양의 버전, 필수적 및 옵션적인 API 등과 같은 기본 HTML-5 및 JavaScript (JSON 를 포함함) 정보.

■ 샘플에서 참조될 수도 있는 JavaScript 코드의 어레이.

● 샘플 디자인

○ 샘플 정의: 샘플은 다음 중 하나이다

■ 1) 시작 페이지로서 일부 JavaScript 코드들을 더한 HTML-5 페이지. 이는 시작 샘플로서 기능하고, 전체 동기화 샘플로 사용될 수도 있다 (페이지를 리로드). HTML-5 페이지는 또한 중복하는 동기화 샘플로서 제공될 수도 있다.- 이 샘플은 "시작" 샘플로 지칭된다

■ 2) (미디어 재생과 동기화된) 디코드 시간에 특정 웹소켓 API 로 푸시되는 일부 이진 오브젝트들. 시작 페이지는 시작 페이지에서 이진 오브젝트와 웹소켓 API 사이에 적절한 바인딩을 제공할 책임이 있다. 이러한 샘플은 기존 시작 페이지에 의존하기 때문에, 동기화 샘플이 아니다. 이 오브젝트들은 "푸시" 샘플들로 지칭된다.

■ 3) 상호작용에 반응하거나 또한 실행을 기반으로 오브젝트들을 로딩하기 위해 HTTP 요청들 (XHR 은 API 가 됨) 을 통해 액세스될 수 있는 오브젝트들. 시작 페이지와 오브젝트 간의 바인딩은 http URL 을 통한다. 샘플은 오브젝트의 관리에 관한 추가 정보, 예를 들어 캐시 지시문 등을 포함할 수도 있다. 요청된 후 샘플이 트랙 핸들러 버퍼에서 제거될 수 있거나 또는 유지되어야 하는 등의 예들이 있다. 이러한 샘플들은 "풀 (pull)" 샘플들로 지칭된다.

○ 시작 페이지는 트랙 헤더에서 비-타이밍된 아이템으로 제공될 수도 있거나 또는 디코드 시간 0 으로 타이밍된, 트랙에서의 정규 샘플로 제공될 수도 있다.

○ 디코드 시간은 샘플 타입에 따라 해석된다

■ "시작" 샘플들의 경우, 디코드 시간은 페이지가 HTML-5 엔진에 로딩되어야만 하는 미디어 시간이다.

■ "푸시" 샘플의 경우, 디코드 시간은 샘플이 WebSocketAPI 로 푸시되는 시간이다.

■ "풀" 샘플의 경우, 디코드 시간은 샘플이 HTML-5 프로세서에 의해 요청될 수도 있는 가장 빠른 시간, 즉 포함된 오브젝트가 이용가능한 시간이다.

○ 샘플들이 트랙에 임베딩될 수도 있거나 또는 외부 참조가 실행될 수도 있다. 특히 풀 샘플의 경우, 외부 참조가 실행될 수도 있다.

○ JavaScript 신택스는 샘플 엔트리에서 JavaScript 코드의 어레이에 대한 인덱스뿐만 아니라 트랙 ID 를 사용함으로써 파일에서 트랙을 참조할 수 있도록 확장된다. 기존의 표준 JavaScript 신택스에 의존하는 클라이언트의 경우, 파일 파서는 새로운 참조 메커니즘을 기존의 표준 JavaScript 신택스를 준수하는 것으로 변환해야 한다.

● 또한 구성 정보를 예를 들어 요구된 API들 등에 관한 미디어 타입에 부가하는 것을 허용하는, 트랙 내의 htm5 에 대한 미디어 타입.

● 동일한 프리젠테이션 (ISO BMFF, DASH 프리젠테이션 등) 에서 미디어 트랙들 간에 트랙 바인딩이 실행되어야 한다. 몇 가지 옵션들이 있다:

○ 소스 엘리먼트의 사용 및 명확한 새로운 URI 를 통한 바인딩을 제공한다. 예를 들어 track://<tracknumber> 은 트랙을 참조하도록 정의될 수도 있다. 해상도는 브라우저에 달려 있다.

○ 대안적으로 http 바인딩은 또는 포함된 리소스를 추적하는 것과 유사하게 실행될 수도 있다. 그러나, 그 후에 외부 바인딩에 대한 표시가 필요하다.

○ 또 다른 대안은, 트랙의 바이트 스트림이 브라우저로 전송될 수 있도록 MSE 를 사용하는 것이다. 이 옵션이 가장 적합한 것 같다. 이것은 예를 들어, 미디어 파일을 동기화된 방식으로 로딩하기 위해 MSE 및 JavaScript 를 사용하기 위해 트랙 URI 를 사용하는 구현에 의해 실행될 수도 있다.

● HTML/XML (및 여기서는 구체적으로, HTML-5) 트랙이 이 트랙의 샘플들에 포함된 HTML/XML 문서들 중 적어도 하나에 태그된 미디어 트랙들을 참조하기 위해, 새로운 트랙 참조 타입, 'mdtk' 가 정의된다.

● 다수의 HTML-5 트랙들이 허용된다. 다수의 HTML-5 트랙들이 파일에 존재하는 경우, 트랙들 간의 구분이 시그널링되어야만 한다. 한 가지 예는 상이한 디스플레이 해상도들 또는 디바이스들일 수 있다. 이를 위해, 타겟 디스플레이 해상도의 필드를 HTML5ConfigurationBox 에 추가할 수 있다. 대안적으로, 단일 런치가 항상 사용될 수도 있지만, 다수의 트랙들이 종속된 파일에 있을 수도 있고, 오직 특정 트랙들만이 액세스된다.

데이터 프로세싱 모델을 기반으로 하는 프레임워크의 데모 (demonstration) 는, 상당한 부분이 기존의 안정적인 구현을 갖는 기존 기술에 의존한다는 사실에 의해 촉진된다. 수신 측에서, 오직 HTML 트랙 핸들러만이 구현되어야 한다. 유사하게, 컨텐츠 생성 측에서, HTML 트랙 패키저가 구현될 수도 있다. 이들 모듈들이 구현되면, 기존의 브라우저, 예를 들면 Chrome 브라우저, Open Source 소켓 서버 및 HTTP 서버를 사용하여 실시간 상호작용 프로토타입이 데모를 위해 실현된다.

예시적인 데모 시나리오로서, 사용자는 스트림의 HTTPS URL, 예를 들어, example.com/InteractiveStream.mp4 ("https:// "가 선행함) 을 사용하여 인터넷 상의 과학 다큐멘터리의 상호작용 스트림에 액세스하기 위해 브라우저를 시작할 수도 있다. 이 URL 에 액세스하면, 완전한 기능의 웹 페이지는 2 가지 옵션들을 제시하는 2 개의 비디오 스트림 썸네일들로 보일 수도 있다: 피처의 재생 또는 스크린 트랙 뒤에서의 재생. 2 개의 옵션들 중 하나를 클릭하면, 전체 브라우저 창에서 다음 30 초 동안 프리젠터의 썸네일 이미지와 함께 무비가 재생된다. 썸네일 중 하나를 클릭하면 프리젠터 프로필이 새 창에서 열릴 수도 있다.

데모를 제시하기 위한 모든 데이터는 오픈 인터넷으로부터 액세스될 수도 있는, 프리젠터 프로파일을 제외하고 상호작용 파일에 임베딩될 수도 있다. 서비스 작업자가 필요한 경우 (예측된 시간프레임 동안 MSE 를 통한 HTML 트랙 디코딩에 대한 지원이 없기 때문에; 클라이언트는 또한 자연적으로 HTML 트랙에 대한 현재 지원의 결함 때문에 스트림을 디멀티플렉싱해야할 수도 있음), 그 실현이 보여져야할 수도 있다. 이는 미리 로딩되거나, 글루 URL 에 액세스함으로써 또는 서버측 스크립팅에 의해 촉진될 수 있다. HTML 트랙이 오디오/비디오와 별도로 제공되는 경우 단순화가 실행될 수 있지만, 이는 데모의 영향을 감소시킬 수도 있다.

상호작용 HTML 페이지는 기존의 Creative Commons 비디오 컨텐츠 및/또는 HTML 페이지 제작 도구를 사용하여 생성될 수도 있다. HTML 컨텐츠를 위한 기존 인코더가 없기 때문에, 매우 적은 수의 샘플들이 있다면, HTML 컨텐츠를 청크하고 패키징하기 위해 스크립트가 예를 들어, 파이썬 (Python) 으로 기록될 수도 있다. MP4Box 와 같은 기존 패키저는 샘플이 그 패키저에 대해 알 수 없는 유형이라 하더라도, 다수의 HTML 트랙을 형성하는 것이 가능할 수도 있다고 가정한다. JavaScript 는 HTML 트랙을 디코딩하기 위해 사용될 수도 있다. 클라이언트 디바이스는 또한 스크립트를 사용하여 HTML 트랙을 디멀티플렉싱할 수도 있다.

클라이언트측 애플리케이션에 대한 설정은 클라이언트 머신을 설정하는 것, (필요한 경우에) 오픈 소스 웹 소켓 서버를 액세스하는 것 및 HTML 서버를 액세스하는 것을 포함할 수도 있다. 클라이언트측 애플리케이션은 JavaScript 에 서비스 작업자 (service worker) 를 포함할 수도 있으며, 이는 오직 상기 논의된 HTML 트랙 디코더만을 포함할 수도 있다.

스트로맨 디자인은 상기 논의된 예들을 넘어서 확장될 수도 있다. 예를 들어, 스트로맨 디자인은 외부로의 HTTPS 접속들을 요구하는 HTML-5 를 설명하기 위해 확장될 수도 있다. 스트로맨 디자인은 CORS 문제를 해결할 수도 있다. MPEG-4, MAF 또는 다른 표준은 본 개시의 스트로맨 디자인을 설명하기 위해 확장될 수도 있다. 또한, 전달 및 세그먼트화된 컨텐츠를 맵핑하기 위해 추가의 세부사항들이 추가될 수도 있다.

이러한 방식으로, 도 8 은 미디어 데이터를 취출하기 위한 디바이스의 일 예를 나타내고, 상기 디바이스는 미디어 데이터를 저장하도록 구성된 메모리, 및 회로부에 구현된 하나 이상의 프로세서들을 포함하며, 상기 하나 이상의 프로세서들은, 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하고, 그리고 미디어 데이터 및 웹 컨텐츠를 제시하도록 구성되며, 상기 하나 이상의 프로세서들은 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하도록 구성된다.

도 9 는 본 개시의 기술들에 따라 미디어 데이터 및 동기화된 웹 컨텐츠를 취출하고 프로세싱하기 위한 예시적인 방법을 도시하는 흐름도이다. 도 9 의 방법은, 도 1 의 컨텐츠 준비 디바이스 (20) 및 클라이언트 디바이스 (40) 와 관련하여 설명된다. 하지만, 다른 디바이스들이 도 9 의 기술들을 수행하도록 구성될 수도 있음을 이해해야 한다. 예를 들어, 도 6 내지 도 8 중 어느 하나의 클라이언트 디바이스 모델에 따라 구성된 클라이언트 디바이스는 클라이언트 디바이스 (40) 에 기인하는 도 9 의 엘리먼트들을 수행할 수도 있다. 다른 예로서, 서버 디바이스 (60) 는 네트워크를 통해 데이터를 전송 및 수신하는 것과 같은, 컨텐츠 준비 디바이스 (20) 에 기인하는 특정 엘리먼트들을 수행할 수도 있다.

먼저, 컨텐츠 준비 디바이스 (20) 는 미디어 데이터 및 시간 동기화된 웹 컨텐츠를 수신한다 (350). 예를 들어, 캡슐화 유닛 (30) 은 오디오 인코더 (26) 로부터의 오디오 데이터, 비디오 인코더 (28) 로부터의 비디오 데이터, 타이밍된 텍스트 또는 다른 미디어 데이터뿐만 아니라, 미디어 데이터와 시간 동기화 방식으로 제시될 웹 컨텐츠를 수신할 수도 있다. 컨텐츠 준비 디바이스 (20) 의 캡슐화 유닛 (30) 은 그 후에 미디어 데이터 및 웹 컨텐츠를 파일에 캡슐화할 수도 있다 (352). 예를 들어, 캡슐화 유닛 (30) 은 도 6 및 도 7 에 도시된 바와 같이, 오디오 트랙에 오디오 데이터를, 비디오 트랙에 비디오 데이터를, 및 웹 컨텐츠 트랙에 웹 컨텐츠를 캡슐화할 수도 있다. 대안적으로, 캡슐화 유닛 (30) 은 도 8 에 도시된 바와 같이, 웹 컨텐츠 이벤트를 정의하는 비디오 데이터 및 이벤트 데이터 양자를 비디오 및 이벤트 트랙에서 캡슐화할 수도 있다.

후속하여, 클라이언트 디바이스 (40) 는 파일에 대한 요청을 전송할 수도 있다 (354). 도 9 에는 도시되어 있지 않지만, 일부 예들에서, 컨텐츠 준비 디바이스 (20) 는 파일의 웹 어드레스 (예를 들어, URL) 를 표시하는 (DASH MPD 와 같은) 매니페스트 파일을 제공할 수도 있고, 클라이언트 디바이스 (40) 는 먼저 매니페스트 파일을 취출하여 그 파일의 웹 어드레스를 결정할 수도 있다. 임의의 경우에, 클라이언트 디바이스 (40) 는 파일에 대한 요청, 예를 들어, 그 파일의 URL 을 정의하는 HTTP GET 또는 부분 GET 요청을 전송할 수도 있다 (354). 컨텐츠 준비 디바이스 (20) (또는 서버 디바이스 (60)) 는 파일에 대한 요청을 수신하고 (356), 요청된 파일을 클라이언트 디바이스 (40) 에 출력 (358) 할 수도 있다.

클라이언트 디바이스 (40) 는 그 후, 파일을 수신할 수도 있다 (360). 파일을 수신한 후에, 클라이언트 디바이스 (40) 는 미디어 데이터 및 웹 컨텐츠를 추출하고 (362), 미디어 데이터를 제시하고 (364), 미디어 데이터와 시간 동기화된 웹 컨텐츠를 제시할 수도 있다 (366). 예를 들어, 도 6 및 도 8 에 도시된 것과 같이, 클라이언트 디바이스 (40) 는 웹 소켓 서버, HTTP 서버 캐시, 및 HTML-5 프로세서를 포함할 수도 있다. 이 예에서, 미디어 데이터 및 웹 컨텐츠를 시간 동기화 방식으로 제시하기 위해, 클라이언트 디바이스 (40) 는 초기에 웹 페이지를 시작하고, 그에 따라 미디어 데이터의 프리젠테이션을 지연시킬 수도 있다. 그 후에, 웹 소켓 서버는 대응하는 미디어 데이터의 디코드 시간에 WebSocket API 를 통해 웹 컨텐츠를 푸시할 수도 있고 및/또는 HTML-5 프로세서는 HTTP 서버 캐시로부터 XHR 을 통해 특정 미디어 시간 주기 내에 미디어 데이터를 요청할 수도 있다. 일부 예들에서, 예를 들어, 도 8 에 도시된 바와 같이, 웹 소켓 서버 또는 다른 유닛 (예를 들어, 비디오 트랙 및 이벤트 핸들러) 은 별도의 서버로부터 웹 컨텐츠의 특정 엘리먼트들을 취출할 수도 있다.

다른 예로서, 도 7 에 도시된 바와 같이, 클라이언트 디바이스 (40) 는 웹 컨텐츠 트랙 핸들러 및 인터프리터를 포함할 수도 있다. 이 예에서, 미디어 데이터 및 웹 컨텐츠를 시간 동기화 방식으로 제시하기 위해, 클라이언트 디바이스 (40) 는 초기에 전체 웹 페이지뿐만 아니라 전체 및/또는 중복된 랜덤 액세스 데이터를 시작할 수도 있다. 그 후에, 인터프리터 및 웹 컨텐츠 트랙 핸들러는 JavaScript, WebSocket API, XHR 등을 사용하여 푸시된 및/또는 풀된 웹 컨텐츠를 통신할 수도 있다.

이러한 방식으로, 도 9 의 방법은 미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하는 단계, 및 미디어 데이터 및 웹 컨텐츠를 제시하는 단계를 포함하며, 상기 미디어 데이터 및 웹 컨텐츠를 제시하는 단계는 웹 컨텐츠를 미디어 데이터와 동기화하는 방식을 표시하는 데이터에 따라 웹 컨텐츠의 프리젠테이션을 미디어 데이터의 프리젠테이션과 동기화하는 단계를 포함하는 방법의 일 예를 나타낸다.

하나 이상의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 그 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되면, 그 기능들은 컴퓨터 판독가능 매체 상의 하나 이상의 명령 또는 코드로서 저장되거나 송신될 수도 있고 하드웨어 기반 프로세싱 유닛에 의해 실행될 수도 있다. 컴퓨터 판독가능 매체는, 데이터 저장 매체와 같은 유형의 매체에 대응하는 컴퓨터 판독가능 저장 매체, 또는 예를 들면, 통신 프로토콜에 따라, 일 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 가능하게 하는 임의의 매체를 포함하는 통신 매체를 포함할 수도 있다. 이러한 방식으로, 컴퓨터 판독가능 매체는 일반적으로 (1) 비-일시적인 유형의 컴퓨터 판독가능 저장 매체 또는 (2) 신호 또는 캐리어파와 같은 통신 매체에 대응할 수도 있다. 데이터 저장 매체는 본 개시에서 설명된 기술들의 구현을 위한 명령들, 코드 및/또는 데이터 구조들을 취출하기 위해 하나 이상의 컴퓨터들 또는 하나 이상의 프로세서들에 의해 액세스될 수 있는 임의의 가용 매체일 수도 있다. 컴퓨터 프로그램 제품이 컴퓨터 판독가능 매체를 포함할 수도 있다.

제한이 아닌 예로서, 그러한 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 저장부, 자기 디스크 저장부 또는 다른 자기 저장 디바이스들, 플래시 메모리, 또는 원하는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 커넥션이 컴퓨터 판독가능 매체로 적절히 명명된다. 예를 들어, 동축 케이블, 광섬유 케이블, 꼬임쌍선, 디지털 가입자 라인 (DSL), 또는 적외선, 무선, 및 마이크로파와 같은 무선 기술들을 이용하여 웹사이트, 서버, 또는 다른 원격 소스로부터 소프트웨어가 송신된다면, 동축 케이블, 광섬유 케이블, 꼬임쌍선, DSL, 또는 적외선, 무선, 및 마이크로파와 같은 무선 기술들은 매체의 정의에 포함된다. 하지만, 컴퓨터 판독가능 저장 매체 및 데이터 저장 매체는 접속, 캐리어 파, 신호 또는 다른 일시적 매체를 포함하는 것이 아니라, 대신에 비일시적, 유형의 저장 매체에 관련된다는 것이 이해되야 한다. 본 명세서에서 사용된 바와 같은 디스크 (disk) 및 디스크 (disc) 는 컴팩트 디스크 (CD), 레이저 디스크, 광학 디스크, 디지털 다기능 디스크 (DVD), 플로피 디스크 및 블루레이 디스크를 포함하며, 여기서, 디스크 (disk) 는 통상적으로 데이터를 자기적으로 재생하지만 디스크 (disc) 는 레이저를 이용하여 데이터를 광학적으로 재생한다. 또한, 상기의 조합은 컴퓨터 판독 가능 매체의 범위 내에 포함되어야 한다.

명령들은 하나 이상의 프로세서, 이를테면 하나 이상의 DSP (digital signal processor), 범용 마이크로프로세서, ASIC (application specific integrated circuit), FPGA (field programmable logic array), 또는 다른 등가 집적 또는 이산 로직 회로에 의해 실행될 수도 있다. 이에 따라, 본 명세서에서 사용된 바와 같은 용어 "프로세서" 는 본 명세서에서 설명된 기법들의 구현에 적합한 전술한 구조 또는 임의의 다른 구조 중 임의의 구조를 지칭할 수도 있다. 추가로, 일부 양태들에서, 본 명세서에서 설명된 기능성은 인코딩 및 디코딩을 위해 구성되거나, 또는 결합된 코덱에 통합된 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공될 수도 있다. 또한, 그 기법들은 하나 이상의 회로들 또는 로직 엘리먼트들에서 완전히 구현될 수 있다.

본 개시의 기법들은 무선 핸드셋, 집적 회로 (IC) 또는 IC 들의 세트 (예를 들면, 칩 세트) 를 포함하여, 광범위하게 다양한 디바이스들 또는 장치들에서 구현될 수도 있다. 다양한 컴포넌트들, 모듈들 또는 유닛들이, 개시된 기술들을 수행하도록 구성된 디바이스들의 기능적인 양태들을 강조하기 위하여 본 개시에 설명되었지만, 상이한 하드웨어 유닛들에 의한 실현을 반드시 필요로 하는 것은 아니다. 오히려, 상술된 바처럼, 다양한 유닛들이 코덱 하드웨어 유닛에 결합될 수도 있거나, 또는 적합한 소프트웨어 및/또는 펌웨어와 함께, 상술된 하나 이상의 프로세서들을 포함하는 상호동작 (interoperative) 하드웨어 유닛들의 집합에 의해 제공될 수도 있다.

다양한 예들이 설명되었다. 이들 및 다른 예들은 다음의 청구항들의 범위 내에 있다.

Claims

미디어 데이터를 취출하는 방법으로서,
미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하는 단계; 및
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하는 단계를 포함하며,
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하는 단계는 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 상기 데이터에 따라 상기 웹 컨텐츠의 프리젠테이션을 상기 미디어 데이터의 프리젠테이션과 동기화하는 단계를 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에 포함되는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일은 ISO 베이스 미디어 파일 포맷 (ISOBMFF) 에 따라 포맷화되는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일은 핸들러 타입이 'text' 이고 MIME 타입이 'text/htm5' 인 텍스트 트랙을 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일은 샘플 엔트리 타입이 'htm5' 인 샘플 엔트리를 포함하고,
상기 샘플 엔트리는 HTML 정보, JavaScript 정보 및 JavaScript 코드들의 어레이를 포함하는 HTML5ConfigurationBox 를 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일은 하나 이상의 샘플들을 포함하고, 상기 샘플들의 각각은 JavaScript 코드들을 포함하는 HTML 페이지, 이진 오브젝트들, 또는 HTTP 요청들을 통해 액세스가능한 오브젝트들 중 하나를 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에 대한 트랙 헤더에서 비-타이밍된 (non-timed) 아이템으로서 제공되는 시작 페이지를 정의하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에서 샘플로서 제공되는 시작 페이지를 정의하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 웹 컨텐츠의 샘플은 디코드 시간과 연관되고,
상기 방법은,
상기 샘플이 시작 샘플을 포함할 때, 상기 디코드 시간 이전에 상기 샘플의 웹 페이지를 로딩하는 단계;
상기 샘플이 푸시 (push) 샘플을 포함할 때, 상기 디코드 시간에 상기 샘플을 WebSocketAPI 로 푸시하는 단계; 및
상기 샘플이 풀 (pull) 샘플을 포함할 때, 상기 디코드 시간 이후에 상기 샘플을 요청하는 단계를 더 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일의 웹 컨텐츠 트랙으로부터 또는 외부 참조를 사용하여 샘플을 취출하는 단계를 더 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일에서 트랙을 참조하는 상기 웹 컨텐츠의 JavaScript 를 실행하는 단계를 더 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 htm5 트랙에 포함되고, 상기 htm5 트랙에 대한 미디어 타입은 상기 미디어 타입에 대하여 구성 정보가 추가되는 것을 표시하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일에 대응하는 프리젠테이션에서의 미디어 트랙들 간의 바인딩을 결정하는 단계를 더 포함하는, 미디어 데이터를 취출하는 방법.
제 13 항에 있어서,
상기 바인딩은 명확한 URI (Uniform Resource Identifier) 를 포함하는, 미디어 데이터를 취출하는 방법.
제 13 항에 있어서,
상기 바인딩은 HTTP 바인딩을 포함하는, 미디어 데이터를 취출하는 방법.
제 13 항에 있어서,
상기 바인딩은 미디어 소스 확장 (MSE) 바인딩을 포함하는, 미디어 데이터를 취출하는 방법.
제 16 항에 있어서,
상기 파일의 트랙의 바이트 스트림들을 웹 브라우저로 전송하는 단계를 더 포함하며, 상기 트랙은 상기 웹 컨텐츠를 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
트랙 참조 타입이 'mdtk' 인 상기 파일의 트랙을 프로세싱하는 단계를 더 포함하는, 미디어 데이터를 취출하는 방법.
제 1 항에 있어서,
상기 파일은 복수의 HTML-5 트랙들을 포함하는, 미디어 데이터를 취출하는 방법.
미디어 데이터를 취출하기 위한 디바이스로서,
미디어 데이터를 저장하도록 구성되는 메모리; 및
회로부에 구현된 하나 이상의 프로세서들을 포함하며,
상기 하나 이상의 프로세서들은,
미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하고; 그리고
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하도록
구성되며,
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하기 위해, 상기 하나 이상의 프로세서들은 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 상기 데이터에 따라 상기 웹 컨텐츠의 프리젠테이션을 상기 미디어 데이터의 프리젠테이션과 동기화하도록 구성되는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에 포함되는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 파일은 ISO 베이스 미디어 파일 포맷 (ISOBMFF) 에 따라 포맷화되는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 파일은 핸들러 타입이 'text' 이고 MIME 타입이 'text/htm5' 인 텍스트 트랙을 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 파일은 샘플 엔트리 타입이 'htm5' 인 샘플 엔트리를 포함하고,
상기 샘플 엔트리는 HTML 정보, JavaScript 정보 및 JavaScript 코드들의 어레이를 포함하는 HTML5ConfigurationBox 를 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 파일은 하나 이상의 샘플들을 포함하고, 상기 샘플들의 각각은 JavaScript 코드들을 포함하는 HTML 페이지, 이진 오브젝트들, 또는 HTTP 요청들을 통해 액세스가능한 오브젝트들 중 하나를 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에 대한 트랙 헤더에서 비-타이밍된 아이템으로서 제공되는 시작 페이지를 정의하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에서 샘플로서 제공되는 시작 페이지를 정의하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 웹 컨텐츠의 샘플은 디코드 시간과 연관되고,
상기 하나 이상의 프로세서들은 추가로,
상기 샘플이 시작 샘플을 포함할 때, 상기 디코드 시간 이전에 상기 샘플의 웹 페이지를 로딩하고;
상기 샘플이 푸시 샘플을 포함할 때, 상기 디코드 시간에 상기 샘플을 WebSocketAPI 로 푸시하고; 그리고
상기 샘플이 풀 샘플을 포함할 때, 상기 디코드 시간 이후에 상기 샘플을 요청하도록
구성되는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 하나 이상의 프로세서들은 상기 파일의 웹 컨텐츠 트랙으로부터 또는 외부 참조를 사용하여 샘플을 취출하도록 구성되는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 웹 컨텐츠를 제시하기 위해, 상기 하나 이상의 프로세서들은 상기 파일에서 트랙을 참조하는 상기 웹 컨텐츠의 JavaScript 를 실행하도록 구성되는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 htm5 트랙에 포함되고, 상기 htm5 트랙에 대한 미디어 타입은 상기 미디어 타입에 대하여 구성 정보가 추가되는 것을 표시하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 하나 이상의 프로세서들은 추가로, 상기 파일에 대응하는 프리젠테이션에서의 미디어 트랙들 간의 바인딩을 결정하도록 구성되는, 미디어 데이터를 취출하기 위한 디바이스.
제 32 항에 있어서,
상기 바인딩은 명확한 URI (Uniform Resource Identifier), HTTP 바인딩, 또는 미디어 소스 확장 (MSE) 바인딩 중 하나를 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 파일은 복수의 HTML-5 트랙들을 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
제 20 항에 있어서,
상기 디바이스는,
집적 회로;
마이크로프로세서; 및
무선 통신 디바이스
중 적어도 하나를 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
미디어 데이터를 취출하기 위한 디바이스로서,
미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하는 수단; 및
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하는 수단을 포함하며,
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하는 수단은 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 상기 데이터에 따라 상기 웹 컨텐츠의 프리젠테이션을 상기 미디어 데이터의 프리젠테이션과 동기화하는 수단을 포함하는, 미디어 데이터를 취출하기 위한 디바이스.
명령들을 저장한 컴퓨터 판독가능한 저장 매체로서,
상기 명령들은, 실행될 경우, 프로세서로 하여금,
미디어 데이터, 하이퍼텍스트 마크업 언어 (HTML) 에 따라 포맷화된 웹 컨텐츠, 및 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 데이터를 포함하는 파일을 취출하게 하고; 그리고
상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하게 하며,
상기 프로세서로 하여금 상기 미디어 데이터 및 상기 웹 컨텐츠를 제시하게 하는 명령들은, 상기 프로세서로 하여금 상기 웹 컨텐츠를 상기 미디어 데이터와 동기화하는 방식을 표시하는 상기 데이터에 따라 상기 웹 컨텐츠의 프리젠테이션을 상기 미디어 데이터의 프리젠테이션과 동기화하게 하는 명령들을 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 웹 컨텐츠 트랙에 포함되는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 웹 컨텐츠의 샘플은 디코드 시간과 연관되고,
상기 프로세서로 하여금,
상기 샘플이 시작 샘플을 포함할 때, 상기 디코드 시간 이전에 상기 샘플의 웹 페이지를 로딩하게 하고;
상기 샘플이 푸시 샘플을 포함할 때, 상기 디코드 시간에 상기 샘플을 WebSocketAPI 로 푸시하게 하고; 그리고
상기 샘플이 풀 샘플을 포함할 때, 상기 디코드 시간 이후에 상기 샘플을 요청하게 하는
명령들을 더 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 프로세서로 하여금, 상기 파일의 웹 컨텐츠 트랙으로부터 또는 외부 참조를 사용하여 샘플을 취출하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 파일의 웹 컨텐츠 트랙으로부터 또는 외부 참조를 사용하여 샘플을 취출하는 것을 더 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 프로세서로 하여금, 상기 파일에서 트랙을 참조하는 상기 웹 컨텐츠의 JavaScript 를 실행하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 웹 컨텐츠는 상기 파일의 htm5 트랙에 포함되고, 상기 htm5 트랙에 대한 미디어 타입은 상기 미디어 타입에 대하여 구성 정보가 추가되는 것을 표시하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 프로세서로 하여금, 상기 파일에 대응하는 프리젠테이션에서의 미디어 트랙들 간의 바인딩을 결정하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능한 저장 매체.
제 44 항에 있어서,
상기 바인딩은 명확한 URI (Uniform Resource Identifier) 를 포함하는, 컴퓨터 판독가능한 저장 매체.
제 44 항에 있어서,
상기 바인딩은 HTTP 바인딩을 포함하는, 컴퓨터 판독가능한 저장 매체.
제 44 항에 있어서,
상기 바인딩은 미디어 소스 확장 (MSE) 바인딩을 포함하는, 컴퓨터 판독가능한 저장 매체.
제 47 항에 있어서,
상기 프로세서로 하여금, 상기 파일의 트랙의 바이트 스트림들을 웹 브라우저로 전송하게 하는 명령들을 더 포함하며, 상기 트랙은 상기 웹 컨텐츠를 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 프로세서로 하여금, 트랙 참조 타입이 'mdtk' 인 상기 파일의 트랙을 프로세싱하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능한 저장 매체.
제 37 항에 있어서,
상기 파일은 복수의 HTML-5 트랙들을 포함하는, 컴퓨터 판독가능한 저장 매체.