[QTFF] Atoms
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 의 컨텐츠를 복사하지 않고서는 항상 가능하진 않다.
이런 불편을 방지하기 위하여, media data atoms 는 전형적으로 64-bit placeholder atom (즉각적으로 movie file 안에서 media data 를 앞서는 atom) 을 생성한다. placeholder atom 은 kWideAtomPlaceholderType('wide') 라는 타입을 갖고 있다.
'free' 혹은 'skip' atom 과 유사하게 'wide' atom 은 예약된 공간이다, 하지만 in this case 이 공간은 특별한 목적을 위해 예약된다. 만약 'wide' atom 이 즉각적으로 second atom 을 앞선다면, 단순하게 atom header 를 8 바이트 빠르게 시작하고('wide' atom 을 overwriting), size 필드 값을 1로 세팅하고, extended size 필드에 더함으로서 second atom 은 32-bit 크기에서 64-bit 크기로 확장될 수 있다. 이 방법에서 샘플데이타를 위한 오프셋은 재계산될 필요가 없다.
(? : Much like a 'free' or 'skip' atom, the 'wide' atom is reserved space, but in this case the space is reserved for a specific purpose. If a 'wide' atom immediately precedes a second atom, the second atom can be extended from a 32-bit size to a 64-bit size simply by starting the atom header 8 bytes earlier (overwriting the 'wide' atom), setting the size field to 1, and adding an extended size field. This way the offsets for sample data do not need to be recalculated.)
'wide' atom 의 크기는 정확히 8 바이트이다. 그리고 자체적으로(solely) size, type 필드를 포함하고 있고 그 이외의 data 는 포함하고있지않다.
Note : 흔한 오류는 'wide' atom 은 extended size 를 포함하고 있다고 생각한다는 점이다. 'wide' atom 은 필요하다면 extended size 필드를 포함하는 atom header 에 의해 overwritten 될 수 있는 단지 placeholder 일 뿐이다.