diff options
Diffstat (limited to 'app/lzo/doc')
| -rw-r--r-- | app/lzo/doc/LZO.FAQ | 213 | ||||
| -rw-r--r-- | app/lzo/doc/LZO.TXT | 291 | ||||
| -rw-r--r-- | app/lzo/doc/LZOAPI.TXT | 261 | ||||
| -rw-r--r-- | app/lzo/doc/LZOTEST.TXT | 75 |
4 files changed, 0 insertions, 840 deletions
diff --git a/app/lzo/doc/LZO.FAQ b/app/lzo/doc/LZO.FAQ deleted file mode 100644 index cb1f38aa..00000000 --- a/app/lzo/doc/LZO.FAQ +++ /dev/null @@ -1,213 +0,0 @@ -============================================================================ -LZO Frequently Asked Questions -============================================================================ - - -I hate reading docs - just tell me how to add compression to my program -======================================================================= - -This is for the impatient: take a look at examples/simple.c and -examples/lzopack.c and see how easy this is. - -But you will come back to read the documentation later, won't you ? - - -Can you explain the naming conventions of the algorithms ? -========================================================== - -Let's take a look at LZO1X: - - The algorithm name is LZO1X. - The algorithm category is LZO1. - Various compression levels are implemented. - - LZO1X-999 - !---------- algorithm category - !--------- algorithm type - !!!----- compression level (1-9, 99, 999) - - LZO1X-1(11) - !---------- algorithm category - !--------- algorithm type - !------- compression level (1-9, 99, 999) - !!---- memory level (memory requirements for compression) - -All compression/memory levels generate the same compressed data format, -so e.g. the LZO1X decompressor handles all LZO1X-* compression levels -(for more information about the decompressors see below). - -Category LZO1 algorithms: compressed data format is strictly byte aligned -Category LZO2 algorithms: uses bit-shifting, slower decompression - - -Why are there so many algorithms ? -================================== - -Because of historical reasons - I want to support unlimited -backward compatibility. - -Don't get misled by the size of the library - using one algorithm -increases the size of your application by only a few KiB. - -If you just want to add a little bit of data compression to your -application you may be looking for miniLZO. -See minilzo/README.LZO for more information. - - -Which algorithm should I use ? -============================== - -LZO1X seems to be best choice in many cases, so: -- when going for speed use LZO1X-1 -- when generating pre-compressed data use LZO1X-999 -- if you have little memory available for compression use LZO1X-1(11) - or LZO1X-1(12) - -Of course, your mileage may vary, and you are encouraged to run your -own experiments. Try LZO1Y and LZO1F next. - - -What's the difference between the decompressors per algorithm ? -=============================================================== - -Once again let's use LZO1X for explanation: - -- lzo1x_decompress - The 'standard' decompressor. Pretty fast - use this whenever possible. - - This decompressor expects valid compressed data. - If the compressed data gets corrupted somehow (e.g. transmission - via an erroneous channel, disk errors, ...) it will probably crash - your application because absolutely no additional checks are done. - -- lzo1x_decompress_safe - The 'safe' decompressor. Somewhat slower. - - This decompressor will catch all compressed data violations and - return an error code in this case - it will never crash. - -- lzo1x_decompress_asm - Same as lzo1x_decompress - written in assembler. - -- lzo1x_decompress_asm_safe - Same as lzo1x_decompress_safe - written in assembler. - -- lzo1x_decompress_asm_fast - Similar to lzo1x_decompress_asm - but even faster. - - For reasons of speed this decompressor can write up to 3 bytes - past the end of the decompressed (output) block. - [ technical note: because data is transferred in 32-bit units ] - - Use this when you are decompressing from one memory block to - another memory block - just provide output space for 3 extra bytes. - You shouldn't use it if e.g. you are directly decompressing to video - memory (because the extra bytes will be show up on the screen). - -- lzo1x_decompress_asm_fast_safe - This is the safe version of lzo1x_decompress_asm_fast. - - -Notes: ------- -- When using a safe decompressor you must pass the number of - bytes available in 'dst' via the parameter 'dst_len'. - -- If you want to be sure that your data is not corrupted you must - use a checksum - just using the safe decompressor is not enough, - because many data errors will not result in a compressed data violation. - -- Assembler versions are only available for the i386 family yet. - Please see also asm/i386/00README.TXT - -- You should test if the assembler versions are actually faster - than the C version on your machine - some compilers can do a very - good optimization job and they also can optimize the code - for a specific processor. - - -What is this optimization thing ? -================================= - -The compressors use a heuristic approach - they sometimes code -information that doesn't improve compression ratio. - -Optimization removes this superfluos information in order to -increase decompression speed. - -Optimization works similar to decompression except that the -compressed data is modified as well. The length of the compressed -data block will not change - only the compressed data-bytes will -get rearranged a little bit. - -Don't expect too much, though - my tests have shown that the -optimization step improves decompression speed by about 1-3%. - - -I need even more decompression speed... -======================================= - -Many RISC processors (like MIPS) can transfer 32-bit words much -faster than bytes - this can significantly speed up decompression. -So after verifying that everything works fine you can try if activating -the LZO_ALIGNED_OK_4 macro improves LZO1X and LZO1Y decompression -performance. Change the file config.h accordingly and recompile everything. - -On an i386 architecture you should evaluate the assembler versions. - - -How can I reduce memory requirements when (de)compressing ? -=========================================================== - -If you cleverly arrange your data, you can do an overlapping (in-place) -decompression which means that you can decompress to the *same* -block where the compressed data resides. This effectively removes -the space requirements for holding the compressed data block. - -This technique is essential e.g. for usage in an executable packer. - -You can also partly overlay the buffers when doing compression. - -See examples/overlap.c for a working example. - - -Can you give a cookbook for using pre-compressed data ? -======================================================= - -Let's assume you use LZO1X-999. - -1) pre-compression step - - call lzo_init() - - call lzo1x_999_compress() - - call lzo1x_optimize() - - compute an adler32 checksum of the *compressed* data - - store the compressed data and the checksum in a file - - if you are paranoid you should verify decompression now - -2) decompression step within your application - - call lzo_init() - - load your compressed data and the checksum - - optionally verify the checksum of the compressed data - (so that you can use the standard decompressor) - - decompress - -See examples/precomp.c and examples/precomp2.c for a working example. - - -How much can my data expand during compression ? -================================================ - -LZO will expand incompressible data by a little amount. -I still haven't computed the exact values, but I suggest using -these formulas for a worst-case expansion calculation: - - Algorithm LZO1, LZO1A, LZO1B, LZO1C, LZO1F, LZO1X, LZO1Y, LZO1Z: - ---------------------------------------------------------------- - output_block_size = input_block_size + (input_block_size / 16) + 64 + 3 - - [This is about 106% for a large block size.] - - Algorithm LZO2A: - ---------------- - output_block_size = input_block_size + (input_block_size / 8) + 128 + 3 - diff --git a/app/lzo/doc/LZO.TXT b/app/lzo/doc/LZO.TXT deleted file mode 100644 index 2d3b5aa7..00000000 --- a/app/lzo/doc/LZO.TXT +++ /dev/null @@ -1,291 +0,0 @@ - - ============================================================================ - LZO -- a real-time data compression library - ============================================================================ - - Author : Markus Franz Xaver Johannes Oberhumer - <markus@oberhumer.com> - http://www.oberhumer.com/opensource/lzo/ - Version : 2.07 - Date : 25 Jun 2014 - - - Abstract - -------- - LZO is a portable lossless data compression library written in ANSI C. - It offers pretty fast compression and very fast decompression. - Decompression requires no memory. - - In addition there are slower compression levels achieving a quite - competitive compression ratio while still decompressing at - this very high speed. - - The LZO algorithms and implementations are copyrighted OpenSource - distributed under the GNU General Public License. - - - Introduction - ------------ - LZO is a data compression library which is suitable for data - de-/compression in real-time. This means it favours speed - over compression ratio. - - The acronym LZO is standing for Lempel-Ziv-Oberhumer. - - LZO is written in ANSI C. Both the source code and the compressed - data format are designed to be portable across platforms. - - LZO implements a number of algorithms with the following features: - - - Decompression is simple and *very* fast. - - Requires no memory for decompression. - - Compression is pretty fast. - - Requires 64 KiB of memory for compression. - - Allows you to dial up extra compression at a speed cost in the - compressor. The speed of the decompressor is not reduced. - - Includes compression levels for generating pre-compressed - data which achieve a quite competitive compression ratio. - - There is also a compression level which needs only 8 KiB for compression. - - Algorithm is thread safe. - - Algorithm is lossless. - - LZO supports overlapping compression and in-place decompression. - - - Design criteria - --------------- - LZO was designed with speed in mind. Decompressor speed has been - favoured over compressor speed. Real-time decompression should be - possible for virtually any application. The implementation of the - LZO1X decompressor in optimized i386 assembler code runs about at - the third of the speed of a memcpy() - and even faster for many files. - - In fact I first wrote the decompressor of each algorithm thereby - defining the compressed data format, verified it with manually - created test data and at last added the compressor. - - - Performance - ----------- - To keep you interested, here is an overview of the average results - when compressing the Calgary Corpus test suite with a blocksize - of 256 KiB, originally done on an ancient Intel Pentium 133. - - The naming convention of the various algorithms goes LZOxx-N, where N is - the compression level. Range 1-9 indicates the fast standard levels using - 64 KiB memory for compression. Level 99 offers better compression at the - cost of more memory (256 KiB), and is still reasonably fast. - Level 999 achieves nearly optimal compression - but it is slow - and uses much memory, and is mainly intended for generating - pre-compressed data. - - The C version of LZO1X-1 is about 4-5 times faster than the fastest - zlib compression level, and it also outperforms other algorithms - like LZRW1-A and LZV in both compression ratio and compression speed - and decompression speed. - - +------------------------------------------------------------------------+ - | Algorithm Length CxB ComLen %Remn Bits Com K/s Dec K/s | - | --------- ------ --- ------ ----- ---- ------- ------- | - | | - | memcpy() 224401 1 224401 100.0 8.00 60956.83 59124.58 | - | | - | LZO1-1 224401 1 117362 53.1 4.25 4665.24 13341.98 | - | LZO1-99 224401 1 101560 46.7 3.73 1373.29 13823.40 | - | | - | LZO1A-1 224401 1 115174 51.7 4.14 4937.83 14410.35 | - | LZO1A-99 224401 1 99958 45.5 3.64 1362.72 14734.17 | - | | - | LZO1B-1 224401 1 109590 49.6 3.97 4565.53 15438.34 | - | LZO1B-2 224401 1 106235 48.4 3.88 4297.33 15492.79 | - | LZO1B-3 224401 1 104395 47.8 3.83 4018.21 15373.52 | - | LZO1B-4 224401 1 104828 47.4 3.79 3024.48 15100.11 | - | LZO1B-5 224401 1 102724 46.7 3.73 2827.82 15427.62 | - | LZO1B-6 224401 1 101210 46.0 3.68 2615.96 15325.68 | - | LZO1B-7 224401 1 101388 46.0 3.68 2430.89 15361.47 | - | LZO1B-8 224401 1 99453 45.2 3.62 2183.87 15402.77 | - | LZO1B-9 224401 1 99118 45.0 3.60 1677.06 15069.60 | - | LZO1B-99 224401 1 95399 43.6 3.48 1286.87 15656.11 | - | LZO1B-999 224401 1 83934 39.1 3.13 232.40 16445.05 | - | | - | LZO1C-1 224401 1 111735 50.4 4.03 4883.08 15570.91 | - | LZO1C-2 224401 1 108652 49.3 3.94 4424.24 15733.14 | - | LZO1C-3 224401 1 106810 48.7 3.89 4127.65 15645.69 | - | LZO1C-4 224401 1 105717 47.7 3.82 3007.92 15346.44 | - | LZO1C-5 224401 1 103605 47.0 3.76 2829.15 15153.88 | - | LZO1C-6 224401 1 102585 46.5 3.72 2631.37 15257.58 | - | LZO1C-7 224401 1 101937 46.2 3.70 2378.57 15492.49 | - | LZO1C-8 224401 1 100779 45.6 3.65 2171.93 15386.07 | - | LZO1C-9 224401 1 100255 45.4 3.63 1691.44 15194.68 | - | LZO1C-99 224401 1 97252 44.1 3.53 1462.88 15341.37 | - | LZO1C-999 224401 1 87740 40.2 3.21 306.44 16411.94 | - | | - | LZO1F-1 224401 1 113412 50.8 4.07 4755.97 16074.12 | - | LZO1F-999 224401 1 89599 40.3 3.23 280.68 16553.90 | - | | - | LZO1X-1(11) 224401 1 118810 52.6 4.21 4544.42 15879.04 | - | LZO1X-1(12) 224401 1 113675 50.6 4.05 4411.15 15721.59 | - | LZO1X-1 224401 1 109323 49.4 3.95 4991.76 15584.89 | - | LZO1X-1(15) 224401 1 108500 49.1 3.93 5077.50 15744.56 | - | LZO1X-999 224401 1 82854 38.0 3.04 135.77 16548.48 | - | | - | LZO1Y-1 224401 1 110820 49.8 3.98 4952.52 15638.82 | - | LZO1Y-999 224401 1 83614 38.2 3.05 135.07 16385.40 | - | | - | LZO1Z-999 224401 1 83034 38.0 3.04 133.31 10553.74 | - | | - | LZO2A-999 224401 1 87880 40.0 3.20 301.21 8115.75 | - +------------------------------------------------------------------------+ - - Notes: - - CxB is the number of blocks - - K/s is the speed measured in 1000 uncompressed bytes per second - - the assembler decompressors are even faster - - - Short documentation - ------------------- - LZO is a block compression algorithm - it compresses and decompresses - a block of data. Block size must be the same for compression - and decompression. - - LZO compresses a block of data into matches (a sliding dictionary) - and runs of non-matching literals. LZO takes care about long matches - and long literal runs so that it produces good results on highly - redundant data and deals acceptably with non-compressible data. - - When dealing with incompressible data, LZO expands the input - block by a maximum of 64 bytes per 1024 bytes input. - - I have verified LZO using such tools as valgrind and other memory checkers. - And in addition to compressing gigabytes of files when tuning some parameters - I have also consulted various 'lint' programs to spot potential portability - problems. LZO is free of any known bugs. - - - The algorithms - -------------- - There are too many algorithms implemented. But I want to support - unlimited backward compatibility, so I will not reduce the LZO - distribution in the future. - - As the many object files are mostly independent of each other, the - size overhead for an executable statically linked with the LZO library - is usually pretty low (just a few KiB) because the linker will only add - the modules that you are actually using. - - I first published LZO1 and LZO1A in the Internet newsgroups - comp.compression and comp.compression.research in March 1996. - They are mainly included for compatibility reasons. The LZO2A - decompressor is too slow, and there is no fast compressor anyway. - - My experiments have shown that LZO1B is good with a large blocksize - or with very redundant data, LZO1F is good with a small blocksize or - with binary data and that LZO1X is often the best choice of all. - LZO1Y and LZO1Z are almost identical to LZO1X - they can achieve a - better compression ratio on some files. - Beware, your mileage may vary. - - - Usage of the library - -------------------- - Despite of its size, the basic usage of LZO is really very simple. - - Let's assume you want to compress some data with LZO1X-1: - A) compression - * include <lzo/lzo1x.h> - call lzo_init() - compress your data with lzo1x_1_compress() - * link your application with the LZO library - B) decompression - * include <lzo/lzo1x.h> - call lzo_init() - decompress your data with lzo1x_decompress() - * link your application with the LZO library - - The program examples/simple.c shows a fully working example. - See also LZO.FAQ for more information. - - - Building LZO - ------------ - As LZO uses Autoconf+Automake+Libtool the building process under - UNIX systems should be very unproblematic. Shared libraries are - supported on many architectures as well. - For detailed instructions see the file INSTALL. - - Please note that due to the design of the ELF executable format - the performance of a shared library on i386 systems (e.g. Linux) - is a little bit slower, so you may want to link your applications - with the static version (liblzo2.a) anyway. - - For building under DOS, Win16, Win32, OS/2 and other systems - take a look at the file B/00readme.txt. - - In case of troubles (like decompression data errors) try recompiling - everything without optimizations - LZO may break the optimizer - of your compiler. See the file BUGS. - - LZO is written in ANSI C. In particular this means: - - your compiler must understand prototypes - - your compiler must understand prototypes in function pointers - - your compiler must correctly promote integrals ("value-preserving") - - your preprocessor must implement #elif, #error and stringizing - - you must have a conforming and correct <limits.h> header - - you must have <stddef.h>, <string.h> and other ANSI C headers - - you should have size_t and ptrdiff_t - - - Portability - ----------- - I have built and tested LZO successfully on a variety of platforms - including DOS (16 + 32 bit), Windows 3.x (16-bit), Win32, Win64, - Linux, *BSD, HP-UX and many more. - - LZO is also reported to work under AIX, ConvexOS, IRIX, MacOS, PalmOS (Pilot), - PSX (Sony Playstation), Solaris, SunOS, TOS (Atari ST) and VxWorks. - Furthermore it is said that its performance on a Cray is superior - to all other machines... - - And I think it would be much fun to translate the decompressors - to Z-80 or 6502 assembly. - - - The future - ---------- - Here is what I'm planning for the next months. No promises, though... - - - interfaces to .NET and Mono - - interfaces to Perl, Java, Python, Delphi, Visual Basic, ... - - improve documentation and API reference - - - Some comments about the source code - ----------------------------------- - Be warned: the main source code in the 'src' directory is a - real pain to understand as I've experimented with hundreds of slightly - different versions. It contains many #if and some gotos, and - is *completely optimized for speed* and not for readability. - Code sharing of the different algorithms is implemented by stressing - the preprocessor - this can be really confusing. Lots of marcos and - assertions don't make things better. - - Nevertheless LZO compiles very quietly on a variety of - compilers with the highest warning levels turned on, even - in C++ mode. - - - Copyright - --------- - LZO is Copyright (C) 1996-2014 Markus Franz Xaver Oberhumer - All Rights Reserved. - - LZO is distributed under the terms of the GNU General Public License (GPL). - See the file COPYING. - - Special licenses for commercial and other applications which - are not willing to accept the GNU General Public License - are available by contacting the author. - - - diff --git a/app/lzo/doc/LZOAPI.TXT b/app/lzo/doc/LZOAPI.TXT deleted file mode 100644 index 547b0d70..00000000 --- a/app/lzo/doc/LZOAPI.TXT +++ /dev/null @@ -1,261 +0,0 @@ - -============================================================================ -LZO -- a real-time data compression library LIBRARY REFERENCE -============================================================================ - - -[ please read LZO.FAQ first ] - - -Table of Contents -================= - -1 Introduction to the LZO Library Reference -1.1 Preliminary notes -1.2 Headers -2 General -2.1 The memory model -2.2 Public integral types -2.3 Public pointer types -2.4 Public function types -3 Function reference -3.1 Initialization -3.2 Compression -3.3 Decompression -3.4 Optimization -3.5 String functions -3.6 Checksum functions -3.7 Version functions -4 Variable reference - - - -1 Introduction to the LZO Library Reference -============================================= - - -1.1 Preliminary notes ---------------------- - -- 'C90' is short for ISO 9899-1990, the ANSI/ISO standard for the C - programming language - - -1.2 Headers ------------ - -This section briefly describes the headers. - -<lzo/lzoconf.h> - - Contains definitions for the basic integral and pointer types, - provides wrappers for the library calling conventions, defines - error codes and contains prototypes for the generic functions. - This file is automatically included by all LZO headers. - -<lzo/lzo1.h> -<lzo/lzo1a.h> -<lzo/lzo1b.h> -<lzo/lzo1c.h> -<lzo/lzo1f.h> -<lzo/lzo1x.h> -<lzo/lzo1y.h> -<lzo/lzo1z.h> -<lzo/lzo2a.h> - - These files provide definitions and prototypes for the - actual (de-)compression functions. - - - -2 General -========= - - -2.1 The memory model --------------------- - -LZO requires a flat 32-bit or 64-bit memory model. - - -2.2 Public integral types -------------------------- - -lzo_uint - - must match size_t - -lzo_bool - - can store the values 0 ("false") and 1 ("true") - - -2.3 Public pointer types ------------------------- - -lzo_voidp - - pointer to void - -lzo_bytep - - pointer to unsigned char - - -2.4 Public function types -------------------------- - -lzo_compress_t - -lzo_decompress_t - -lzo_optimize_t - -lzo_callback_t - - - -3 Function reference -==================== - - -3.1 Initialization ------------------- - -int lzo_init ( void ); - - This function initializes the LZO library. It must be the first LZO - function you call, and you cannot use any of the other LZO library - functions if the call fails. - - Return value: - Returns LZO_E_OK on success, error code otherwise. - - Note: - This function is actually implemented using a macro. - - -3.2 Compression ---------------- - -All compressors compress the memory block at 'src' with the uncompressed -length 'src_len' to the address given by 'dst'. -The length of the compressed blocked will be returned in the variable -pointed by 'dst_len'. - -The two blocks may overlap under certain conditions (see examples/overlap.c), -thereby allowing "in-place" compression. - - -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -#include <lzo/lzo1x.h> - -int lzo1x_1_compress ( const lzo_bytep src, lzo_uint src_len, - lzo_bytep dst, lzo_uintp dst_len, - lzo_voidp wrkmem ); - - Algorithm: LZO1X - Compression level: LZO1X-1 - Memory requirements: LZO1X_1_MEM_COMPRESS (64 KiB on 32-bit machines) - - This compressor is pretty fast. - - Return value: - Always returns LZO_E_OK (this function can never fail). - -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -#include <lzo/lzo1x.h> - -int lzo1x_999_compress ( const lzo_bytep src, lzo_uint src_len, - lzo_bytep dst, lzo_uintp dst_len, - lzo_voidp wrkmem ); - - Algorithm: LZO1X - Compression level: LZO1X-999 - Memory requirements: LZO1X_999_MEM_COMPRESS (448 KiB on 32-bit machines) - - This compressor is quite slow but achieves a good compression - ratio. It is mainly intended for generating pre-compressed data. - - Return value: - Always returns LZO_E_OK (this function can never fail). - - -[ ... lots of other compressors which all follow the same principle ... ] - - - -3.3 Decompression ------------------ - -All decompressors decompress the memory block at 'src' with the compressed -length 'src_len' to the address given by 'dst'. -The length of the decompressed block will be returned in the variable -pointed by 'dst_len' - on error the number of bytes that have -been decompressed so far will be returned. - -The safe decompressors expect that the number of bytes available in -the 'dst' block is passed via the variable pointed by 'dst_len'. - -The two blocks may overlap under certain conditions (see examples/overlap.c), -thereby allowing "in-place" decompression. - - -Description of return values: - - LZO_E_OK - Success. - - LZO_E_INPUT_NOT_CONSUMED - The end of the compressed block has been detected before all - bytes in the compressed block have been used. - This may actually not be an error (if 'src_len' is too large). - - LZO_E_INPUT_OVERRUN - The decompressor requested more bytes from the compressed - block than available. - Your data is corrupted (or 'src_len' is too small). - - LZO_E_OUTPUT_OVERRUN - The decompressor requested to write more bytes to the uncompressed - block than available. - Either your data is corrupted, or you should increase the number of - available bytes passed in the variable pointed by 'dst_len'. - - LZO_E_LOOKBEHIND_OVERRUN - Your data is corrupted. - - LZO_E_EOF_NOT_FOUND - No EOF code was found in the compressed block. - Your data is corrupted (or 'src_len' is too small). - - LZO_E_ERROR - Any other error (data corrupted). - - -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -#include <lzo1x.h> - -int lzo1x_decompress ( const lzo_bytep src, lzo_uint src_len, - lzo_bytep dst, lzo_uintp dst_len, - lzo_voidp wrkmem ); - - Algorithm: LZO1X - Memory requirements: 0 - - -[ ... lots of other decompressors which all follow the same principle ... ] - - - -4 Variable reference -==================== - -The variables are listed alphabetically. - -[ no public variables yet ] - - - ---------------------------- END OF LZOAPI.TXT ------------------------------ - diff --git a/app/lzo/doc/LZOTEST.TXT b/app/lzo/doc/LZOTEST.TXT deleted file mode 100644 index 93c86591..00000000 --- a/app/lzo/doc/LZOTEST.TXT +++ /dev/null @@ -1,75 +0,0 @@ -The test driver 'lzotest' has grown into a fairly powerful program -of it's own. Here is a short description of the various options. - -[ to be written - this is only a very first draft ] - - -Usage: -====== - -lzotest [option..] file... - - -Basic options: -============== - - -m# compression method - -b# set input block size (default 262144, max 1310720) - -n# number of compression/decompression runs - -c# number of compression runs - -d# number of decompression runs - -S use safe decompressor (if available) - -A use assembler decompressor (if available) - -F use fast assembler decompressor (if available) - -O optimize compressed data (if available) - -s DIR process Calgary Corpus test suite in directory 'DIR' - -@ read list of files to compress from stdin - -q be quiet - -L display software license - - -More about '-m': -================ - -Use '-m' to list all available methods. - -You can select methods by number: --m71 - -You can select methods by name: --mlzo1x-1 --mlzo1x-999 --mlzo1x-1(11) - -You can select some predefined method groups: --mall --mlzo --mm1 --mm99 --mm999 --m1x999 --m1y999 - -You can specify multiple methods/groups separated by ',': --m1,2,3,4 --m1,2,3,4,lzo1x-1,m99,81 - -And finally you can use multiple '-m' options: --m962,972 -mm99,982,m1 - - -Other options: -============== - ---max-data-length=LEN - ---dict=FILENAME ---max-dict-length=LEN - ---dump=FILENAME - ---adler32 ---crc32 ---execution-time ---totals - |