KR100927978B1

KR100927978B1 - 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법

Info

Publication number: KR100927978B1
Application number: KR1020087007921A
Authority: KR
Inventors: 비디아 세틀루르; 수레쉬 치투리; 톨가 카핀; 마이클 인그라시아; 다이디 쩡; 미스카 하눅셀라
Original assignee: 노키아 코포레이션
Priority date: 2005-09-01
Filing date: 2006-09-01
Publication date: 2009-11-24
Also published as: US20090313293A1; TW200814665A; WO2007028137A2; US20070186005A1; EP1932315A1; KR20080048054A; WO2007026237A1; EP1932315A4; CN101300810A

Abstract

MMS/PSS/MBMS 서비스들 상으로 라이브 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및 스트리밍을 위한 3GPP ISO 기반 미디어 파일 포맷으로 SVG와 같은 벡터 그래픽 콘텐츠를 임베딩 하는 방법이다. 본 발명의 방법은 파일 포맷이 그래픽, 비디오 텍스트 및 이미지를 포함하는 리치 미디어 콘텐츠의 패키징을 위하여 이용되는 것을 허용하고; 스트리밍 서버들이 RTP 패킷들을 생성하는 것을 가능하게 하고; 클라이언트들이 리치 미디어 콘텐츠를 실현하거나, 재생하거나, 렌더링 하는 것을 가능하게 한다.

Description

리치 미디어 콘텐츠의 프로그레시브 다운로딩 및 스트리밍을 위해 ＩＳＯ 기반 미디어 파일 포맷으로 ＳＶＧ 콘텐츠를 임베딩 하는 방법{Method for embedding SVG content into an ISO base media file format for progressive downloading and streaming of rich media content}

본 발명은 프로그레시브(progressive) 다운로딩 및 스트리밍을 위한 콘텐츠의 임베딩에 일반적으로 관련된다. 보다 구체적으로, 본 발명은 리치 미디어 콘텐츠의 프로그래시브 다운로딩 및 스트리밍을 위한 SVG 콘텐츠의 임베딩에 관련된다.

리치 미디어 콘텐츠는 그래픽 적으로 풍부하고 그래픽, 텍스트, 비디오 및 오디오를 포함하는 복합체 또는 복수의 미디어를 포함하는 콘텐츠를 일반적으로 지칭하고, 바람직하게는 단일 인터페이스를 통하여 전달된다. 리치 미디어는 시간에 따라 동적으로 변하고 사용자 상호작용에 반응할 수 있다. 리치 미디어 콘텐츠는 실시간 콘텐츠를 위한 시각적으로 풍부한 콘텐츠를 운반하기 위하여 점진적으로 중요해지고 있고, 특히 MBMS/PSS 서비스 구조 내에서 중요하다.

멀티미디어 브로드캐스트/멀티캐스트 서비스(MBMS, Multimedia Broadcast/Multicast Service) 스트리밍 서비스들은 3G 모바일 환경에서 복수의 수신기들로 인기 있는 실시간 콘텐츠의 자원 효율적인 전달을 촉진한다. 다른 모바일 장치들로 동일한 콘텐츠를 운반하기 위하여 다른 포인트-대-포인트(PtP) 베어러(bearer)들을 이용하는 대신에, 단일의 포인트-대-다중포인트(PtM) 베어러가 주어진 셀에서 다른 모바일들로 동일한 콘텐츠를 전달하기 위하여 이용된다. 상기 스트리밍 된 콘텐츠는 비디오, 오디오, 가변 벡터 도형 처리(SVG, Scalable Vector Graphics), 시한적 텍스트 및 지원된 미디어를 포함할 수 있다. 상기 콘텐츠는 라이브 공급으로부터 미리 기록되거나 생성될 수 있다.

특히 웹 서비스 영역에서, 리치 미디어를 나타내기 위한 몇몇 현존하는 해결책들이 있다. SVGT 1.2는 XML에서 2차원 그래픽을 나타내기 위한 언어이다. SVG는 그래픽 객체들의 세 가지 유형을 허용한다: (1) 벡터 그래픽 형태들(예를 들면 직선들 및 곡선들로 이루어진 경로들); (2) 래스터(raster) 이미지들, 오디오 및 비디오와 같은 멀티미디어; 및 (3) 텍스트. SVG 그림들은 상호적이고(DOM 이벤트 모델을 이용한다) 동적일 수 있다. 애니메이션들이 선언적으로(즉, SVG 콘텐츠 내에 SVG 애니메이션 요소들을 임베딩 함에 의하여) 또는 스크립팅(scripting)을 통하여 정의되고 트리거 될(triggered) 수 있다. SVG의 복잡한 어플리케이션들은 모든 요소들, 속성들(attribute) 및 특성들(property)로 완전한 접근을 제공하는 SVG Micro Document Object Model(uDOM)로 접근하는 보충 스크립팅 언어의 이용을 통하여 가능하다. 이벤트 핸들러(handler)들의 풍부한 세트는 어떠한 SVG 그래픽 객체로도 할당될 수 있다. CDF와 같은 다른 Web 표준들의 그 호환성 및 레버리징(leveraging) 때문에, 스크립팅 같은 특성들은 동일한 웹 페이지 내에서 동시에 XHTML 및 SVG 요소들 상에서 수행될 수 있다.

동기식 멀티미디어 통합 언어(SMIL, Synchronized Multimedia Integration Language) 2.0은 상호적인 시청각 표시들의 단순한 오서링(authoring)을 가능하게 한다. SMIL은 이미지들을 갖는 오디오 및 비디오, 텍스트 또는 어떠한 다른 미디어 유형을 스트리밍 하는 것을 집적한 "리치 미디어"/멀티미디어 표시들을 위하여 일반적으로 이용된다.

복합 문서 포맷(CDF, Compound Documents Format) 워킹 그룹은 사용자 인터페이스 마크업(markup)들에 초점을 둔, XHTML, SVG, MathML, 및 SMIL과 같은 별개의 콤포넌트 언어들(예를 들면 XML-기반 언어들, 별개의 어휘들로부터의 요소들 및 속성들)을 결합하기 위하여 현재 시도하고 있다. 사용자 인터페이스 마크업들을 결합할 때, 마크업들을 통한 이벤트들의 전파, 렌더링(rendering)의 결합 또는 결합된 문서를 갖는 사용자 상호작용 모델과 같은, 개별 마크업 명세들에 의하여 제시되지 않은 특정 문제점들이 해결되어야 한다. 이러한 작업은 단계들과 참조에 의한 결합 및 산입에 의한 결합의 두 개의 기술적 해결책들로 나뉜다.

앞선 해결책들 및 메커니즘들 중 어느 것도 어떻게 SVG 콘텐츠를 포함하는 리치 미디어 콘텐츠가 프로그레시브 다운로딩 및 스트리밍 목적들을 위하여 ISO 기반 미디어 파일 포맷으로 임베드 될 수 있는지 특정하지 않는다.

최근까지는, 모바일 장치들을 위한 어플리케이션들은 제한된 상호작용을 갖는 텍스트 기반이었다. 그러나 더 많은 무선 장치들이 컬러 디스플레이들 및 더 많은 개선된 그래픽 렌더링 라이브러리들로 설비됨에 따라, 소비자들을 그들의 무선 어플리케이션들 모두로부터 리치 미디어 체험을 점점 요구하고 있다. 그러므로 실 시간 리치 미디어 콘텐츠 스트리밍 서비스는, 특히 MBMS, PSS 및 MMS 서비스들의 영역에서, 모바일 단말들을 위하여 매우 필요하다.

SVG는 해상도에 무관한 이차원 벡터 그래픽들을 기재하도록 설계되고, (그리고 종종 레스터 그래픽들, 오디오, 비디오 등과 같은 다른 미디어를 임베드하고) 그리고 SMIL로부터 가져온 이벤트 모델 및 애니메이션 개념들을 이용하여 상호작용을 허용한다. 이것은 또한 무한한 줌-가능성(zoomability)을 허용하고 모바일 장치들 상의 사용자 인터페이스들의 능력을 향상시킨다. 결과적으로, SVG는 중요성을 얻고 있고, 특히 모바일 TV, 교통 정보의 라이브 갱신들, 날씨, 뉴스 등과 같은 리치 미디어 서비스들을 위하여, 멀티미디어 표시의 핵심적인 요소들 중 하나가 되고 있다. SVG는 XML 기반이고, 이는 다른 현존하는 웹 기술들과 더욱 투명한 집적을 허용한다. SSVG는 권유로서 W3C에 의하여 그리고 선호되는 데이터 포맷으로서 Adobe에 의하여 보증되어 왔다.

3GPP에 의해 정의된, ISO 기반 미디어 파일 포맷은, 3세대 고속 무선 네트워크들 상에서 멀티미디어의 생성, 전달 및 재생을 위한 새로운 세계 표준이다. 이러한 표준은 가장 최근의 멀티미디어-가능 무선 장치들로 새로 발전된, 광대역 모바일 네트워크들(3세대 네트워크들) 상으로 리치 멀티미디어의 균일한 운반을 제공하는 것을 추구한다. 현재 파일 포맷은 오디오, 비디오 및 시한적 텍스트에 대하여 오직 정의된다. 그러므로 SVG의 중요성이 증가함에 따라, 특히 모바일 장치들 상에서, 진정한 리치 미디어 콘텐츠를 강화하고 전달하기 위하여 ISO 기반 미디어 파일 포맷으로 전통적인 미디어(비디오, 오디오 등)와 함께 SVG를 통합하는 것이 중요해 지고 있다. 이것은 리치미디어 스트리밍 서버들 및 클라이언트들이 프로그레시브 다운로드 또는 스트리밍 솔루션들을 위한 콘텐츠 전달을 위해 이러한 개선된 ISO 기반 미디어 파일 포맷을 지원할 수 있는 것을 의미한다.

현재, 리치 미디어 콘텐츠의 프로그레시브 다운로드 또는 스트리밍을 위한 3GPP ISO 기반 미디어 파일 포맷으로 SVG의 그래픽 미디어를 임베딩하기 위한 어떠한 현존하는 솔루션들도 없다. PCT 공보 번호 2005/039131은 컨테이너(container) 포맷 내에서 몇몇 미디어 객체들을 포함하는 멀티미디어 표시를 전송하기 위한 방법을 소개했다. US 공개 특허 출원 No. 2005/0102371은 클라이언트로 송신되는 파일의 메타-데이터의 적어도 일부와 함께 서버 및 클라이언트 사이에 네트워크상으로 메타-데이터 및 미디어-데이터를 포함하는 스트리밍 가능한 파일을 스트리밍 또는 다운로딩 하는 것을 구성하기 위한 방법을 논했다. 그러나 3GPP 내의 벡터 그래픽들을 위한 현재 솔루션들은 다운로딩 및 재생, 아니면 HTTP 스트리밍으로서 알려진 것에 한정된다.

본 발명은 MMS/PSS/MBMS 서비스들 상으로 실시간 리치 미디어 콘텐츠의 프로그레시브 다운로딩 또는 스트리밍을 위해 SVG와 같은 벡터 그래픽 콘텐츠를 3GPP ISO 기반 미디어 파일 포맷으로 임베딩 하는 방법에 대해 제공한다. 본 발명의 방법은 파일 포맷이 리치 미디어 콘텐츠(그래픽들, 비디오, 텍스트, 이미지 등)의 패킹을 위하여 이용되는 것을 허용하고, 스트리밍 서버들이 RTP 패킷들을 생성하는 것을 가능하게 하고, 클라이언트들이 리치 미디어 콘텐츠를 실현하거나, 재생하거나, 렌더링 하는 것을 가능하게 한다.

본 발명은 SVG 콘텐츠를 수용하기 위하여 ISO 기반 미디어 포맷을 확장한다. 시간 기반 SVG와 함께 비디오와 같은 프레임 기반 미디어 둘 다를 포함하기 위한 어떠한 솔루션도 예전에 없었다. ISO 기반 미디어 파일 포맷은 3세대 고속 무선 네트워크들 상으로 멀티미디어의 생성, 전달 및 재생을 위한 새로운 모바일 폰 파일 포맷이다. SVG의 산입은 3G 모바일 장치로 리치 미디어 서비스들을 제공하기 위하여 더 큰 레버리지를 촉진시킨다.

본 발명의 이러한 그리고 다른 목적들, 이점들 및 특성들은 그것의 동작의 구성 및 방식과 함께, 첨부된 도면들과 결합하여 취해질 때 다음 상세한 설명으로부터 명확해질 것이고, 유사한 요소들은 아래 묘사된 몇몇 도면들 전체에서 유사한 번호들을 갖는다.

도 1은 본 발명이 구현될 수 있는 시스템의 개략적인 도면이다.

도 2는 본 발명의 실시에서 이용될 수 있는 모바일 전화의 사시도이다.

도 3은 도 2의 모바일 전화의 전화 회로단의 개략적인 표현이다.

도 4는 ISO 기반 미디어 파일 본문 내의 서버로부터 클라이언트 장치로 리치 미디어 서비스들을 제공하기 위한 프로세스를 보여주는 흐름도이다.

본 발명은 MMS/PSS/MBMS 서비스들 상으로 실시간 리치 미디어 콘텐츠의 프로그레시브 다운로딩 또는 스트리밍을 위한 3GPP ISO 기반 미디어 파일 포맷으로 SVG 와 같은 벡터 그래픽 콘텐츠를 임베딩 하는 방법을 제공한다. 본 발명의 방법은 상기 파일 포맷이 리치 미디어 콘텐츠(그래픽들, 비디오, 텍스트, 이미지들 등)의 패킹을 위하여 이용되는 것을 허용하고, 스트리밍 서버들이 RTP 패킷들을 생성하는 것을 가능하게 하고, 클라이언트들이 리치 미디어 콘텐츠를 실현하거나, 재생하거나, 또는 렌더링 하는 것을 가능하게 한다.

리치 미디어 서비스들을 이용한 몇가지 경우들이 있다. 이러한 이용 경우들 중 몇몇이 다음에 있다.

긴 만화 애니메이션들의 미리보기-이러한 서비스는 최종-사용자가 어떤 애니메이션을 그 또는 그녀가 그것의 전체에 있어서 보기를 원하는지 결정하기 전에 각각의 애니메이션의 작은 부분들을 프로그레시브하게 다운로드하는 것을 허용한다.

상호적인 모바일 TV 서비스들- 이러한 서비스는 모두 함께 최종-사용자 인터페이스에서, 오디오-비디오 콘텐츠, 텍스트, 그래픽, 이미지들 및 TV 및 라디오 채널들을 포함하는 리치 미디어 콘텐츠의 결정하는 렌더링 및 동작을 가능하게 한다. 상기 서비스는 단일 어플리케이션 또는 서비스 내의 콘텐츠를 통한 편리한 이동을 제공해야하고, 투표 및 개인화(예를 들면 관련된 메뉴 또는 하위 메뉴, 광고 및 최종-사용자 프로필 또는 서비스 가입의 기능 내의 콘텐츠)와 같은 목적을 위하여 국지적으로 또는 원격으로 동기화 상호작용을 허용해야 한다. 이러한 이용 경우는 iTV 모바일 서비스에서 이용 가능한 네 개의 서비스들 및 하위 서비스들에 상응하는 네 개의 단계들에서 묘사된다: (1) 모자이크 메뉴: TV 채널 모습; (2) 전자 프로그램 가이드 및 관련된 iTV 서비스의 트리거; (3) iTV 서비스; 및 (4) 개인화 된 메뉴 "스포츠 뉴스".

라이브 기업 데이터 공급- 이 서비스는 실시간 기세(quotes)의 스트리밍을 제공하는 주식 시세 표시기, 기술적인 표지들을 갖는 라이브 일일 차트들, 뉴스 모니터링, 일기 알림들, 차트들, 비즈니스 업데이트들 등을 포함한다.

라이브 대화- 라이브 대화 서비스는 웹 캠, 비디오 채널 또는 리치 미디어 블로그 서비스 내에서 통합될 수 있다. 최종 사용자들은 그들의 별명을 등록하고, 저장하고 메시지들을 교환할 수 있다. 메시지들은 최종 사용자에 의하여 제공되는 리치 미디어 데이터에 속하여 라이브 대화 서비스 내에서 동적으로 나타난다. 상기 대화 서비스는 동시에 하나 또는 그 이상의 복수의 채널들 내에서 개인적이거나 공용일 수 있다. 최종 사용자는 다른 사용자들로부터 신규 메시지들에 대하여 동적으로 알림을 받을 수 있다. 서비스 내에서 메시지들의 동적인 갱신들은 완전한 페이지를 다시 로딩함 없이 일어난다.

가라오케(Karaoke)- 이 서비스는 노래를 위하여 글자들 상에 흐르는 것 같은 애니메이션으로 노래의 말을 따라(예를 들면 폰트들의 부드러운 색깔 변화, 텍스트의 스크롤), 음악 tv 채널 또는 비디오 클립 카탈로그를 디스플레이 한다. 최종 사용자는 상호적인 버튼을 선택함에 의하여 완전한 애니메이션을 따라 그 또는 그녀가 선택한 노래를 다운로드할 수 있다.

도 4는 ISO 기반 미디어 파일 본문에서 서버(100)로부터 클라이언트 장치(110)까지 리치 미디어 서비스들을 제공하기 위한 프로세스의 표현이다. 리치 미디어(다른 미디어를 갖는 SVG)는 ISO 기반 미디어 파일 생성기(120)로 제공되고, 이는 리치 미디어 ISO 기반 미디어 파일(130)을 생성하기 위하여 이용된다. 이러한 아이템은 다음으로 인코더(140)를 통하여 통과되고 디코더(150)에 의하여 이어서 복호화 된다. 상기 리치 미디어 ISO 기반 미디어 파일(130)은 리치 미디어 파일 추출기(160)에 의하여 다음으로 추출되고 다음으로 클라이언트 장치(110)에 의하여 이용될 수 있다.

본 발명의 제1 실시는 세 개의 단계들을 포함한다: (1) ISO 기반 미디어 파일 포맷에서 새로운 SVG 미디어 트랙을 정의하는 단계; (2) SVG 샘플들의 RTP 패킷화를 촉진하기 위하여 상기 ISO 기반 미디어 파일 포맷 내에서 힌트 트랙 정보를 특정하는 단계; 및 (3) 탐색 동작들을 위한 랜덤 접근 점들을 편리하게 하기 위하여 선택적인 음영(shadow) 동기화 샘플 테이블을 특정하는 단계.

ISO 기반 미디어 파일 포맷에서, 전체 표시가 영화로서 지칭되고 트랙들로 논리적으로 분할된다. 각각의 트랙은 미디어의 시한적인 시퀀스를 나타낸다(예를 들면, 비디오에서 프레임들, SVG에서 장면 및 장면 갱신들). 각각의 트랙 내의 각각의 시한적인 단위는 샘플로 지칭된다. 각각의 트랙은 하나 또는 그 이상의 샘플 기재들을 갖고, 여기서 트랙 내의 각각의 샘플들은 참조에 의하여 상응하는 샘플 기재로 속해진다. 이러한 파일 포맷 내의 데이터 모두는 박스들의 계층 내에서 캡슐화된다. 박스는 유일한 타입 식별자 및 길이에 의하여 정의되는 객체-지향 빌딩 블록이다. 모든 데이터는 박스들 내에 포함되고; 파일 내에 어떠한 다른 데이터도 없다. 이는 특정 파일 포맷에 의하여 요구되는 어떠한 시작 서명을 포함한다.

표 1은 ISO 기반 미디어 파일 포맷의 박스 계층을 보여준다. 이러한 박스들 의 배열 및 가이드라인들은 www.jpeg.org/jpeg2000/j2kpart12.html에 개시된 바와 같은 ISO/IEC 15444-12:2005 명세들에 따른다. 여기서 논해지는 실시의 상세 내용들은 파일 포맷에 SVG 미디어를 포함하기 위하여 요구되는 추가적인 박스 정의들 및 기술자(descriptor)를 제공한다. 표 1 내의 모든 다른 박스들은 명세 내에 묘사된 바와 같은 그들의 정의들 및 문법을 따른다. ISO 기반 미디어 파일 포맷 내의 데이터가 표시, 트랙 및 샘플 레벨들을 포함하는 몇몇 레벨들에서 발생할 수 있음으로써, 단일 표시로 그룹화 되고 집적되는 것이 필요하다. 표 1에서, 본 문서 내에서 새롭게 정의되는 박스들이 두껍게 강조되었다.

moov						*		모든 메타데이터를 위한 컨테이너
	mvhd					*		영화 헤더, 전체 선언들
	trak					*	b	개별 트랙 또는 스트림을 위한 컨테이너
		tkhd				*		트랙 헤더, 트랙에 관한 전체 정보
		mdia				*		트랙 내의 미디어 정보를 위한 컨테이너
			mdhd			*		미디어 헤더, 미디어에 관한 전체 정보
			hdlr			*	c	핸들러, 미디어 (핸들러) 유형 선언들
			minf			*		미디어 정보 컨테이너
				smhb			d	SVG 미디어 헤더, 전체 정보(오직 SVG 트랙)
				dinf		*		데이터 정보 박스, 컨테이너
					dref	*		데이터 참조 박스, 트랙 내의 미디어 데이터의 소스(들) 선언들
				stbl		*		샘플 테이블 박스, 시간/공간 맵을 위한 컨테이너
					stsd	*	f	샘플 기재(코덱 유형들, 초기화 등)
					stts	*	e	(복호화) 시간-대-샘플
					stsc	*		샘플-대-청크(chunk), 부분적인 데이터-오프셋 정보
					stco	*		청크 오프셋, 부분적인 데이터-오프셋 정보\
					stss		g	동기화 샘플 테이블(랜덤 접근점들)
					stsh		g	음영 동기화 샘플 테이블
		udta						사용자 데이터
			hnti					트랙 힌트 정보 컨테이너
				fthi			i.3.4	FLUTE 트랙 힌트 정보(FLUTE 설계)
				fdtt			i.5.4	FLUTE 트랙 FDT 정보(FLUTE 설계)
				sdp				RTP 트랙 sdp 힌트 정보(RTP 설계)
	udta							사용자 데이터
		hnti						영화 힌트 정보 컨테이너
			fmhi				i.3.3	FLUTE 영화 힌트 정보(FLUTE 설계)
			flmf				i.5.3	FLUTE 영화 FDT 정보(FLUTE 설계)
			rtp					RTP 영화 힌트 정보(RTP 설계)
			frmh				i.4.3	FLUTE RTP 영화 힌트 정보(FLUTE+RTP 설계)
			frmf				i.5.3	FLUTE RTP 영화 FDT 정보(FLUTE+RTP 설계)
			rfmh				i.4.3	RTP FLUTE 영화 힌트 정보(FLUTE+RTP 설계)
meta						*	a	메타 데이터 박스
	iloc					*		아이템 위치 박스
	iinf					*		아이템 정보 박스
	pitm					*		일차 아이템 참조
	ihib						i.1	아이템 힌트 정보 박스
		rihi					i.2.2	RTP 아이템 힌트 정보(RTP 설계)
		fihi					i.3.2	FLUTE 아이템 힌트 정보(FLUTE 설계)
		flif					i.5.2	FLUTE 아이템 FDT 정보(FLUTE 설계)
		frih					i.4.2	FLUTE RTP 아이템 힌트 정보(FLUTE+RTP 설계)
		frif					i.5.2	FLUTE RTP 아이템 FDT 정보(FLUTE+RTP 설계)
		rfih					i.4.2	RTP FLUTE 아이템 힌트 정보(FLUTE+RTP 설계)
	phib						i.1	표시 힌트 정보 박스
		rphi					i.2.1	RTP 표시 힌트 정보(RTP 설계)
		fphi					i.3.1	FLUTE 표시 힌트 정보(FLUTE 설계)
		flpf					i.5.1	FLUTE 표시 FDT 정보(FLUTE 설계)
		frph					i.4.1	FLUTE RTP 표시 힌트 정보(FLUTE+RTP 설계)
		rfph					i.4.1	RTP FLUTE 표시 힌트 정보(FLUTE+RTP 설계)
		frpf					i.5.1	FLUTE RTP 표시 FDT 정보(FLUTE+RTP 설계)

본 발명의 제1 실시는 SVG 미디어를 위한 박스 구문(syntax)들을 정의하는 단계를 포함한다. 다양한 박스 구문은 다음과 같다.

미디어 데이터 박스 및 메타 박스. 전통적인 시스템들에서, 모든 미디어 데이터(오디오, 비디오, 시한적 텍스트, 레스터 이미지들 등)는 동일한 파일 또는 상기 두 개의 결합 내에서 개별 파일들 또는 다른 미디어 데이터 박스들('mdat') 중 하나 내에 포함되었다. 'moov' 박스 및 'meta' 박스 모두는 메타데이터를 저장하기 위하여 이용될 수 있다. 상기 'meta' 박스의 컨테이너는 파일, 즉 'moov' 박스 또는 'trak' 박스일 수 있다. 3GPP 파일 포맷(3GPP TS 26.244)에 따르면, 확장된 표시들 내의 3GPP 파일은 파일의 최고 레벨에서 메타 박스('meta')를 포함한다.

일차적인 데이터는 XML 포맷 내에 있고 상기 XML이 메타-박스 내에서 직접적으로 저장되기를 원할 때, 'meta' 계층 하의 상기 XML 박스들은, 상기 데이터가 각각 순수한 XML 또는 이진 XML인지 여부에 따라 이용될 수 있다. SVG가 XML 데이터의 한 유형이기 때문에, SVG 미디어 데이터는 개별 파일들, 동일한 파일 내의 다른 'mdat', 또는 XML 박스들('xml' 또는 'bxml') 내에 또는 상기 세 개의 조합 내에 저장될 수 있다.

트랙 박스('trak'). 트랙 박스는 표시의 단일 트랙을 포함한다. 각각의 트랙은 서로에 무관하고, 그것 스스로 일시적이고 공간적인 정보를 운반한다. 각각의 트랙 박스는 그것 자신의 미디어 박스와 관련된다. 디폴트로서, 상기 표시는 영화 박스의 모든 트랙들을 어드레싱 한다. 그러나 그들의 트랙 ID들을 참조함에 의하여 영화 박스 내의 개별 미디어 트랙들을 어드레싱 하는 것이 가능하다. 개별 트랙들은 그들의 번호들을 배열함에 의하여 어드레싱 되고, 예를 들면 "#box=moov;trak_ID1,3"이다.

핸들러 참조 박스. 새로운 SVG 핸들러가 여기서 소개된다. 이 핸들러는 핸들러 유형 'svxm' 및 이름 'image/svg+xml'을 정의한다.

미디어 정보 헤더 박스. SVG 미디어 헤더 박스는 SVG 미디어를 위한 일반적인 표시 정보이다. 이 박스의 정의 및 구문은 다음과 같다.

Box Type: 'smhb'

Container: Media Information Box ('minf')

Mandatory: Yes

Quantity: Exactly one

aligned (8) class SVGMediaHeaderBox extends FullBox('smhb', version = 0, 0) { string version_profile;

string base_profile;

unsigned int(8) sdid_threshold;

}

"version_profile"은 이용되는 SVG의 프로필이 SVGT1.1 또는 SVGT1.2인지 여부를 특정한다. "base-profile"은 콘텐츠를 바르게 렌더링 하는데 필요하다고 여겨지는 최소 SVG 언어 프로필을 기재한다(SVG Tiny 또는 SVG Basic). 상기 "sdid_threshold"는 샘플 기재 인덱스 영역(SDID)의 문턱값을 정의한다. SDID는 페이로드(payload)를 복호화하는 것을 돕기 위하여 샘플 기재들(SD)을 식별하기 위하여 이용되는 8-비트 인덱스이다. SDID를 위한 최대값은 225이고, 정적 그리고 동적 SDID들을 위한 디폴트 문턱값은 127이다.

박스들을 샘플링 하는 시간. 박스를 샘플링 하는 복호화 시간(stts)은 어떻게 정보를 샘플링하기 위한 복호화 시간이 장면 및 장면 갱신들을 위하여 연산되어야하는지를 설명한다. 박스를 샘플링하기 위한 복호화 시간은 복호화 시간으로부터 인덱싱(indexing)이 번호를 샘플링 하는 것을 허용하는 테이블의 압축판을 포함한다. 상기 테이블 내의 각각의 엔트리는 동일한 시간 델타를 갖는 수개의 연속적인 샘플들, 및 그러한 샘플들의 델타를 준다. 델타들을 추가함에 의하여, 완전한 시간-대-샘플 맵이 수립될 수 있다. 상기 샘플 엔트리들은 시간 스탬프들을 복호화 함에 의하여 배열되고; 그러므로 상기 델타들은 모두 음이 아니다. 참고를 위하여, TimeToSampleBox를 위한 ISO 기반 미디어 파일 포맷 구문은 다음과 같다.

aligned(8) class TimeToSampleBox extends FullBox('stts', version = 0,0) {

unsigned int(32) entry_count;

int i;

for (i=0; i < entry_count; i++) {

unsigned int(32) sample_count;

unsigned int(32) sample_delta;

}

이러한 경우, 상기 "entry_count"는 다음 테이블 내의 수 개의 엔트리들에 주어지는 정수이다. 상기 "sample_count"는 주어진 지속시간을 갖는 연속적인 샘플들의 수를 세는 정수이다. 상기 "sample_delta"는 상기 미디어의 시간 스케일에서 이러한 샘플들의 델타를 주는 정수이다. 예를 들면 일은 제0 시간 단위들의 시작 시간을 갖는, 한 장면이 있는 상황을 시험할 수 있다. 이러한 상황에서, 또한 제5 시간 단위, 제10 시간 단위, 제15 시간 단위의 시작 시간들을 갖는 세 개의 장면 갱신들이 있을 수 있다. 이러한 경우, 총 네 개 엔트리들이 있다. 이러한 경우, 테이블 엔트리들을 샘플링하기 위한 복호화 시간은 다음과 같다.

entry_count=4

sample_count	1	1	1	1
sample_delta	0	5	5	5

대안으로, 표 2는 다음과 같이 나타낼 수 있고, 이는 장면 갱신들을 위한 델타들이 동일하기 때문이다.

entry_count=4

sample_count	1	3
sample_delta	0	5

시간 간격들이 동일하지 않은 다른 예는 다음과 같다. 한 장면은 제0 시간 단위의 시작 시간을 가질 수 있다. 이러한 예에서, 제2 시간 단위, 제7 시간 단위, 제12 시간 단위 및 제15 시간 단위의 시작 시간들을 갖는 네 개의 장면 갱신들이 있다. 이러한 상황에서, 테이블 엔트리들을 샘플하기 위한 복호화 시간은 다음과 같다.

entry_count=5

sample_count	1	1	1	1	1
sample_delta	0	2	5	5	3

이는 대안적으로 다음과 같이 보일 수 있다.

sample_count	1	1	2	1
sample_delta	0	2	5	3

몇몇 아이템들은 그러한 구성에서 주의되어야 한다. 장면 및 장면 업데이트들은 일시적으로 겹쳐지지 않는다. 상기 '시간 단위'는 미디어 헤더 박스('mdhd') 내에서 정의된 'timescale'에 기초하여 산출된다. 추가적으로, 상기 'timescale'은 각각의 복호화 시간이 정수인 것을 보장하기에 충분한 해상도를 필요로 한다. 최근에는, 다른 트랙들이 다른 시간 스케일들을 가질 수 있다. 만약 SVG 미디어가 오디오 및 비디오를 포함하는 모든 다른 미디어를 위한 컨테이너 포맷이라면, 이 경우 표시의 시간 스케일은 일차적으로 SVG 미디어의 시간 스케일이다. 그러나 만약 SVG 미디어가 다른 미디어와 공존한다면, 이 경우 표시 시간 스케일은 표시 내의 모든 미디어 중에서 최대 시간 스케일 보다 작지 않다.

샘플 기술 박스. ISO 기반 미디어 포맷 내의 샘플 기술 박스(stsd) 하에서, SVGSampleEntry는 아래에 정의된다. 이는 이러한 장면 트랙 내의 SVG 샘플들을 나타내기 위하여 샘플 기재 포맷을 정의한다. 이는 SVG 샘플들의 복호화를 위하여 모든 필요한 정보를 포함한다.

class SVGSampleEntry() extends SampleEntry ('ssvg') { //'ssvg' -> unique type identifier for //SVG Sample

unsigned int(16) pre_defined = 0;

const unsigned int(l6) reserved = 0;

unsigned int(8) type;

string content_encoding;

string text_encoding;

unsigned int(8) content_script_type;

unsigned int(l6) format_list[];

}

상기 "type"은 이러한 샘플이 장면 또는 장면 갱신을 나타내는지 여부를 특정한다. 상기 "content_encoding"은 'none,' 'bin_xml,' 'gzip,' 'compress,' 'deflate'인 가능한 값들을 갖는 널 종료 스트링(null terminated string)이다. 이러한 명세는 RFC 2616의 섹션 3.5에 따르고, 이는 www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5에서 찾을 수 있다. 상기 "text_encoding"은 US-ASCII, BS_4730 등과 같은 IANA 명세(이는 www.iana.org/assignments/character-sets에서 찾을 수 있다) 내의 'name' 또는 'alias' 영역(적용에 따라)으로부터 취해지는 가능한 값들을 갖는 널 종료 스트링이다. "content_script_type"은 주어진 샘플에 대한 디폴트 스크립팅 언어를 식별한다. 이러한 속성은 문서 내의 스크립트의 모든 예들에 대하여 디폴트 스크립팅 언어를 설정한다. 상기 값 "content_type"은 미디어 유형을 특정한다. 만약 스크립팅이 활성화되지 않았다면, 이 경우 이러한 영역에 대한 값은 0이다. 디폴트값은 값 1을 갖는 "ecmascrip"이다. 상기 "format_list"는 현재 샘플 내에 나타난 미디어 포맷들 모두를 나열한다. 외부적으로 임베딩 된 미디어는 이러한 경우 고려되지 않는다.

미디어는 <xlink:href="ski.avi" volume=".8" type="video/x-msvideo" x="10" y="170"> 또는 <xlink:href="1.ogg" volume="0.7" type="audio/vorbis" begin="mybutton.click" repeatCount=3>과 같이 SVG 내에 임베딩 될 수 있다.

format_list는 상응하는 SVG 샘플 내에 내부적으로 링크되고 임베딩 된 미디어의 포맷 번호들을 나타낸다. 상기 format_list는 SVG 샘플의 포맷 번호가, 다른 임베딩 된 미디어의 포맷 번호들에 앞서는, 제1 위치 내에 저장되는 어레이이다. 예를 들면, 만약 SVG 표시의 SDP가 다음과 같은 경우이다.

m=svg+xml 12345 RTP/AVP 96

a=rtpmap:96 X-SVG+XML/100000

a=fmtp:96 sdid-threshold=63;version_provile="1.2";base_profile=" 1 "

....

m=video 49234 RTP/AVP 98 99 100 101

a=rtpmap:98 h263-2000/90000

....

만약 한 특정 SVG 샘플이 99, 100의 포맷 번호들을 갖는 비디오 미디어를 포함한다면, 이 경우 이러한 샘플의 format_list 값들: 96, 99, 100을 연속적으로 포함한다. SVGSampleEntry 박스 내에 특정된 파라미터들 중 일부는 SVG 파일 그 자체 내에 정의될 수 있고, ISO 기반 미디어 파일 생성기는 샘플에 대한 정보를 획득하기 위하여 XML-유사 SVG 콘텐츠를 분석할 수 있다. 그러나 설계에 있어서 유연성을 위하여, 이러한 정보는 SVGSampleEntry 박스 내에 영역들로서 제공된다.

동기화 샘플 박스 및 음영 동기화 샘플 박스. 상기 동기화 샘플 박스 및 음영 동기화 샘플 박스는 ISO 기반 미디어 파일 포맷(ISO/IEC 15444-12, 2005) 내에 정의된다. 상기 동기화 샘플 박스는 스트림 내에 랜덤 접근점들의 압축 표시를 제공한다. 만약 동기화 샘플 박스가 존재하지 않는다면, 모든 샘플은 랜덤 접근점이다. 상기 음영 동기화 테이블은 탐색할 때 또는 유사한 목적을 위하여 이용될 수 있는 동기화 샘플들의 선택적인 세트를 제공한다. 일반적인 정방향 재생에서, 이들은 무시된다. 음영 동기화 샘플(ShadowSyncSample)은 그것이 음영을 지우는 샘플을 증가 없이 대체한다. 상기 음영 동기화 샘플은 마치 그것이 음영을 지우는 샘플의 구간을 가지고, 그것이 음영을 지우는 샘플의 시간에서 그것이 발생하는 것처럼 처리된다. 예로서, 다음 SVG 샘플 시퀀스가 고려된다.

S SU SU SU S SU SU SU S S SU SU SU

sample_index	0	1	2	3	4	5	6	7	8	9	10	11	12
samples	S	SU	SU	SU	S	SU	SU	SU	S	S	SU	SU	SU

이러한 상황에서, 각각의 SVG 장면(S)은 랜덤 접근점이다. SVG 장면들 모두는 동기화 샘플인 것이 가능하다. 만약 인덱스 0, 4, 및 8을 갖는 샘플들이 동기화 샘플들인 것으로 고려된다면, 이 경우 Sync Sample List는 다음과 같다.

entry_index	0	1	2
sync_sample_number	0	4	8

음영 동기화 샘플들은, 비록 이것이 요건은 아니더라도, 일반적인 재생 동안 나타나지 않는 트랙의 영역(즉, 편집 목록에 의하여 편집되는 부분) 내에 일반적으로 위치된다. 음영 동기화 샘플들은 일반적인 정방향 재생 동안에 무시된다. shadowed_sample_number는 비동기화 SVG 장면 또는 SVG 장면 갱신 중 하나로 할당될 수 있다. ShadowSyncSampleBox 내의 각각의 (sync_sample_number, shadowed_sample_number) 쌍의 한 맵핑 예가 다음과 같다.

	S	SU	SU	SU	S	SU	SU	SU	S	S	SU	SU	SU
sample_index	0	1	2	3	4	5	6	7	8	9	10	11	12
shadowed_sample_number		0	1	2		3	4	5		6	7	8	9
sync_sample_number		0	0	0		4	4	4		8	8	8	8

비록 인덱스 9를 갖는 샘플이 이러한 예에서 SVG 장면이더라도, 이는 동기화 샘플로 여겨지지 않음을 주의해야 한다. 오히려, shadowed_sample_number는 이러한 장면으로 할당될 수 있다.

전달 설계들 특정 및 상응하는 세션 기술 포맷들. SVG는 동기식 멀티미디어 통합 언어(SMIL, Synchronized Multimedia Integration Language) 미디어 요소들과 유사한 미디어 요소들을 지원한다. 임베드 된 미디어 모두는 동적 및 정적 미디어의 두 부분으로 나뉠 수 있다. 동적 미디어 또는 실시간 미디어 요소들은 그들의 시간 컨테이너 내에서 그들 자신의 시간라인들을 정의한다. 예를 들면,

<audio xlink:href="l.ogg" volume="0.7" type="audio/vorbis"

begin="mybutton.click'' repeatCount="3" />

이미지들과 같은 정적 미디어는 다음과 같은 'image' 요소를 이용하여 SVG 내에 임베딩될 수 있다.

<image x="200" y="200" width="100px" height="100px"

xlink:href="myimage.png''>

SVG는 또한 다른 SVG 문서들을 임베드할 수 있고, 이는 차례로 함유를 통하여 훨씬 더 많은 SVG 문서들을 임베드할 수 있다. 애니메이션 요소는 동기화되고 애니메이션화 된 벡터 그래픽을 제공하는 외부 임베드 된 SVG 문서 또는 SVG 문서 조각을 특정한다. 비디오 요소와 같이, 상기 애니메이션 요소는 그것의 x, y, 즉 넓이와 높이 속성들에 의하여 결정되는 크기를 갖는 그래픽 객체이다. 예를 들면,

유사하게, SVG 내의 미디어는 내부적으로 또는 외부적으로 참조될 수 있다. 앞선 예들이 내부적으로 참조되는 동안, 다음 예가 외부적으로 참조되는 미디어를 보여준다.

<animate attributeName="xlink:href"

values="http://www.example.com/images/l.png;

http://www.example.com/images/2.png;

http://www.example.com/images/3.png"

begin="15s" dur="30s"/>

상기 임베드 된 미디어 요소들은 SVG 콘텐츠 내에서 내부 또는 외부 URL들을 통하여 링크될 수 있다. 이러한 경우, 내부 URLS는 ISO 기반 미디어 파일 자체 내에서 파일 경로들을 참조한다. 외부 URLS는 ISO 기반 미디어 파일 외부의 파일 경로를 참조한다. 본 발명에서, 전달 메커니즘은 내부적으로 임베드 된 미디어에 대해서만 오직 설명된다. 세션 기술 프로토콜(SDP, Session Description Protocol)은 내부적으로 임베드 된 미디어 및 장면 표현에 대하여 상응하여 특정된다.

여기서 논의된 전달 메커니즘들은 오직 내부적으로 임베드 된 미디어에 대하여 제공되었지만, 동시에 상기 수신기는 상기 외부 스트리밍 서버로부터 외부적으로 임베드 된 동적 미디어를 요청할 수 있다. 그러므로 상기 아래 정의된 세션 기술 정보는 내부적으로 임베드 된 미디어에 오직 적용된다.

내부적으로 임베드 된 미디어에 대하여, 동적 미디어 및 정적 미디어 모두 FLUTE에 의하여 전달될 수 있다(한 방향의 전달 상으로 파일 전달). 그러나 그들 중에 오직 동적 미디어만이 RTP에 의하여 전달될 수 있다. 상기 정적 미디어는 그것이 그 자신의 RTP 페이로드 포맷을 가질 때만 RTP에 의하여 전달될 수 있다. 상기 정적 임베드 된 미디어 파일(예를 들면 이미지들)은 (1) FLUTE 세션을 통하여 개선된 UE로 그들을 송신하거나; (2) 보안 키들이 MBMS 세션에 앞서 클라이언트들로 송신되는 방식과 유사한 방식으로 스트리밍 세션 전에 포인트-대-포인트 베어러 상에서 각각의 클라이언트로 정적 미디어를 송신하거나; (3) 만약 충분한 무선 자원들이 이용 가능하다면, 상기 RTP 전달 세션에 무관한 병렬 FLUTE 전달 세션을 갖거나; 또는 (4) 제한된 무선 자원들 때문에 모든 데이터를 전달하기 위하여 비-병렬 전달 세션을 갖는 것에 의하여 정확하게 전송될 수 있다. 각각의 전달 세션은 FLUTE 데이터 또는 RTP 데이터 중 하나를 포함할 수 있다. 추가적으로, RTP SDP 포맷은 SVG 장면 기재들 및 동적 미디어를 전달하도록 특정되고, FLUTE SDP 포맷은 SVG 장면 기재, 동적 및 정적 미디어를 전달하도록 특정된다.

세션 기술 프로토콜은 세션 기술을 특정하기 위한 공통의 실제 포맷이다. 이는 각각의 전달 프로토콜의 세션 기술을 특정하기 위하여 아래에서 이용된다. RTP 패킷들은 장면 기재 및 동적 내부적으로 임베드 된 미디어를 전달하기 위하여 이용될 수 있다. SVG 내의 동적 임베드 된 미디어(예를 들면 비디오)에 대하여, 장면 기재는 다음과 같은 포맷에서 파일들을 어드레싱할 수 있다.

이러한 두 개의 임베드 된 미디어는 item_ID 또는 item_name에 따라 아이템 정보 박스('iinf')에 의하여 어드레싱될 수 있다. 예를 들면, 만약 상기 미디어가 각각 item_ID=2 및 item_ID=4로서 아이템 정보 박스에 의하여 참조되고, 상기 상응하는 item_name이 item_name="video1.263" 및 item_name="video2.263"이라면, 상기 상응하는 SDP 포맷은 다음과 같이 정의될 수 있다.

m=video 49234 RTP/AVP 98 99

a=rtpmap:98 h263-2000/90000

a=fmtp:98 item_ID=2;profile=3;level=10

a=rtpmap:99 h263-2000/90000

a=fmtp:99 item_name="video2.263"; profile=3 ;level=10

메타 박스들을 위한 URL 형태들은 ISO 기반 미디어 파일 포맷에서 정의되어 왔고(ISO/IEC 15444-12 2005, section 8.44.7), 여기서 item_ID 및 item_name은 아이템들을 어드레싱하기 위하여 이용된다. 상기 item_ID 및 item_name은 다른 3GPP 파일 내에 나타난 내부 그리고 외부 동적 미디어 파일 모두를 어드레싱 하고, 이는 필요한 정보 모두가 아이템 위치 박스 및 아이템 정보 박스에서 이용 가능하기 때문이다. 상기 아이템 위치 박스(ItemLocationBox)는 이 동적 임베드 된 미디어의 위치를 제공하고, 상기 아이템 정보 박스(ItemInfoBox)는 이 미디어의 'content_type'을 제공한다. 상기 'content_type'은 MIME 형태이다. 그 영역으로부터, 상기 디코더는 상기 미디어가 어떤 유형인지 알 수 있다. 추가적으로, 3GPP의 확장된 표시 프로필은 메타 박스 내에 ItemInfoBox 및 ItemLocationBox가 있어야하고, 그러한 메타 박스는 루트-레벨 메타 박스인 것을 요구한다.

다른 예에서, 현재 3GPP 파일은 동일한 포맷을 갖는 두 개의 비디오 트랙들을 포함한다. 상기 장면 기재는 트랙들을 어드레싱하기 위하여 다음 텍스트를 이용한다.

상응하는 SDP 포맷은 다음과 같이 정의될 수 있다.

m=video 49234 RTP/AVP 98 99

a=rtpmap:98 h263-2000/90000

a=fmtp:98 box=moov;track_ID=3;profile=3;level=l0

a=rtpmap:99 h263-2000/90000

a=fmtp:99 box=moov;track_ID=5;profile=3;level=l0

FLUTE 패킷들은 장면 기재, 동적 내부적으로 임베드 된 미디어 및 동적 내부적으로 임베드 된 미디어를 전달하기 위하여 이용될 수 있다. 내부적으로 임베드 된 미디어의 URL들은 세션 기술라기보다는, FLUTE 세션의 내부의 파일 전달 테이블(FDT, File Delivery Table) 내에서 표시된다. FLUTE에 대한 SDP 기술의 구문은 Internet-Draft: SDP Descriptors for FLUTE 내에서 정의되어 왔고, 이는 www.ietf.org/internet-drafts/draft-mehta-rmt-flute-sdp-02.txt에서 찾을 수 있다.

SDP 정보를 저장하기 위한 박스들. 현재 ISO 기반 미디어 파일 포맷에서, SDP 정보는 moviehintinformation box 및 trackhintinformation box를 각각 이용하는 영화 및 트랙 레벨들 모두에서 사용자-데이터 박스들 내의 박스들의 세트에 저장된다. moviehintinformation box는 현재 영화에 의하여 어드레싱되는 데이터를 커버하는 세션 기술 정보를 포함한다. 이는 "Movie Box" 하의 사용자 데이터 박스 내에 포함된다. trackhintinformation box는 현재 트랙에 의하여 어드레싱되는 데이터를 커버하는 세션 기술 정보를 포함한다. 이는 "Track Box" 하에 사용자 데이터 박스 내에 포함된다. 그러나 hintinformationbox('hnti')가 영화 및 트랙 레벨들에서 오직 정의됨에 따라, 클라이언트가 상호작용 동안에 특정 아이템의 데이터를 전송할 것을 서버에 요청하는 상황에 대하여 또는 오디오, 비디오, 이미지 파일들 및 XMLBox 내의 XML 데이터가 표시로서 함께 송신되는 것이 필요하다면 원래 ISO 기반 미디어 파일 포맷의 위치 내의 그러한 정보는 없다. 이러한 문제를 제기하기 위하여, 두 개의 추가적인 힌트 정보 컨테이너들이 여기서 정의된다: 'itemhintinformationbox' 및 'presentationhintinformationbox'.

itemhintinformation box는 모든 아이템들에 의여 어드레싱되는 데이터를 커버하는 세션 기술 정보를 포함한다. 이는 메타 박스 내에 포함되고, 이 메타 박스는 파일 구조의 최고 레벨에 있다. 구문은 다음과 같다.

aligned(8) class itemhintinformationbox extends box ('ihib') {

unsigned int(16) entry_count;

for (i=0; i<entry_count; i++) {

unsigned int(l6) item_ID;

string item_name;

Box container_box;

}

itemhintinformationbox는 파일 레벨에서 메타 박스 내의 'other_boxes' 영역 내에 저장된다. "item_ID"는 힌트 정보가 그에 대에 특정된 아이템의 ID를 포함한다. 이는 ItemLocationBox 및 ItemInfoBox 내의 상응하는 아이템과 같은 값을 갖는다. 상기 "item_name"은 아이템의 심벌 네임을 포함하는 UTF-8 캐릭터들 내의 널 종료 스트링이다. 이는 ItemInfoBox 내의 상응하는 아이템과 같은 값을 갖는다. 이는 item_ID가 이용 가능할 때 빈 스트링일 수 있다. 상기 "container_box"는 SDP와 같은 주어진 아이템의 세션 기술 정보를 포함하는 컨테이너 박스이다. 상기 "entry_count"는 다음 어레이 내의 수 개의 엔트리들의 카운트를 제공한다.

상기 presentationhintinformation box는 모든 표시 동안에 어드레싱되는 데이터를 커버하는 세션 기술 정보를 포함한다. 이는 XML 박스 내의 데이터뿐만 아니라, 아이템들 또는 트랙들에 의하여 어드레싱되는 어떠한 데이터라도 포함할 수 있다. 이는 사용자 데이터 박스(User Data Box) 내에 포함될 수 있고, 이 사용자 데이터 박스는 파일 구조의 최고 레벨에 있다. 구문은 다음과 같다.

aligned(8) class presentationhintinformationbox extends box ('phib') {

}

다양한 기술 포맷들이 RTP를 위하여 이용될 수 있다. 이러한 박스들에서, 'sdptext' 영역은 각각이 SDP에 의하여 요구되는 바와 같이(ISO/IEC 15444-12:2005의 section 10.4) <crlf>에 의하여 종료되는, 라인들의 시리즈로서 올바르게 포맷된다. 이러한 경우는 SVG 장면과 장면 갱신들 및 동적 임베드 된 미디어의 전송에 대하여 발생한다. 현재 ISO 기반 미디어 파일 포맷에서, SDP 박스들은 영화 및 트랙 레벨에서만 RTP에 대하여 정의된다. 그러므로 두 개의 추가적인 박스들은 표시 및 아이템 레벨에서 정의된다. 첫 번째로, 표시 레벨 힌트 정보 컨테이너는 'phib' 박스 내에서 정의되고 RTP 전달을 위하여 제공된다. 구문은 다음과 같다.

aligned(8) class rtppresentationhintinformation extends box('rphi') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

상기 미디어 자원들은 예를 들어 다음에서와 같이, 'item_ID', 'item_name', 'box' 또는 'track_ID'를 이용함에 의하여 식별될 수 있다.

....

m=video 49234 RTP/AVP 98 99 100

a=rtpmap:98 h263-2000/90000

a=fmtp:98 box=moov;track_ID=3;profile=3;level=10

a=rtpmap:99 h263-2000/90000

a=fmtp:99 item_ID=2;profile=3;level=10

a=rtpmap:100 h263-2000/90000

a=fmtp:100 item_name="3gpfile.3gp";bow=moov;track_ID=5;profile=3;level=10

....

두 번째로, 아이템 레벨 힌트 정보 컨테이너가 'ihib' 내에서 정의되고 RTP 전달을 위하여 제공된다.

aligned(8) class rtpitemhintinformation extends box('rihi') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

FLUTE를 위한 다양한 기술 포맷들이 있을 수 있다. 오직 SDP 만이 현재 문서에서 정의된다. sdptext는 SDP에 의하여 요구되는 바와 같이, 각각 <crlf>에 의하여 종료되는, 라인들의 시리즈로서 올바르게 포맷된다. 이러한 경우는 SVG 장면 및 장면 업데이트들 및 정적 임베드 된 미디어의 전송에 대하여 발생한다. 현재 ISO 기반 미디어 파일 포맷이 어떠한 레벨(표시, 영화, 트랙, 아이템 등)에서 FLUTE을 위하여 SDP 컨테이너 박스들을 갖지 않음으로써, 모든 이러한 네 개의 레벨들을 위한 박스들은 보이는 바와 같이 정의된다.

표시 레벨 힌트 정보 컨테이너는, FLUTE에 대해 전용의 'phib' 박스 내에서 정의된다. 이는 "현재 표시(current presentation)" 내의 모든 콘텐츠가 FLUTE를 통하여 송신될 때 이용될 수 있다. 구문은 다음과 같다.

aligned(8) class flutepresentationhintinformation extends box('fphi') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

아이템 레벨 힌트 정보 컨테이너는 FLUTE에 대해 전용인 'ihib' 박스 내에서 정의된다. 이것은 "현재 아이템" 내의 모든 콘텐츠가 FLUTE를 통하여 송신될 때 이용될 수 있다. 구문은 다음과 같다.

aligned(8) class fluteitemhintinformation extends box('fihi') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

영화 레벨 힌트 정보 컨테이너는 FLUTE에 대해 전용인 'hnti' 박스 내에서 정의된다. 이것은 "현재 영화" 내의 모든 콘텐츠가 FLUTE을 통하여 송신될 때 이용될 수 있다. 구문은 다음과 같다.

aligned(8) class flutemoviehintinformation extends box('fmhi') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

트랙 레벨 힌트 정보 컨테이너는 FLUTE에 대해 전용인 'hnti' 박스 내에서 정의된다. 이것은 현재 트랙 내의 모든 콘텐츠가 FLUTE을 통하여 송신될 때 이용될 수 있다. 구문은 다음과 같다.

aligned(8) class flutetrackhintinformation extends box('fthi') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

FLUTE + RTP 전달 시스템은 SVG 미디어가 정적 및 동적 임베드 된 미디어 모두를 포함할 때 이용될 수 있다. 상기 정적 미디어는 FLUTE를 통하여 전송되고, 상기 동적 미디어는 RTP를 통하여 전송된다. 상응하여, FLUTE 및 RTP를 위한 SDP 정보는 다음 박스들 내에 저장될 수 있다. 이들은 어플리케이션에 의하여 더 결합될 수 있다.

표시 SDP 정보 (다음 두 개의 박스들은 'phib' 박스 내에 포함된다.)

aligned(8) class flutertppresentationhintinformation extends box('frph') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

aligned(8) class rtpflutepresentationhintinformation extends box('rfph') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

아이템 SDP 정보. (다음 두 개의 박스들은 'ihib' 박스 내에 포함된다.)

aligned(8) class flutertpitemhintinformation extends box('frih') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

aligned(8) class rtpfluteitemhintinformation extends box('rfih') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

영화 SDP 정보. (다음 두 개의 박스들은 영화 레벨 'hnti' 박스 내에 포함된다.)

aligned(8) class flutertpmoviehintinformation extends box('frmh') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

aligned(8) class rtpflutemoviehintinformation extends box('rfmh') {

uint(32) descriptionformat = 'sdp';

char sdptext[];

}

파일 전달 테이블(FDT, File Delivery Table)은 파일 전달 세션 내에서 전달 될 파일들과 관련된 다양한 속성들을 기술하기 위한 메커니즘을 제공한다. 국지적으로, FDT는 세션에서 전달될 파일들에 대한 파일 기재 엔트리들의 세트이다. 각각의 파일 기재 엔트리는 그것이 기술하는 파일에 대한 TOI 및 파일을 식별하는 URI를 포함해야 한다. 각각의 파일 전달 세션은 주어진 세션에 국지적인 FDT를 가져야 한다. 파일 전달 세션 내에서, 상기 FDT는 FDT 보기(FDT Instances)로서 전달된다. FDT 보기는 FDT의 하나 또는 그 이상의 파일 기재 엔트리들을 포함한다. FDT 박스들은 FDT 보기들의 데이터를 저장하기 위하여 여기서 정의되고 이용된다. FDT 박스들은 아래 보이는 바와 같이 네 개의 레벨들-표시, 영화, 트랙 및 아이템에 대하여 정의된다.

두 개의 표시-레벨 FDT 데이터 컨테이너들이 각각 FLUTE 및 FLUTE+RTP 전달 설계들에 대해 전용인 'phib' 박스 내에서 정의된다. 이러한 컨테이너들은 다음과 같이 정의된다.

aligned(8) class flutepresentationfdtinformation extends box('flpf') {

unsigned int(32) fdt_instance_count;

for (i=0; i< fdt_instance_count; i++) {

char fdttext[];

}

aligned(8) class flutertppresentationfdtinformation extends box('frpf') {

unsigned int(32) fdt_instance_count;

for (i=0; i< fdt_instance_count; i++) {

char fdttext[];

}

임베드 된 미디어 자원들의 콘텐츠-위치는 ISO/IEC 15444-12:2005 내의 Section 8.44.7에 정의된 URL 형태들을 이용함에 의하여 참조될 수 있다. 'item_ID', 'item_name', 'box', 'track_ID', '#' 및 '*'는 URL을 가리키기 위하여 이용될 수 있다. 예를 들면,

...

<File

Content-Location="3gpfile.3gp#item_name=tree.html*branch1"

TOI="2"

Content-Type="text/html"/>

...

두 개의 아이템 레벨 FDT 데이터 컨테이너는 각각 FLUTE 및 FLUTE+RTP 전달 설계들에 대해 전용인 'ihib' 박스 내에서 정의된다. 이러한 컨테이너들은 다음과 같이 정의된다.

aligned(8) class fluteitemfdtinformation extends box('flif') {

unsigned int(32) fdt_instance_count;

for(i=0; i< fdt_instance_count; i++) {

char fdttext[];

}

aligned(8) class flutertpitemfdtinformation extends box('frif') {

unsigned int(32) fdt_instance_count;

for(i=0; i< fdt_instance_count; i++) {

char fdttext[];

}

두 개의 영화 레벨 FDT 데이터 컨테이너들이 각각 FLUTE 및 FLUTE+RTP 전달 설계들에 대하여 전용인 영화 레벨 'hnti' 박스 내에서 정의된다. 상기 두 개의 컨테이너들은 다음과 같이 정의된다.

aligned(8) class flutemoviefdtinformation extends box('flmf') {

unsigned int(32) fdt_instance_count;

for(i=0; i< fdt_instance_count; i++) {

char fdttext[];

}

aligned(8) class flutertpmoviefdtinformation extends box('frmf') {

unsigned int(32) fdt_instance_count;

for(i=0; i< fdt_instance_count; i++) {

char fdttext[];

}

트랙 레벨 FDT 데이터 컨테이너는 FLUTE에 대하여 전용인 'hnti' 박스 내에서 정의된다. 이것은 현재 트랙 내의 모든 콘텐츠가 FLUTE를 통하여 송신될 때 이용될 수 있다. 컨테이너는 다음과 같이 정의된다.

aligned(8) class flutetrackfdtinformation extends box('fdtt') {

char fdttext[];

}

힌트 트랙 정보(Hint Track Information). 힌트 트랙 구조는 복수의 데이터 포맷들에서 힌트 샘플들을 지원하기 위하여 일반화된다. 힌트 트랙 샘플은 올바른 형태의 패킷 헤더를 수립하기 위하여 필요한 어떠한 데이터를 포함하고, 또한 패킷에 속하는 데이터의 블록으로의 포인터를 포함한다. 그러한 데이터는 SVG, 동적 및 정적 임베드 된 미디어를 포함할 수 있다. 힌트 트랙 샘플들은, 비록 그들이 동일한 파일 내에서 일반적으로 발견된다 한지라도, 힌트 트랙 박스 구조의 일부가 아니다. 힌트 트랙 데이터 참조 박스('dref') 및 샘플 테이블 박스('stbl')는 특정 샘플을 위한 파일 명세 및 바이트 오프셋을 찾기 위하여 이용될 수 있다. 힌트 트랙 샘플 데이터는 바이트-정렬되어 있고 항상 빅-엔디안(big-endian) 포맷에 있다.

사용자 상호작용 동안, 클라이언트는 RTP를 통하여 동적이고 내부적으로 임베드 된 미디어를 송신할 것을 서버에 요청할 수 있다. 그러한 미디어의 메타데이터는 아이템들 내에 저장될 수 있다. RTP 힌트 트랙 포맷은 한 아이템을 위한 RTP 스트림을 생성하기 위하여 이용될 수 있다. 아이템으로부터 RTP 패킷들의 효과적인 생성을 허용하기 우하여, 아이템 레벨에서 생성자의 이러한 유형에 대한 구문이 다음과 같이 정의된다. 영역들은 ISO 15444-12:2005 section 10.3.2 내의 포맷에 기반을 둔다.

aligned(8) class RTPitemconstructor extends RTP constructor(4) {

unsigned int(16) item_ID;

unsigned int(16) extent_index;

unsigned int(64) data_offset; //offset in byte within extent

unsigned int(32) data_length; //length in byte within extent

}

새로운 생성자는 또한 XMLBox 또는 BinaryXMLBox로부터 RTP 패킷들의 효율적인 생성을 제공하도록 정의된다. 이러한 생성자를 위한 구문은 다음과 같다.

aligned(8) class RTPxmlboxconstructor extends RTPconstructor(5)

{

unsigned int(64) data_offset; //offset in byte within XMLBox or BinaryXMLBox

unsigned int(32) data_length;

unsigned int(32) reserved;

}

이러한 생성자 포맷들에 기반을 두어, 힌트 트랙은 'mdat' 박스, XMLBox 또는 임베드 된 미디어 파일들로부터 데이터를 위한 RTP 패킷들을 효과적으로 생성할 수 있고, 모든 데이터의 조합을 위하여 RTP 스트림을 만들 수 있다.

FLUTE 패킷들의 생성을 편리하게 하기 위하여, FLUTE을 위한 힌트 트랙 포맷이 아래 정의된다. RTP 힌트 트랙의 계층에 유사하게, FluteHintSampleEntry 및 FLUTEsample이 정의된다. 추가적으로, 관련된 구조들 및 생성자들이 또한 정의된다.

FLUTE 힌트 트랙들은 'flut'의 샘플 기재 내에 엔트리포맷을 갖는 힌트 트랙들(미디어 핸들러 'hint')이다. FluteHintSampleEntry는 다음과 같은 구문을 가지고 SampleDescriptionBox('stsd') 내에 포함된다.

class FluteHintSampleEntry() extends SampleEntry ('flut') {

uint(16) hinttrackversion = 1;

uint(16) highestcompatibleversion = 1;

uint(32) maxpacketsize;

box additionaldata[]; //optional

}

영역들, "hinttrackversion", "highestcompatibleversion" 및 "maxpacketsize"는 ISO/IEC 15444-12:2005 명세의 섹션 10.2에 설명된 "RtpHintSampleEntry" 영역 내에 있는 것과 동일한 해석을 갖는다. 추가적인 데이터는, ISO/IEC 15444-12:2005 섹션 10.2에서 참조되는 timescaleentry 및 timeoffset으로부터의 박스들의 세트이다. 이러한 박스들은 FLUTE에 대하여 선택적이다.

힌트 트랙 내의 각각의 FLUTE 샘플이 하나 이상의 FLUTE 패킷들을 생성할 것이다. RTP 샘플들에 비교되면, FLUTE 샘플들은 그들 자신의 특정 타임스탬프들을 갖지 않지만, 대신에 연속적으로 송신된다. TimeToSampleBox에 저장된 샘플-델타를 고려하면, 만약 FLUTE 샘플들이 임베드 된 미디어 또는 SVG 콘텐츠의 조각들을 나타낸다면, 이 경우 현재 미디어/SVG의 첫 번째 샘플과 이전 미디어/SVG의 마지막 샘플 사이에 샘플-델타는 현재 및 이전 미디어/SVG가 속하는 장면/갱신의 시작 시간 사이에 차이와 같은 값을 갖는다. 현재 미디어/SVG 내의 연속적인 샘플들 중 나머지에 대한 샘플 델타들은 0이다. 그러나 만약 FLUTE 샘플이 전체 미디어 또는 SVG 콘텐츠를 나타낸다면, 이 경우 이러한 FLUTE 샘플을 뒤따르는 0과 같은 델타들을 갖는 어떠한 연속적인 샘플들(동일한 미디어/SVG로부터의 연속적인 데이터를 포함한다)도 없을 것이다. 그러므로 오직 한 샘플-델타만이 현재 FLUTE 샘플에 대하여 존재한다. 각각의 샘플은 두 개의 영역을 포함한다: 패킷들을 구성하기 위한 명령어들, 및 그러한 패킷들을 송신할 때 필요한 어떠한 추가적인 데이터(예를 들면 미디어 데이터의 부호화 된 버전). 샘플의 크기는 샘플 크기 테이블로부터 알 수 있음을 인지해야 한다.

aligned(8) class FLUTEsample {

unsigned int(16) packetcount;

unsigned int(16) reserved;

FLUTEpacket packets[packetcount];

byte extradata[]; //optional

}

패킷 엔트리 테이블 내의 각각의 패킷은 다음 구조를 갖는다.

aligned(8) class FLUTEpacket {

FLUTEheader flute_header;

unsigned int(16) entrycount;

dataentry constructors[entrycount];

}

aligned(8) class FLUTEheader

{

UDPheader header;

LCTheader lct_header;

variable FEC_payload_ID;

}

"flute_header" 영역은 현재 FLUTE 패킷에 대한 헤더를 포함한다. "entry_count" 영역은 다음 생성자의 카운트이고, "construtors" 영역은 FLUTE 패킷들을 구성하기 위하여 이용되는 구조를 정의한다. FEC_payload_ID는 세션 기재 내에서 통신되어야 하는 FEC Encoding ID에 의하여 결정된다. 아래서 이용되는 'FEC_encoding_ID'는 세션 기재 내에서 시그널링 되어야 한다.

다음 구문의 상세한 내용은 참고자료 Request for Comments (RFC) 3926, 3450 and 3451 of the Network Working Group에 기반을 둔다.

class pseudoheader {

unsigned int(32) source_address;

unsigned int(32) destination_address;

unsigned int(8) zero;

unsigned int(8) protocol;

unsigned int(16) UDP_length;

}

class UDPheader {

pseudoheader pheader;

unsigned int(16) source_port;

unsigned int(16) destination_port;

unsigned int(l6) length;

unsigned int(l6) checksum;

}

class LCTheader {

unsigned int(4) V_bits;

unsigned int(2) C_bits;

unsigned int(2) reserved;

unsigned int(1) S_bit;

unsigned int(2) O_bits;

unsigned int(1) H_bit;

unsigned int(1) T_bit;

unsigned int(2) R_bit;

unsigned int(2) A_bit;

unsigned int(2) B_bit;

unsigned int(8) header_length;

unsigned int(8) codepoint

unsigned int((C_bits+1)*32) congestion_control_information;

unsigned int(S_bit*32 + H_bit*16) transport_session_identifier;

unsigned int(O_bits*32 + H_bit*16) transport_object_identifier; //For EXT_FDT, TOI=0

if(T_bit== 1) {

unsigned int(32) sender_current_time;

}

if(T_bit == 1) {

unsigned int(32) expected_residual_time;

}

if (header_length > (32 + (C_bits+1)*32 + S_bit*32 + H_bit*16 + O_bits*32 + H_bit*16)) {

LCTheaderextentions header_extention;

}

class LCTheaderextentions {

unsigned int(8) header_extention_type; //192-EXT_FDT, 193- EXT_CENC, 64-EXT_FTI

if (header_extention_type<= 127) {

unsigned int(8) header_extention_length;

}

if (header_extention_type == 64) {

unsigned int(48) transfer_length;

if ((FEC_encoding_ID == 0)||(FEC_encoding_ID == 128)||(FEC_encoding_ID ==130)) {

unsigned int(16) encoding_symbol_length;

unsigned int(32) max_source_block_length;

}

else if((FEC_encoding_ID>=128)||(FEC_encoding_ID<=255)) {

unsigned int(16) FEC_instance_ID;

}

else if(FEC_encoding_ID == 129) {

unsigned int(l6) encoding_symbol_length;

unsigned int(16) max_source_block_length;

unsigned int(16) max_num_of_encoding_ symbol;

}

else if(header_extention_type == 192){

unsigned int(4) version = 1;

unsigned int(20) FDT_instance_ID;

}

else if(header_extention_type == 193){

unsigned int(8) content_encoding_algorithm; //ZLIB,DEFLATE,GZIP

unsigned int(16) reserved = 0;

}

else {

byte other_extentions_content[];

}

생성자의 다양한 형태들이 있다. 각각의 생성자는 반복(iteration)을 쉽게 만들기 위하여 16 바이트이다. 첫 번째 바이트는 결합 식별자(union discriminator)이다. 이러한 구조는 ISO/IEC 15444-12:2005로부터의 섹션 10.3.2에 기반을 둔다.

aligned(8) class FLUTEconstructor(type) {

unsigned int(8) constructor_type = type;

}

aligned(8) class FLUTEnoopconstructor extends FLUTEconstructor(0)

{

uint(8) pad[15];

}

aligned(8) class FLUTEimmediateconstructor extends FLUTEconstructor(1)

{

unsigned int(8) count;

unsigned int(8) data[count];

unsigned int(8) pad[14 - count];

}

aligned(8) class FLUTEsampleconstructor extends FLUTEconstructor(2)

{

signed int(8) trackrefindex;

unsigned int(16) length;

unsigned int(32) samplenumber;

unsigned int(32) sampleoffset;

unsigned int(16) bytesperblock = 1;

unsigned int(16) samplesperblock = 1;

}

aligned(8) class FLUTEsampledescriptionconstructor extends FLUTEconstructor(3)

{

signed int(8) trackrefindex;

unsigned int(16) length.;

unsigned int(32) sampledescriptionindex;

unsigned int(32) sampledescriptionoffset;

unsigned int(32) reserved;

}

aligned(8) class FLUTEitemconstructor extends FLUTEconstructor(4)

{

unsigned int(16) item_ID;

unsigned int(16) extent_index;

unsigned int(64) data_offset; //offset in byte within extent

unsigned int(32) data_length; //length in byte within extent

}

aligned(8) class FLUTExmlboxconstructor extends FLUTEconstructor(5)

{

unsigned int(64) data_offset; //offset in byte within XMLBox or BinaryXMLBox

unsigned int(32) data-length;

unsigned int(32) reserved;

}

FDT 데이터는 전체 FLUTE 데이터 스트림의 한 부분이다. 이러한 데이터는 FLUTE 패킷들의 형태에서 FLUTE 세션 동안에 송신된다. 그러므로 생성자는 FLUTE 패킷으로 FDT 데이터를 맵핑하기 위하여 필요하다. 생성자의 구문은 다음과 같이 제공된다.

aligned(8) class FLUTEfdtconstructor extends FLUTEconstructor(6)

{

unsigned int(2) fdt_box; //0-'fdtp', 1-'fdtm', 2-'fdti', 3-'fdtt'

if((fdt_box==0)||(fdt_box==l)||(fdt_box==2)) {

unsigned int(30) instance_index; //index of the FDT instance

unsigned int(64) data_offset; //offset in byte within the given FDT instance

unsigned int(32) data_length; //length in byte within the given FDT instance

} else {

unsigned int(64) data_offset; //offset in byte within the given FDT box

unsigned int(32) data_length; //length in byte within the given FDT box

bit pad[30]; //padding bits

}

RTP 및 FLUTE 패킷들 모두가 표시 동안에 동시에 송신되는 경우에, RTP 및 FLUTE 모두를 위한 생성자들이 이용된다. RTP 패킷들은 동적 미디어 및 SVG 콘텐츠를 송신하기 위하여 이용되고, FLUTE 패킷들은 정적 미디어를 송신하기 위하여 이용된다. 다른 힌트 메커니즘이 이러한 경우를 위하여 이용된다. 그러한 메커니즘은 올바름 시간 차수에서 RTP 및 FLUTE 샘플들 모두를 결합할 수 있다. 표시를 위한 FLUTE 및 RTP 패킷들의 생성을 편리하게 하기 위하여, FLUTE+RTP를 위한 힌트 트랙 포맷이 아래 정의된다. RTP 및 FLUTE 힌트 트랙들의 계층과 유사하게, FluteRtpHintSampleEntry 및 FLUTERTP 샘플이 정의된다. 추가적으로, TimeToSampleBox 내의 데이터가 각각의 패킷에 대한 시간 정보를 준다.

FLUTE+RTP 힌트 트랙들은 "frhs"의 샘플 기재 내에 엔트리-포맷을 갖는 힌트 트랙들(미디어 핸들러 'hint')이다. FluteRtpHintSampleEntry는 SampleDescriptionBox "stsd" 내에서 정의된다.

class FluteRtpHintSampleEntry() extends SampleEntry ('frhs') {

uint(16) hinttrackversion = 1;

uint(16) highestcompatibleversion = 1;

uint(32) maxpacketsize;

box additionaldata[];

}

hinttrackversion은 현재 1이고; 최고 호환 가능한 버전(highest compatible version) 영역은 이 트랙이 역방향으로 호환 가능한 가장 오래된 버전을 특정한다. maxpacketsize는 이 트랙이 생성될 최대 패킷의 크기를 가리킨다. 추가적인 데이터는 박스들의 세트('tims' 및 'tsro')이고, 이는 ISO 기반 미디어 파일 포맷 내에서 정의된다.

FLUTERTPSample은 MediaDataBox('mdat') 내에서 정의된다. 이러한 박스는 복수의 FLUTE 샘플들, RTP 샘플들, 가능한 FDT 및 SDP 정보 및 어떠한 추가 데이터를 포함한다. 하나의 FLUTERTPSample은 FDT 데이터, SDP 데이터, FLUTE 샘플, 또는 RTP 샘플을 포함할 수 있다. FLUTE 샘플들을 포함하는 FLUTERTPSamples는 정적 미디어를 전송하기 위하여 오직 이용된다. 그러한 미디어는 SVG 표시 중에서 장면 또는 장면 갱신 내에 항상 임베드 된다. 그들의 시작 시간은 그들이 속하는 장면/장면 갱신의 시작 시간과 같다. FLUTE 샘플들은 그들 자신의 특정 타임스탬프를 갖지 않고, 대신에 그들이 속한 장면/장면 갱신의 RTP 샘플들 바로 다음에, 연속적으로 송신된다. 그러므로 TimeToSampleBox에서, 정적 미디어를 위한 FLUTERTPSample의 샘플 델타들은 모두 0으로 설정된다. 그들의 연속적인 순서는 그들의 송신-시간 순서를 나타낸다.

UE는 제한된 전력을 가질 수 있고 어떠한 시간 순간에 오직 한 전송 세션을 지원할 수 있으며, FLUTE 세션들 및 RTP 세션들은 하나씩 인터리브 될 필요가 있다. 한 세션은 나머지가 종료된 후에 즉시 시작된다. 이러한 경우, description_text1, description_text2 및 description_text3 영역은 아래서 각각의 세션에 대한 SDP 및 FDT 정보를 제공하기 위하여 이용된다.

aligned(8) class FLUTERTPSample {

unit(2) sample_type;

unsigned int(6) reserved;

if (sample_type == 0) {

char fdttext[]; //FDT info for following samples

}

else if (sample_type == 1) {

char sdptext[]; //SDP info for following samples

}

else if(sample_type == 2) {

FLUTEsample flute_sample;

}

else {

RTPsample rtp_sample;

}

byte extradata[];

샘플 그룹 기술 박스(Sample Group Description Box). 어떠한 코딩 시스템들에서, 수 개의 샘플들을 복호화한 후에 임의로 스트림으로 접근하고 올바른 복호화를 성취하는 것이 가능하다. 이는 점진적인 리프레시(gradual refresh)로서 알려져 있다. SVG에서, 인코더는 두 개의 랜덤 접근점들(SVG 장면들) 사이의 그리고 동일한 롤(roll) 거리를 갖는 SVG 샘플들(장면들 및 갱신들)의 그룹을 부호화할 수 있다. 추상 클래스는 SampleGroupDescriptionBox(sgpd) 내에서 SVG 시퀀스에 대하여 정의된다. 그러한 설명적인 엔트리들이 SVG 샘플 그룹을 정의하거나 특징짓기 위하여 필요하다. 구문은 다음과 같다.

// SVG sequence

abstract class SVGSampleGroupEntry (type) extends SampleGroupDescriptionEntry (type) {

}

랜덤 접근 복구 점들(Random Access Recovery Points). 점진적인 리프레시가 가능한 SVG 샘플들은 수개의 이러한 SVG 그룹이 있음에 의하여 표시된다. SVG 롤 그룹은 SVG 샘플들의 그룹은 동일한 롤 거리를 갖도록 정의된다. 상응하는 구문은 다음과 같다.

class SVGRollRecoveryEntry() extends SVGSampleGroupEntry ('roll') {

signed int(16) roll_distance;

본 발명의 추가적이고 대안의 수개의 실시들이 일반적으로 다음과 같다: 제2 실시는 앞서 논의된 제1 실시와 같지만, 재배열된 영역들을 갖는다.

본 발명의 제3 실시는 앞서 논의된 제1 실시와 유사하지만, 영역들의 길이들이 어플리케이션 의존도에 기반을 두고 변경된다. 특히, 특정 영역들은 특정 값들보다 더 짧거나 길 수 있다.

본 발명의 제4 실시는 앞서 상세하게 논해진 제1 실시와 본질적으로 동일하다. 그러나 제4 실시에서, SVG를 위한 어떠한 적절한 압축 방법이 샘플 기재 박스를 위하여 이용될 수 있다.

본 발명의 제5 실시는 SVG 버전 및 기본 프로필들이 SVG의 더 새로운 버전들 및 컴플라이언스(compliance)에 기반을 두고 갱신될 수 있다.

본 발명의 제6 실시는 또한 앞서 논의된 제1 실시와 유사하다. 그러나 이러한 실시에서, SVGSampleEntry 박스 내에서 특정된 파라미터들 중 일부 또는 모두가 SVG 파일 그 자체 내에서 정의될 수 있고, ISO 기반 미디어 파일 생성기가 샘플에 대한 정보를 획득하기 위하여 XML-유사 SVG 콘텐츠를 조사할 수 있다.

본 발명의 제7 실시는 또한 제1 실시와 유사하다. 그러나 SDP 정보를 저장하기 위한 박스들의 아이템들에서, 하나가 예를 들면 표시-레벨 inor 아이템-레벨 세션 정보를 포함하기 위하여 다른 레벨들에서 'hnti' 박스를 다시 정의할 수 있다.

제8 실시는 또한 제1 실시와 유사하다. 그러나 RTP 전달 메커니즘을 위한 SDP 박스들, FLUTE 전달 메커니즘을 위한 SDP 박스들, 및 FLUTE+RTP 전달 메커니즘을 위한 SDP 박스들에 대하여, 다른 기술 포맷들이 저장될 수 있다. 그러한 경우, 'sdptext' 영역은 따라서 변할 것이다.

제9 실시에서, FLUTE를 위한 FDT 박스들에 대하여, 모든 FDT 데이터가 경우들, 즉 조각들 또는 단일 파일 기재들로 나뉠 수 있다. 그러나 'FDT 경우'는 FLUTE 전송에서 일반적으로 이용된다.

본 발명의 제10 실시에서, FLUTE를 위한 FDT 박스들에 대하여, 단일 'fdttext' 영역은 FDT 데이터 모두를 포함할 수 있다. 어플리케이션은 모든 레벨들에 대해 또는 파일들에 대해 이러한 데이터 조각 중 하나를 선택할 수 있다.

본 발명의 제11 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, RTPconstructor(4) 및 RTPconstructor(5)의 식별자는 상호 교환 가능하다.

본 발명의 제12 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, item_ID 영역은 item_name으로 교체될 수 있다.

본 발명의 제13 실시에서, 또한 RTP를 위한 힌트 트랙 포맷에 대하여, data_length 영역이 예약된 영역을 제거함에 의하여 64 바이트로 만들어질 수 있다.

본 발명의 제14 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, data_length 영역이 16 바이트로 만들어지고 64 바이트로 예약된 영역을 조절할 수 있다.

본 발명의 제15 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, hinttrackversion 및 highestcompatibleversion 영역들은 다른 값들을 가질 수 있다.

본 발명의 제16 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, minpacketsize 영역은 maxpacketsize에 추가하여 추가될 수 있다.

본 발명의 제17 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, packetcount 영역이 예약된 영역을 제거함에 의하여 32비트로 만들어질 수 있다.

본 발명의 제18 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, 다른 헤더 박스들(예를 들면 FLUTEheader, UDPheader, LCTheader 등)의 계층 구조는 다를 수 있다.

본 발명의 제19 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, FLUTEfdtconstructor 구문은 각각의 FDT_box에 대하여 별개의 영역 정의들을 가질 수 있다.

본 발명의 제20 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, fluteitemconstructor는 item_name에 의하여 교체된 item_id를 가질 수 있다.

본 발명의 제21 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, flutexmlboxconstructor는 예약된 영역을 제거함에 의하여 64 바이트로 만들어 질 data_length 영역을 가질 수 있다.

본 발명의 제22 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, flutexmlboxconstructor는 16 바이트로 만들어 질 data_length 영역을 가질 수 있고 64 바이트로 예약된 영역을 조절할 수 있다.

본 발명의 제23 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, FluteRtpHintSampleEntry는 다른 값들일 hinttrackversion 및 highestcompatibleversion 영역들을 가질 수 있다.

본 발명의 제24 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, FluteRtpHintSampleEntry는 maxpacketsize 영역에 추가하여 minpaketsize 영역을 추가할 수 있다.

본 발명의 제25 실시에서, RTP를 위한 힌트 트랙 포맷에 대하여, FLUTERTPSample 박스는 각각의 sample_type에 대하여 별개의 영역 정의들을 가질 수 있다.

도 1은 본 발명이 이용될 수 있는 시스템(10)을 보여주고, 이는 네트워크를 통하여 통신할 수 있는 복수의 통신 장치들을 포함한다. 상기 시스템(10)은 모바일 전화 네트워크, 무선 근거리 통신망(LAN, Local Area Network), 블루투스 개인 영역 네트워크, 이더넷 LAN, 토큰 링(token ring) LAN, 광역 통신만, 인터넷들을 포함하는 유선 또는 무선 네트워크들의 어떠한 조합을 포함할 수 있지만, 이에 한정되는 것은 아니다. 상기 시스템(10)은 유선 및 무선 통신 장치들 모두를 포함할 수 있다.

예시를 위하여, 도 1에 보인 시스템(10)은 모바일 전화 네트워크(11) 및 인터넷(28)을 포함한다. 인터넷(28)으로 연결성은 장거리 무선 연결들, 단거리 무선 연결들, 및 전화 선들, 케이블 선들, 전력 선들, 및 유사한 것을 포함하지만 이에 한정되지 않는 다양한 유선 연결들을 포함할 수 있고, 그렇지만 이에 한정되지 않는다.

상기 시스템(10)의 예시적인 통신 장치들은 모바일 전화(12), PDA 및 모바일 전화 결합(14), PDA(16), 집적 메시징 장치(IMD, integrated messaging device, 18), 데스크톱 컴퓨터(20), 및 노트북 컴퓨터(22)를 포함할 수 있지만 이에 한정되지 않는다. 상기 통신 장치들은 동적이거나 움직이는 개인에 의하여 이동될 때와 같이 이동할 수 있다. 상기 통신 장치들은 또한 자동차, 트럭, 택시, 버스, 보트, 비행기, 자전거, 오토바이 등을 포함하지만 이에 한정되지 않는 운송 모드에 위치될 수 있다. 상기 통신 장치들 중 일부 또는 전부는 호들 및 메시지들을 송신하거나 수신할 수 있고 기지국(24)으로 무선 연결(25)을 통하여 서비스 제공자들과 통신할 수 있다. 기지국(24)은 모바일 전화 네트워크(11) 및 인터넷(28) 사이에 통신을 허용하는 네트워크 서버(26)로 연결될 수 있다. 상기 시스템(10)은 추가적인 통신 장치들 및 다른 유형의 통신 장치들을 포함할 수 있다.

상기 통신 장치들은 코드 분할 다중 접속(Code Division Multiple Access , CDMA), GSM(Global System for Mobile Communications), 범용 이동 통신 시스템(Universal Mobile Telecommunications System, UMTS), 시분할 다중 접속(Time Division Multiple Access, TDMA), 주파수 분할 다중 접속(Frequency Division Multiple Access, FDMA), 전송 제어 프로토콜/인터넷 프로토콜(Transmission Control Protocol/Internet Protocol, TCP/IP), 문자 메시지 서비스(Short Messaging Service, SMS), 멀티미디어 메시지 서비스(Multimedia Messaging Service, MMS), 이메일, 인스턴트 메시지 서비스(Instant Messaging Service, IMS), 블루투스(Bluetooth), IEEE 802.11. 등을 포함하지만 이에 한정되지 않는 다양한 전송 기술들을 이용하여 통신할 수 있다. 통신 장치는 무선, 적외선, 레이저, 케이블 연결, 및 유사한 것을 포함하지만 이에 한정되지 않는 다양한 매체를 이용하여 통신할 수 있다.

도 2 및 3은 본 발명이 실시될 수 있는 한 대표적인 모바일 전화(12)를 보여준다. 그러나 본 발명은 모바일 전화(12) 또는 다른 전자 장치의 한 특정 유형에 한정되려고 의도되지 않음을 이해해야 한다. 도 2 및 3의 모바일 전화(12)는 하우징(30), 액정 디스플레이 형태의 디스플레이(32), 키패드(34), 마이크로폰(36), 이어-피스(38), 배터리(40), 적외선 포트(42), 안테나(44), 본 발명의 일 실시예에 따른 UICC 형태의 스마트카드(46), 카드 리더(48), 무선 인터페이스 회로단(52), 코덱 회로단(54), 제어부(56) 및 메모리(58)를 포함한다. 개별 회로들 및 요소들은 본 기술분야, 예를 들면 모바일 전화의 Nokia 범위에서 모두 잘 알려진 형태이다.

본 발명은 방법 단계들의 일반적인 내용에서 묘사되고, 이는 네트워크화 된 환경에서 컴퓨터들에 의하여 실행되는, 프로그램 코드와 같은, 컴퓨터 실행가능 명령어들을 포함하는 프로그램 제품에 의하여 한 실시예에서 구현될 수 있다.

일반적으로, 프로그램 모듈들은 특정 작업들을 수행하거나 특정 추상 데이터 유형들을 구현하는 루틴들, 프로그램들, 객체들, 콤포넌트들, 데이터 구조들 등을 포함한다. 데이터 구조에 관련된 컴퓨터 실행가능 명령어들 및 프로그램 모듈들은 여기서 개시된 방법들의 단계들을 실행하기 위한 프로그램 코드의 예를 나타낸다. 그러한 실행 가능한 명령어들 또는 관련된 데이터 구조들의 특정 시퀀스는 그러한 단계들에서 묘사되는 기능들을 구현하기 위하여 상응하는 동작들의 예들을 나타낸다.

본 발명의 소프트웨어 및 웹 구현들은 규칙 기반 로직을 갖는 표준 프로그래밍 기술들, 및 다양한 데이터베이스 탐색 단계들, 상관관계들, 비교 단계들 및 결정 단계들을 달성하기 위한 다른 로직으로 달성될 수 있다. 또한 이겨서 그리고 청구항들에서 이용되는 바와 같은 단어들 "콤포넌트(component)" 및 "모듈"은 소프트웨어 코드의 하나 또는 그 이상의 라인들을 이용하는 구현들, 하드웨어 구현들, 및/또는 수동 입력들을 수신하기 위한 장비들을 포괄하도록 의도되었음이 인지되어야 한다.

본 발명의 실시예들의 앞선 설명은 묘사 및 설명의 목적을 위하여 나타냈다. 이것은 개시된 정확한 형태로 본 발명을 구속하거나 한정하려는 의도가 아니며, 수정 및 변형들이 앞선 교사들의 견지에서 가능하거나 본 발명의 실시로부터 획득될 수 있다. 실시예들이 본 기술 분야의 통상의 기술자가 다양한 실시예들에서 그리고 고려된 특정 이용에 적절하도록 다양한 수정들을 가지고 본 발명을 이용하는 것이 가능하게 하기 위하여 본 발명의 원칙들 및 그것의 실제 적용을 설명하기 위하여 선택되고 묘사되었다.

Claims

클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법에 있어서,

SVG를 포함하는 리치 미디어 콘텐츠를 제공하는 단계;

ISO 기반 미디어 생성기를 이용하여 상기 리치 미디어 콘텐츠로부터 ISO 기반 미디어 파일을 생성하는 단계로서, SVG 미디어 트랙을 포함하는 상기 ISO 기반 미디어 파일은, 각각이 상기 SVG와 관련된 샘플 테이블 박스 및 복호화 시간-대-샘플 박스 중 적어도 하나를 포함하는, ISO 기반 미디어 파일을 생성하는 단계;

상기 ISO 기반 미디어 파일을 부호화하는 단계; 및

상기 클라이언트 장치로 복수의 패킷들 내에서 상기 부호화된 ISO 기반 미디어 파일을 송신하는 단계를 포함하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제1항에 있어서,

상기 클라이언트 장치에 도달하면, 상기 부호화 된 ISO 기반 미디어 파일을 복호화 하는 단계; 및

상기 ISO 기반 미디어 파일을 추출하는 단계를 더 포함하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제1항에 있어서, 상기 SVG 미디어 트랙은 상기 ISO 기반 미디어 파일 내에 포함된 미디어 객체들을 기재하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제3항에 있어서, 상기 SVG 미디어 트랙은 상기 SVG 미디어 트랙 내에 포함된 미디어 샘플들에 대한 시간 및 데이터 인덱스를 포함하는 상기 샘플 테이블 박스를 포함하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제3항에 있어서, 상기 SVG 미디어 트랙은 미디어 샘플에 특정된 정보를 포함하는 샘플 기술 박스를 포함하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제3항에 있어서, 상기 SVG 미디어 트랙은 상기 복호화 시간-대-샘플 박스를 포함하고, 상기 복호화 시간-대-샘플 박스는 상기 SVG 미디어 트랙 내에서 각각의 미디어 샘플에 대하여 복호화 시간을 특정하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제1항에 있어서, 상기 ISO 기반 미디어 파일은 힌트 트랙 샘플을 포함하고, 상기 힌트 트랙 샘플은 각각의 패킷 내에서 송신될 데이터를 포함하거나 가리키는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
제1항에 있어서, 상기 ISO 기반 미디어 파일은 음영(shadow) 동기화 테이블을 포함하고, 상기 음영 동기화 테이블은 랜덤 접근을 지원하기 위하여 이용되는 샘플들을 포함하는, 클라이언트 장치로 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 방법.
컴퓨터 프로그램을 저장하는 컴퓨터 판독가능 매체에 있어서, 상기 컴퓨터 프로그램은, 클라이언트 장치에 리치 미디어 콘텐츠를 프로그레시브하게 제공하도록 구성되고,

SVG를 포함하는 리치 미디어 콘텐츠를 제공하기 위한 컴퓨터 코드;

ISO 기반 미디어 생성기를 이용하여 상기 리치 미디어 콘텐츠로부터 ISO 기반 미디어 파일을 생성하기 위한 컴퓨터 코드로서, SVG 미디어 트랙을 포함하는 상기 ISO 기반 미디어 파일은, 각각이 SVG와 관련된 샘플 테이블 박스 및 복호화 시간-대-샘플 박스 중 적어도 하나를 포함하는, ISO 기반 미디어 파일을 생성하기 위한 컴퓨터 코드;

상기 ISO 기반 미디어 파일을 부호화하기 위한 컴퓨터 코드; 및

상기 클라이언트 장치로 복수의 패킷들 내에서 상기 부호화 된 ISO 기반 미디어 파일을 송신하기 위한 컴퓨터 코드를 포함하는, 클라이언트 장치에 리치 미디어 콘텐츠를 프로그레시브하게 제공하는 컴퓨터 판독가능 매체.
제9항에 있어서, 상기 컴퓨터 프로그램은,

상기 클라이언트 장치에 도달하면, 상기 부호화 된 ISO 기반 미디어 파일을 복호화하기 위한 컴퓨터 코드; 및

상기 ISO 기반 미디어 파일을 추출하기 위한 컴퓨터 코드를 더 포함하는, 컴퓨터 판독가능 매체.
제9항에 있어서, 상기 SVG 미디어 트랙은 상기 ISO 기반 미디어 파일 내에 포함된 미디어 객체를 기재하는, 컴퓨터 판독가능 매체.
제11항에 있어서, 상기 SVG 미디어 트랙은 상기 SVG 미디어 트랙 내에 포함된 상기 미디어 샘플들에 대한 시간 및 데이터 인덱스를 포함하는 상기 샘플 테이블 박스를 포함하는, 컴퓨터 판독가능 매체.
제11항에 있어서, 상기 SVG 미디어 트랙은 미디어 샘플에 특정된 정보를 포함하는 샘플 기술 박스를 포함하는, 컴퓨터 판독가능 매체.
제11항에 있어서, 상기 SVG 미디어 트랙은 상기 복호화 시간-대-샘플 박스를 포함하고, 상기 복호화 시간-대-샘플 박스는 상기 SVG 미디어 트랙 내의 각각의 미디어 샘플에 대한 복호화 시간을 특정하는, 컴퓨터 판독가능 매체.
제9항에 있어서, 상기 ISO 기반 미디어 파일은 힌트 트랙 샘플을 포함하고, 각각의 패킷 내에서 송신될 데이터를 포함하거나 가리키는, 컴퓨터 판독가능 매체.
제9항에 있어서, 상기 ISO 기반 미디어 파일은 음영 동기화 테이블을 포함하고, 상기 음영 동기화 테이블은 랜덤 접근을 지원하기 위하여 이용되는 샘플들을 포함하는, 컴퓨터 판독가능 매체.
전자 장치에 있어서,

프로세서; 및

상기 프로세서로 기능적으로 연결된 메모리부로서,

SVG를 포함하는 리치 미디어 콘텐츠를 제공하기 위한 컴퓨터 코드;

ISO 기반 미디어 생성기를 이용하여 상기 리치 미디어 콘텐츠로부터 ISO 기반 미디어 파일을 생성하기 위한 컴퓨터 코드로서, SVG 미디어 트랙을 포함하는 상기 ISO 기반 미디어 파일은 각각이 SVG와 관련된 샘플 테이블 박스 및 복호화 시간-대-샘플 박스 중 적어도 하나를 포함하는, ISO 기반 미디어 파일을 생성하기 위한 컴퓨터 코드;

상기 ISO 기반 미디어 파일을 부호화하기 위한 컴퓨터 코드; 및

상기 클라이언트 장치로 복수의 패킷들 내에서 상기 부호화 된 ISO 기반 미디어 파일들을 송신하기 위한 컴퓨터 코드를 포함하는 메모리부를 포함하는, 전자 장치.
제17항에 있어서, 상기 ISO 기반 미디어 파일은 상기 ISO 기반 미디어 파일 내에 포함된 미디어 객체들을 기재하는 SVG 미디어 트랙을 포함하는, 전자 장치.
제17항에 있어서, 상기 ISO 기반 미디어 파일은 힌트 트랙 샘플을 포함하고, 상기 힌트 트랙 샘플은 각각의 패킷 내에서 송신될 데이터를 포함하거나 가리키는, 전자 장치.
제17항에 있어서, 상기 ISO 기반 미디어 파일은 음영 동기화 테이블을 포함하고, 상기 음영 동기화 테이블은 랜덤 접근을 지원하기 위하여 이용되는 샘플들을 포함하는, 전자 장치.