Cosmetics: Removed trailing whitespace, converted tabs to spaces.

Originally committed as revision 4375 to svn://svn.ffmpeg.org/ffmpeg/trunk

1 files changed, 58 insertions, 58 deletions

diff --git a/doc/optimization.txt b/doc/optimization.txt
index 08caa89c1b..f435d0f0cb 100644
--- a/doc/optimization.txt
+++ b/doc/optimization.txt
@@ -10,12 +10,12 @@ i386 directory or find some other functions in the c source to optimize, but the
 arent many left
 
 Understanding these overoptimized functions:
-as many functions, like the c ones tend to be a bit unreadable currently becouse 
-of optimizations it is difficult to understand them (and write arichtecture 
+as many functions, like the c ones tend to be a bit unreadable currently becouse
+of optimizations it is difficult to understand them (and write arichtecture
 specific versions, or optimize the c functions further) it is recommanded to look
-at older CVS versions of the interresting files (just use CVSWEB at 
+at older CVS versions of the interresting files (just use CVSWEB at
 http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFmpeg)
-or perhaps look into the other architecture specific versions in i386/, ppc/, 
+or perhaps look into the other architecture specific versions in i386/, ppc/,
 alpha/, ...; even if u dont understand the instructions exactly it could help
 understanding the functions & how they can be optimized
 
@@ -29,106 +29,106 @@ the primary purpose of that list is to avoid wasting time to optimize functions
 which are rarely used
 
 put(_no_rnd)_pixels{,_x2,_y2,_xy2}
-	used in motion compensation (en/decoding)
+    used in motion compensation (en/decoding)
 
 avg_pixels{,_x2,_y2,_xy2}
-	used in motion compensation of B Frames 
-	these are less important then the put*pixels functions
+    used in motion compensation of B Frames
+    these are less important then the put*pixels functions
 
 avg_no_rnd_pixels*
-	unused
+    unused
 
 pix_abs16x16{,_x2,_y2,_xy2}
-	used in motion estimation (encoding) with SAD
+    used in motion estimation (encoding) with SAD
 
 pix_abs8x8{,_x2,_y2,_xy2}
-	used in motion estimation (encoding) with SAD of MPEG4 4MV only
-	these are less important then the pix_abs16x16* functions
+    used in motion estimation (encoding) with SAD of MPEG4 4MV only
+    these are less important then the pix_abs16x16* functions
 
 put_mspel8_mc* / wmv2_mspel8*
-	used only in WMV2
-	it is not recommanded that u waste ur time with these, as WMV2 is a
-	ugly and relativly useless codec
+    used only in WMV2
+    it is not recommanded that u waste ur time with these, as WMV2 is a
+    ugly and relativly useless codec
 
 mpeg4_qpel* / *qpel_mc*
-	use in MPEG4 qpel Motion compensation (encoding & decoding)
-	the qpel8 functions are used only for 4mv
-	the avg_* functions are used only for b frames
-	optimizing them should have a significant impact on qpel encoding & decoding
- 
+    use in MPEG4 qpel Motion compensation (encoding & decoding)
+    the qpel8 functions are used only for 4mv
+    the avg_* functions are used only for b frames
+    optimizing them should have a significant impact on qpel encoding & decoding
+
 qpel{8,16}_mc??_old_c / *pixels{8,16}_l4
-	just used to workaround a bug in old libavcodec encoder
-        dont optimze them
+    just used to workaround a bug in old libavcodec encoder
+    dont optimze them
 
 tpel_mc_func {put,avg}_tpel_pixels_tab
-	used only for SVQ3, so only optimze them if u need fast SVQ3 decoding
+    used only for SVQ3, so only optimze them if u need fast SVQ3 decoding
 
 add_bytes/diff_bytes
-	for huffyuv only, optimize if u want a faster ff-huffyuv codec
+    for huffyuv only, optimize if u want a faster ff-huffyuv codec
 
 get_pixels / diff_pixels
-	used for encoding, easy
-        
+    used for encoding, easy
+
 clear_blocks
-	easiest, to optimize
-        
+    easiest, to optimize
+
 gmc
-	used for mpeg4 gmc
-        optimizing this should have a significant effect on the gmc decoding speed but
-        its very likely impossible to write in SIMD
+    used for mpeg4 gmc
+    optimizing this should have a significant effect on the gmc decoding speed but
+    its very likely impossible to write in SIMD
 
 gmc1
-	used for chroma blocks in mpeg4 gmc with 1 warp point
-	(there are 4 luma & 2 chroma blocks per macrobock, so 
-        only 1/3 of the gmc blocks use this, the other 2/3 
-        use the normal put_pixel* code, but only if there is 
-        just 1 warp point)
-        Note: Divx5 gmc always uses just 1 warp point
+    used for chroma blocks in mpeg4 gmc with 1 warp point
+    (there are 4 luma & 2 chroma blocks per macrobock, so
+    only 1/3 of the gmc blocks use this, the other 2/3
+    use the normal put_pixel* code, but only if there is
+    just 1 warp point)
+    Note: Divx5 gmc always uses just 1 warp point
 
 pix_sum
-	used for encoding
-        
+    used for encoding
+
 hadamard8_diff / sse / sad == pix_norm1 / dct_sad / quant_psnr / rd / bit
-	specific compare functions used in encoding, it depends upon the command line
-        switches which of these are used
-        dont waste ur time with dct_sad & quant_psnr they arent really usefull
+    specific compare functions used in encoding, it depends upon the command line
+    switches which of these are used
+    dont waste ur time with dct_sad & quant_psnr they arent really usefull
 
 put_pixels_clamped / add_pixels_clamped
-	used for en/decoding in the IDCT, easy
-        Note, some optimized IDCTs have the add/put clamped code included and then 
-        put_pixels_clamped / add_pixels_clamped will be unused
+    used for en/decoding in the IDCT, easy
+    Note, some optimized IDCTs have the add/put clamped code included and then
+    put_pixels_clamped / add_pixels_clamped will be unused
 
 idct/fdct
-	idct (encoding & decoding)
-        fdct (encoding)
-	difficult to optimize
-        
+    idct (encoding & decoding)
+    fdct (encoding)
+    difficult to optimize
+
 dct_quantize_trellis
-	used for encoding with trellis quantization
-	difficult to optimize 
+    used for encoding with trellis quantization
+    difficult to optimize
 
 dct_quantize
-	used for encoding
-        
+    used for encoding
+
 dct_unquantize_mpeg1
-	used in mpeg1 en/decoding
+    used in mpeg1 en/decoding
 
 dct_unquantize_mpeg2
-	used in mpeg2 en/decoding
+    used in mpeg2 en/decoding
 
 dct_unquantize_h263
-	used in mpeg4/h263 en/decoding
+    used in mpeg4/h263 en/decoding
 
 FIXME remaining functions?
 btw, most of these are in dsputil.c/.h some are in mpegvideo.c/.h
 
 
-        
+
 Alignment:
 some instructions on some architectures have strict alignment restrictions,
 for example most SSE/SSE2 inctructios on X86
 the minimum guranteed alignment is writen in the .h files
-for example: 
+for example:
     void (*put_pixels_clamped)(const DCTELEM *block/*align 16*/, UINT8 *pixels/*align 8*/, int line_size);
 
 
@@ -139,7 +139,7 @@ http://www.aggregate.org/MAGIC/
 X86 specific:
 http://developer.intel.com/design/pentium4/manuals/248966.htm
 
-The IA-32 Intel Architecture Software Developer's Manual, Volume 2: 
+The IA-32 Intel Architecture Software Developer's Manual, Volume 2:
 Instruction Set Reference
 http://developer.intel.com/design/pentium4/manuals/245471.htm