xenia-project/snappy
1
0
Fork 0
mirror of https://github.com/xenia-project/snappy.git synced 2024-11-26 20:50:36 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add support for padding in the Snappy framed format.

Browse Source 
This is specifically motivated by DICOM's demands that embedded data
must be of an even number of bytes, but could in principle be used for
any sort of padding/alignment needed.

R=sanjay


git-svn-id: https://snappy.googlecode.com/svn/trunk@82 03e5f5b5-db94-4691-08a0-1a8bf15f6143
This commit is contained in:
snappy.mirrorbot@gmail.com 2013-10-25 13:31:27 +00:00
parent eeead8dc38
commit f82bff66af
1 changed files with 15 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
framing_format.txt
View File

@ -1,5 +1,5 @@
Snappy framing format description
Last revised: 2013-01-05
Last revised: 2013-10-25
This format decribes a framing format for Snappy, allowing compressing to
files or streams that can then more easily be decompressed without having
@ -106,7 +106,18 @@ no more than 65536 data bytes, so the maximum legal chunk length with the
checksum is 65540.
4.4. Reserved unskippable chunks (chunk types 0x02-0x7f)
4.4. Padding (chunk type 0xfe)
Padding chunks allow a compressor to increase the size of the data stream
so that it complies with external demands, e.g. that the total number of
bytes is a multiple of some value.
All bytes of the padding chunk, except the chunk byte itself and the length,
should be zero, but decompressors must not try to interpret or verify the
padding data in any way.
4.5. Reserved unskippable chunks (chunk types 0x02-0x7f)
These are reserved for future expansion. A decoder that sees such a chunk
should immediately return an error, as it must assume it cannot decode the
@ -115,10 +126,10 @@ stream correctly.
Future versions of this specification may define meanings for these chunks.
4.5. Reserved skippable chunks (chunk types 0x80-0xfe)
4.6. Reserved skippable chunks (chunk types 0x80-0xfd)
These are also reserved for future expansion, but unlike the chunks
described in 4.4, a decoder seeing these must skip them and continue
described in 4.5, a decoder seeing these must skip them and continue
decoding.
Future versions of this specification may define meanings for these chunks.