-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
SMJPEG.txt
67 lines (54 loc) · 2.08 KB
/
SMJPEG.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
This file documents the simple animation format used by SMJPEG
This is for static animation files, not for audio/video streaming.
All 32-bit and 16-bit values are stored in big-endian format.
8 bytes magic - "^@\nSMJPEG"
Uint32 version = 0
Uint32 length of clip in milliseconds
One or more optional comment headers:
4 bytes magic - "_TXT"
Uint32 text length
arbitrary text
Optional audio header:
4 bytes magic - "_SND"
Uint32 audio header length
Uint16 audio rate
Uint8 bits-per-sample (8 = unsigned 8-bit audio, 16 = signed 16-bit LE audio)
Uint8 channels (1 = mono, 2 = stereo)
4 bytes audio encoding ("NONE" = none, "APCM" = ADPCM compressed)
Optional video header:
4 bytes magic - "_VID"
Uint32 video header length
Uint32 number of frames
Uint16 width
Uint16 height
4 bytes video encoding ("JFIF" = jpeg)
End of header marker:
4 bytes magic - "HEND"
Interleaved chunks of audio/video data:
4 bytes magic - "sndD" for sound data, "vidD" for video data
Uint32 millisecond timestamp
Uint32 chunk length
// Comment -
A single video chunk corresponds to a single frame of video.
A single audio chunk corresponds to audio data not more than 4K uncompressed.
(decoders may silently truncate chunks that contain more than 4K of
audio data, though a robust implementation would accept them.)
// Comment -
The audio/video chunks should be more-or-less ordered according to timestamp
so seeking by time works correctly. Audio chunks should be ordered before
video chunks, and all audio chunks for a given frame of video should be
grouped together. This results in good playback when scanning linearly.
i.e. AAAV-AAV-AAAV-... (A = audio chunk, V = video chunk)
// Comment -
The audio chunks should be encoded one frame ahead of the video chunks
(i.e. current frame + next frame) so that if the decoder gets behind,
the audio is queued up and doesn't underflow. The decoder will quickly
skip the next video frame and catch up.
// Comment -
The ADPCM audio encoded chunk consists of:
Uint16 valprev
Uint8 index
Uint8 unused
... compressed audio data
End of data marker:
4 bytes magic - "DONE"