Lovely Sky

Atoms

QuickTime file 에서의 기본적인 데이터 단위는 atom 이다. 각각의 atom 은 다른 data 들에 앞서서 size 와 type field 들을 포함하고 있다. size field 는 size 와 type field 들을 포함하여 atom 에 있는 총 바이트수를 표시하고, type field 는 atom 에 저장된 데이타의 타입과 데이터의 포맷(data format 은 암시에 의하여(by impilcation))을 명시한다. 어느 경우에는 size 와 type field 들이 version field 와 flags field 에 따라 나오기도 한다. 이러한 version, flags field 들을 포함한 atom 을 두고 종종 full atom 이라 부르기도 한다.

atom type 들은 전형적으로 ASCII code 4 글자로 번역될 수 있는 32-bit unsigned int 로 명시된다. (Apple, inc. 는 전부 소문자들로 이루어진 모든 4 글자 코드에 대해 법적 권리를 가지고 있다.) 만약 다른 언급이 없으면(Unless otherwise stated), QuickTime movie 의 모든 데이터들은 네트워크 바이트 ordering 으로 일반적으로 알려져있는 big-endian (MSB 가 가장 먼저 저장되고, 가장 먼저 전송되는) 으로 저장된다.

atom 은 본질적으로 계층구조를 갖고있다. 이 말은 즉슨, 하나의 atom 이 또 다른 것들을 포함할 가능성이 있는 다른 atom 들을 포함할 수 있다. 이런 계층구조는 종종 부모, 자식, 형제(siblings), 손주(grandchildren), 등등으로 표현되기도 한다. 다른 atom 을 포함하는 atom 을 container atom 이라고 부르며, parent atom 은 계층구조에서 주어진 atom 에서 정확히 한 단계 위의 container atom 을 가리킨다.

다른 atom 들을 포함하지 않는 atom 은 leaf atom 이라고 부른다. 이 leaf atom 은 전형적으로 하나 또는 더 많은 필드나 테이블(tables)로서의 data 를 포함한다. 하지만 어떤 몇몇의 leaf atom 들은 flags 나 placeholders 처럼 행동하고, size 와 type fields 외에는 어떠한 정보도 갖지 않는다.

given atom 에 저장된 데이타의 포맷은 항상 혼자서 atom 의 type field 에 의해 결정될 수 없다.; parent atom 의 타입 또한 중요할 수도 있다. 다른 말로, given atom 타입은 parent atom 에 의존하는 다른 종류의 정보들을 포함할 수 있다. 예를 들어 movie atom 안에 있는 profile atom 은 the movie 에 대한 정보들을 포함한다. 반면에 profile atom 이 track atom 안에 있다면, profile atom 은 트랙에 대한 정보들을 포함하게된다.

- Atom Layout

오른쪽 그림 1-1 (Figure 1-1 A sample atom) 에서 보여지는 leaf atom 은 간단히 오프셋에 의해 접근가능한 a series of data fields 를 포함한다.

Container Atom들 안에 있는 Atom들은 이 문서 내부에서 따로 특별하게 어떤 순서를 언급하지 않는한, 일반적으로 어떤 특정한 순서(order)을 갖지 않는다. 하나의 예를 들자면, 무조건 handle 하는 data 의 앞(before)부분에 위치해야하는 handler description atom 이 있다.

예를 들어, media handler description atom 은 media information atom 앞에(before) 위치해야하고, data handler description atom 은 data information atom 앞에(before) 위치해야한다.

- Atom Structure

Atom data 다음에 따라오는 Atom 들은 header 들로 구성되어 있다. header 는 atom의 크기를 bytes 단위로 갖는 atom의 크기필드, 그것의 타입을 갖는 atom의 타입필드를 갖는다. 또한 large atom을 64-bit integer 값으로 갖는 extended size field 도 포함하고 있다. 만약에 이 extended 필드가 존재한다면, 크기필드의 값은 1로 설정되어있을것이다. atom의 실질적인 크기는 8 바이트(minimum size of the type and size fields)보다 작은 값을 가지지 않는다. (최소 8 바이트이다.) 

몇 atom 들은 또한 version, flag fields 도 포함한다. 이들은 종종 full atoms 라고 불린다. flag 와 version field들은 이 문서 내부의 atom header의 부분으로 처리되지는 않는다. 그들은 full atoms 을 포함하는 각 atom type 에 특화된 (specific to each atom type) data fields 로 간주된다. (? : they are treated as data fields specific to each atom type that contains them.) 이러한 필드들은 따로 특별한 상황이 아니면, 항상 0 값으로 세팅되어있어야한다.

atom header 는 다음 필드들로 구성되어 있다.

Atom size

atom 의 컨텐츠(다른 포함된 atom들을 포함해서)들과, atom 의 헤더를 포함한 atom 의 크기를 가리키는 32-bis integer 이다. 일반저긍로 size field 는 32-bit unsigned integer 로 표현된 실제의 bytes 단위의 atom 크기를 포함한다. 하지만 size field 는 atom 크기를 정하는데 사용되는 다른 대안의 방법을 지칭하는 특별한 값을 가질수도 있다. (이 특별한 값은 일반적으로 media data atom ('mdat') 에만 사용된다.)

두 특별한 값은 사이즈 필드에서 유효한 값들이다 :

0 : 오직 top-level atom 만을 위해 허락된 값으로, 파일안에 마지막 atom 을 가리키고, 파일의 끝에서 확장된 것을 가르켜준다. 

(? : , designates the last atom in the file and indicates that the atom extends to the end of file.)

1 : 실제 크기는 extended size field 에 존재한다는 뜻이다. extended size field 는 type field 를 따르는 선택적인(optional) 64-bit filed 이다.

This accommodates media data atoms that contain more than 2^32 bytes.

이것은 2^32 바이트보다 더 많은것을 포함하는 media data atoms 를 수용한다. 

아래 Figure 1-2 는 어떻게 atom 의 크기를 계산하는지에 대해 나와있다.

Figure 1-2 Caculating atom sizes 

Type

atom 의 타입을 가리키는 32-bis integer 이다. 이건 종종 mnemonic 값을 가진 4 char 필드로 유용하게 처리될 수 있다. 예를 들어 movie atom 을 위한 'moov' (0x6D6F6F76), 또는 track atom 을 위한 'trak' (0x7472616B) 이 있다. non-ASCII 값들도 이용되기도 한다. (예를 들어 0x00000001) 

atom 의 타입을 아는것은 당신이 그 data 를 해석하게 해준다. atom data 는 fields, tables, 다른 atom 들의 독자적인 모음으로서 나열될 수 있다. data structure 는 atom type 에 특화되어 있다. 주어진 type 에 대한 atom 은 각각 정의된 data structure 를 갖고 있다.

만약에 당신의 애플리케이션이 알려지지않은 type 의 atom 을 마주하였다고 하였을때, app 은 그 해당 atom data 를 해석하려는 시도하면 안된다. atom 과 그 해당 atom 이 포함하고 있는 content 들을 스킵하기 위하여 atom 의 size field 를 이용하여라. 이 행위는 QuickTime file format 를 확장하는것에 대한 a degree of forward compatibility 를 허락해준다. 

(* forward compatibility ? : (software) Capability of interoperating with anticipated future systems.)

Warning : 주어진 atom 의 타입에 대한 내부 구조는 새로운 버전이 출시될때 바뀔 수 있습니다. version 필드가 존재한다면, 항상 version 필드를 확인하십시오. 절대 Size or Extended Size 필드에서 정의된 atom 말고 그 외부에 떨어진 data 를 해석하려 시도하지 마십시오.

Extended Size

만약 atom 의 size 필드가 1 로 세팅되있다면 type 필드는 64-bit unsigned integer 형으로 atom 의 실제 크기를 갖는 64-bit extended size 필드를 자신의 뒤로 갖게 된다. (the type field is followed) 이는 media data atom 의 크기가 2^32 bytes 를 넘었을때 사용된다.

size field 가 atom 의 실제 크기를 가질때, extended size 필드는 존재하지 않는다. 이 뜻은 data 를 더함으로서 QuickTime atom 이 수정될 때, 그리고 그것의 크기가 2^32 바이트 제한 내에 있다면, 새로운 atom size 를 기록하기 위한 extended size 필드는 없다는 뜻이다. 결과적으로, 2^32 바이트를 넘어서는 atom 를 확장하는 것이 새로운 atom 에 그 해당 atom 의 컨텐츠를 복사하지 않고서는 항상 가능하진 않다.

Introduction to QuickTime File Format Specification

QTFF 는 devices, applications, operationg systems 간에 디지털미디어의 교환을 쉽게해주기 위한 이상적인 fomat. 이유는, QTFF 가 거의 대부분의 미디어 구조를 describe하는데에 사용될 수 있기 때문이다. The file format 은 (객체들의 유연한 모음으로 구성되어서 쉽게 분석되고, 쉽게 확장될 수 있는) object-oriented의 성질을 갖고있다. 모르는 객체는 간단하게 무시되거나 넘어갈 수 있다(skip). 이렇게 함으로써 새로운 객체 타입이 선언되었을때(introduced) 많은 수의 접근호환성(forward compatibility)을 지원해준다. 

QuickTime 그 자체로 많은 high-level function들을 제공해준다. 당신은 high-level function를 이용하여 실제 파일 포맷에 대한 이해없이, QuickTime files을 만들거나 조작하는 작업들을 수행할 수 있다. 이러한 함수들은 개발자들에게 operation 의 low-level 구체사항에 대한 요구를 필요없도록 도와준다. 그 이야기는 여기에 표현된(presented) 정보들 없이는 모든 종류의 QuickTime files 이 만들어질수없다는 것이다.

Warning : Do NOT use this specification to interpret a file that conforms to a different specification, however similar

QuickTime 은 audio/visual media 에서의 새로운 사용들과 요구들에 의해 계속해서 진화해가는 a rich technology 이다. 이때문에, 최근 QuickTime technology의 요소들은 시간이 지남에 따라 become deprecated 될지도 모른다. 이런 요소들은 포함하는 현존하는 QuickTime file 들에 대한 법적 요소(components)들의 충분한 정보들을 보존하기 위하여 deprecated 요소들은 QuickTime File Format Specification 의 수정사항 부분의 가장 위의 section 에 note 에 표기해놓을 것이다.

Overview of QTFF

QuickTime movies 는 정보를 저장하기 위한 2 가지 기본적인 구조를 이용하여 disk 에 저장한다.

- atoms (또한 simple atoms or classic atoms 로도 알려져있다.)

- QT atoms

어떻게 QuickTime movies 가 저장되는지를 알기위하여, 당신은 앞으로 서술할 기본적인 atom 구조에 대하여 이해해야한다.

당신이 QuickTime File Format 에서 만나는 대부분의 atom 들은 간단하거나 classic atoms 이다.하지만 simple atoms 나 QT atoms 나 둘다 당신이 마음대로 복잡한 계층의 데이터구조를 설계할 수 있게끔 도와주고, 둘다 당신의 어플리케이션이 그들이 이해하지못한 data 를 무시할수 있게 허락한다.  

Media Description

QuickTime file 은 그 미디어에 대한 서술들을 미디어 데이터(media data)와 따로 저장한다. 

- Movie resource, movie atom, the movie (description)

이 서술을 movie resource, movie atom 또는 간단하게 the movie 라고 부르고, 이 서술은 트랙의 수, 비디오 압축 포맷, 시간 정보와 같은 정보들은 포함한다. movie resource 는 또한 어디에 모든 미디어 데이터가 저장되어 있는지를 서술하는 index 도 포함하고 있다.

- media data (actual data)

media data 는 비디오 프레임과 오디오 샘플들과 같은 the movie 에서 사용되는 실질적인 샘플 데이타이다. media data 는 1) QuickTime movie 와 같은 파일로, 2) 분리된 파일로, 3) 복수의 파일로, 4) 데이터베이스 혹은 실시간 스트림처럼 대체적인 소스로, 혹은 5) 이런것들중 몇몇의 조합으로 저장될 것이다. 

Atoms

QuickTime file 에서의 기본적인 데이터 단위는 atom 이다. 각각의 atom 은 다른 data 들에 앞서서 size 와 type field 들을 포함하고 있다. size field 는 size 와 type field 들을 포함하여 atom 에 있는 총 바이트수를 표시하고, type field 는 atom 에 저장된 데이타의 타입과 데이터의 포맷(data format 은 암시에 의하여(by impilcation))을 명시한다. 어느 경우에는 size 와 type field 들이 version field 와 flags field 에 따라 나오기도 한다. 이러한 version, flags field 들을 포함한 atom 을 두고 종종 full atom 이라 부르기도 한다.

atom type 들은 전형적으로 ASCII code 4 글자로 번역될 수 있는 32-bit unsigned int 로 명시된다. (Apple, inc. 는 전부 소문자들로 이루어진 모든 4 글자 코드에 대해 법적 권리를 가지고 있다.) 만약 다른 언급이 없으면(Unless otherwise stated), QuickTime movie 의 모든 데이터들은 네트워크 바이트 ordering 으로 일반적으로 알려져있는 big-endian (MSB 가 가장 먼저 저장되고, 가장 먼저 전송되는) 으로 저장된다.

atom 은 본질적으로 계층구조를 갖고있다. 이 말은 즉슨, 하나의 atom 이 또 다른 것들을 포함할 가능성이 있는 다른 atom 들을 포함할 수 있다. 이런 계층구조는 종종 부모, 자식, 형제(siblings), 손주(grandchildren), 등등으로 표현되기도 한다. 다른 atom 을 포함하는 atom 을 container atom 이라고 부르며, parent atom 은 계층구조에서 주어진 atom 에서 정확히 한 단계 위의 container atom 을 가리킨다.

다른 atom 들을 포함하지 않는 atom 은 leaf atom 이라고 부른다. 이 leaf atom 은 전형적으로 하나 또는 더 많은 필드나 테이블(tables)로서의 data 를 포함한다. 하지만 어떤 몇몇의 leaf atom 들은 flags 나 placeholders 처럼 행동하고, size 와 type fields 외에는 어떠한 정보도 갖지 않는다.

given atom 에 저장된 데이타의 포맷은 항상 혼자서 atom 의 type field 에 의해 결정될 수 없다.; parent atom 의 타입 또한 중요할 수도 있다. 다른 말로, given atom 타입은 parent atom 에 의존하는 다른 종류의 정보들을 포함할 수 있다. 예를 들어 movie atom 안에 있는 profile atom 은 the movie 에 대한 정보들을 포함한다. 반면에 profile atom 이 track atom 안에 있다면, profile atom 은 트랙에 대한 정보들을 포함하게된다.