ĐĎॹá>ţ˙ ~ţ˙˙˙}€˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ěĽÁ5@ řżö{bjbjĎ2Ď2 6”­X­Xés ˙˙˙˙˙˙ˆ&&&&&&&”x$x$x$8°$Ä$L”r/:% % % % % % % %Œ'Ž'Ž'Ž'%ł' S+ ó.$Ź0Rţ2L/& % % % % %/&& % %,/Ě%Ě%Ě% % & %& %Œ'Ě% %Œ'Ě%Ě%Ţ%.'&&h' %% €‡…˘Ćx$*%|F'Œ'B/0r/`'J3Ś%J3h':Ô†&&&&J3&h'$Ě% % % %//””äx$ź%””x$Chapter 5PRIVATE  Motion Video There are three basic ways to bring motion video to PCs: 1. analog passthrough, which includes the laserdisk and videocassette recorder (VCR); 2. softwarebased video, now part of Multimedia Windows; and 3. hardwareassisted video, such as used in DVI (Digital Video Interactive), JPEG (Joint Photographic Experts Group), and MPEG (Motion Picture Experts Group) compression schemes. Analog Pass-Through We mentioned earlier that Microsoft is releasing the Multimedia Extensions to Windows in stages. We also noted that the Extensions contain drivers for videodisc players; but Windows 3.1 does not. This means that only those who have the Multimedia Extensions can use analog video from a videodisc. While cards and software exist to capture video from a video camera, a VCR, or a television, we do not yet have an agreed upon standard for performing this task; and Windows does not yet support this capability. Generally, these devices allow users to view analog video sequences on their computer monitors, resize the window to any desired size, and capture individual frames for later use or manipulation. These devices use time-based rather than frame-based coding (more on this later in this chapter); so they cannot yet deal with video sequences. Within the year, we should see the development of software that will allow these boards to work with video sequences. Software-Based Video Multimedia Windows A "software only" approach to motion video relies on the built-in capabilities of the computer, eliminating the need for additional hardware or special video cards. However, this approach assumes a relatively powerful base computer. Multimedia Windows follows this approach in implementing motion video, which it calls a movie. Any Multimedia PC that has the Multimedia Movie Player dynamic link library (MMP.DLL) loaded on its system can display a MacroMind Director movie. If the movie uses the Media Control Interface (MCI) to control audio or an external device, then it also requires the installation of the MCIMMP.DRV device driver. Windows with Multimedia can play a movie in any one of three ways: 1. It can utilize the application programming interface (API) supported by the Movie Player DLL. This requires the application developer to write a custom movieplayer program. 2. The user can run animations from the Windows Media Player applet. Multimedia Windows includes the Media Player (MPLAYER.EXE), a generalpurpose MCI player that allows controlling MCI devices installed on the system. 3. Any authoring environment that supports the use of MCI (such as Asymetrix ToolBook) can play movie files using the MCI animation device. A movie designed to run on a Multimedia PC must support a range of potential delivery platforms, ranging from the base Multimedia PC (with an 80386, 10mHz processor and 16color [VGA video adapter]) to more powerful machines (equipped with 80486 or 80586 processors and 256color VGA video adapters). These differences in CPU speed and palette handling can cause unexpected results when playing movies. Intel Corporation and Microsoft Corporation currently have a version of a specification (called DV MCI) for the digital video command set for MCI in beta testing. It should appear in finalized form before the publication of this book. The specification intends to expand the Media Control Interface to work with all current and future forms of digital video. This means that applications written to the interface will work automatically no matter what kind of digital video they incorporate. This command set will allow Windows users to take full advantage of digital video's special capabilities, such as storage, transmission, and manipulation of video sequences. The specification applies to hardware and software manufacturers of digital video products as well as to developers creating applications using the digital video products. Not limited to a single manufacturer's hardware, it should apply to a wide range of hardware implementations. "SoftVideo" Many companies favor the software only approach. We shall look at a couple of examples. TMM, Inc., an electronic publisher of multimedia products for the education, entertainment, and archived data industries produces proprietary "SoftVideo" decompression software. "SoftVideo" permits the softwareonly based playback of NTSC quality video and allows traditional personal computers with sound boards to function as fullmotion playback terminals without any additional hardware. In addition to the entertainment applications of "SoftVideo", such as the playback of fulllength feature films, television programming, and interactive video games, TMM has expanded the software's capabilities to include realtime video teleconferencing over an Ethernet LAN as well as traditional telephone and/or ISDN lines. "SoftVideo" currently runs with any program configuration using a standard AT 286class VGA computer with a DOS, UNIX, or MAC operating system. PICS Animation Compiler The Company of Science & Art (CoSA) has a product, called "PACo" ­ the PICS Animation Compiler which improves the delivery of audiovisual information on a computer. PICS, an industry standard file format for the Macintosh, stores video and animation information. PACo enhances the playback of such information and allows end users to combine productions with synchronized sound tracks. It comprises a processing and presentation tool which is particularly effective for productions distributed on CD-ROM. PACO consists of an animation and digital video engine. Its unique compression scheme is optimized for speed; and it dramatically reduces the amount of RAM needed to run a multimedia production. It provides a softwareonly solution to the startup delays and memory constraints of current playback technology. PACO works in two stages. First, in a compilation stage, it imports PICS or PICT files and SoundEdit files and compresses them into an optimizedforspeed format. Then, in playback, PACo rapidly decompresses each image as it draws it to the screen. Since PACo decompresses the frames on the fly, it only needs to read into memory one frame at a time, rather than the whole production. The maximum possible length of an animation, therefore, is only constrained by the amount of available disk space, not the amount of available RAM. PACo also has comprehensive synchronization abilities that allow precisely synchronizing sound tracks to animations. In addition, the lossless compression scheme reconstructs images identical to the original. PACo reads information from storage as fast as the storage medium can deliver it; and it can run almost any animation in one megabyte of RAM. PACo's most interesting feature is the platform independent playback it provides. The system gives users the ability to create videos, animations, and QuickTime movies on a Macintosh computer and play the same file, unmodified, on all Apple Macintosh personal computers, PCs running Windows 3.0 or 3.1, and SPARCstations from Sun Microsystems. Users only need one copy on a heterogeneous network; and they can move the animations between platforms using any file transfer program. The PACo system includes PACo Producer 2.0 which compresses and presents animations, digital videos, visualizations, and audio files. It can be used with any Macintosh application that outputs PICS, PICT, 8bit audio files, or QuickTime movies. PACo Producer takes those files and packs them into a unique, compressed file format optimized for minimal RAM requirements, rapid loading time, and smooth playback. PACo Producer has sound synchronization abilities that enable users to combine sound files with their animation or video. The company also has a comprehensive DLL (Dynamic Link Library) for Windowsbased interactivity environments. PhotoMotion IBM will also offer a range of products for software video compression/decompression. It now offers IBM PhotoMotion, a DOS software compression approach that provides synchronized video and audio, used in consumer/education titles such as National Geographic's Mammals and Presidents, Falcon Software's Introductory Chemistry CDROM, The New Grolier's MultiMedia Encyclopedia, and the 1991 Time Magazine Compact Almanac. PhotoMotion plays its video clips completely under DOS. Designed to execute behind the scenes, PhotoMotion allows developers to integrate video and audio into their applications, regardless of what programming language or authoring environment they use. PhotoMotion features include: ˇ Up to fullscreen motion video playback with synchronized audio (hard drive source); ˇ Quarterscreen CDROM motion video playback with synchronized audio (twohour capacity at 10 frames/second); ˇ More than twenty hours of audioonly CDROM playback; ˇ Requires only the addition of a CDROM drive and audio card for title publishing applications ­ and only a CDROM drive for videoonly publishing; ˇ Multiple video frame rates selectable up to 30 frames/second. In addition to PhotoMotion, IBM plans to provide a stateoftheart Compression/Decompression (CODEC) approach on future releases of OS/2 MMPM/2 (Multimedia Presentation Manager). This CODEC technique represents a new technology that has grown out of the audio and video interleaving capabilities of the PhotoMotion software CODEC product. This software will utilize the full multitasking environment of OS/2. It will support the addition of other CODEC approaches from IBM or other software vendors, using the open MMPM/2 compression architecture. Hardware-Based Video Digital Video Interactive Digital Video Interactive currently appears as the most promising method of rendering hardware-based full motion video on the PC. DVI technology provides for up to 72 minutes of full-screen, full-motion (30 frames/sec) video/audio playback from a CD-ROM drive, rewritable optical disk, hard drive, or local area network. In addition, DVI technology supports real time full-motion video capture and the capture and playback of high-resolution still images in a range of formats. DVI technology has multiple advantages: ˇ A programmable Intel chip set. This programmability allows DVI technology to remain open to multiple present and future video compression standards ­ a key distinction of DVI technology over solutions that "hardwire" a particular compression algorithm. ˇ A stable technological road map. The compression techniques supported in the current products will be available in future generations, thus allowing developers and customers to plan and predict the evolution of their applications over time. ˇ RTV (Real Time Video) capability. RTV supports on-thefly capture and playback of video, allowing lowcost inhouse development of multimedia applications. ˇ Platform independence. Many environments, including OS/2, DOSbased LinkWay Live!, and DOS/Windows can employ identical DVIcompressed content. ˇ The ability to update DVI applications and content incrementally, which stems from DVI digital technology. ˇ Convenient content portability on small digital media, such as rewritable optical disks and CDROM discs. ˇ The ability to network DVI content. DVI technology basically consists of software and a set of video processors, the i750 PB/DB (pixel processor and display processor), that give manufacturers the ability to create a digital, multimedia personal computer or platform. These video processors comprise high-speed, special purpose computer chips to compress, decompress, and display video in the personal computer. These processors allow manufacturers to build add-in multimedia boards or to build multimedia capability right onto the motherboard of a personal computer. Compression We have seen that motion video requires a significant amount of compression for storage. It also demands a computer with a good deal of processing power to decompress the images and display them in real time. Compression can decrease the size of video files to the point that they require less storage space than uncompressed audio and still images. A full screen VGA graphic (640 x 480 resolution), for example, uses 307,200 bits (or about 38 K) of storage space in uncompressed mode. If we multiply that by the color depth of the image, say 9 bits, we need 2,764,800 bits or 345,600 K for each frame. A frame consists of a complete image, typically intended for playback at 30 frames per second (fps). (Visual material that originated on film, however, will have a natural frame rate of 24 fps, while PAL originated material will have a frame rate of 25 fps.) So, we multiply by 30 to learn that each second of 9-bit VGA video will require 10,368,000 bytes (just over 10 MB) of storage space in uncompressed mode. Higher resolution or greater color depth will increase these requirements even more. Compression can reduce storage requirements to an average of five kilobytes per frame for a total of 150 K per second, which matches exactly the transfer rate of the CD-ROM drive. Because multimedia applications require large file sizes, compression is highly desired. Without compression, we cannot store motion video and play it back at normal data rates on a personal computer. Compression also represents a key factor in allowing DVI applications to work over a Local Area Network (LAN). A LAN requires motion video, still images, and audio in a digital format for transmission; so in order for the application to work in a cost effective way, the data must be compressed. Otherwise, the rate of delivery will be far too slow and the file sizes too big to be economical. A 16-bit video image converted into digital format at a resolution of 512 x 480 represents almost 500 K (491,520 bytes of data) in uncompressed form. CD-ROM stores about 650 MB of data which means that it can only store about 44 seconds of uncompressed motion video. Since the CD-ROM delivers only 150,000 bytes of data per second, those 44 seconds of digitized, uncompressed motion video would take more than an hour to play back, as each frame would get constructed at 150,000 bytes of information or data per second. Motion video would look like it was being slowly painted on the screen. Intel's PLV (Production Level Video) compression algorithm permits storing over one hour of motion video and audio on CD-ROM; and it matches exactly the rate of data delivery from the CD-ROM. Consequently, that hour of compressed, digital video plays back at the standard video rate of 30 fps; and it plays back in real time. In other words, motion video that requires an hour to view takes an hour to play back. However, it requires performing the compression at a special facility. These same algorithms could apply to video for storage on hard disk or transmission over a network. Real Time Audio and video data depend on time. In other words, they must play continuously, without unintended interruptions. So they must have a high priority compared to other things going on in the computer. Many personal computer operating systems (such as MSDOS) do not provide for realtime operations; so real-time operations must have a path around the operating system on these computers. Using the interrupt capability of a PC AT can do this, except that some DOS functions, such as disk access, disable the interrupts. For example, in a PC AT, if we use the hard disk to store audio, we will need to use DOS to get the data and pass it to the audio hardware. To keep the audio playing while DOS gets more data usually requires that the audio hardware contain buffering on its data input. Usually the rest of the application can be designed so that it never requires an access longer than several seconds without an interrupt. That means if it requires longer accesses, the application must call them in pieces to allow interrupts to get in. Since the audio data rate on the average is quite low (4,000 to maybe 16,000 bytes per second) and we can reasonably expect the audio hardware to have 16 K of memory on board, we can buffer up to four seconds of audio to cover disk accesses. Buffering permits retrieving data in blocks large enough to keep a steady supply of data stored ahead in the playback hardware to prevent running out of data during the longest possible disk access. This capability comprises a key advantage of digital systems over analog systems. Buffering has a disadvantage, however, in that it implies some delay in starting because we must fill up the buffer before we begin playing. DVI's Realtime Video (RTV), also called Edit-Level Video (ELV), uses a 386based computer equipped with ActionMedia hardware and software to compress motion video in real time. While it can play back at a full 30 frames per second, the resulting images have a lower quality than those produced with PLV compression which spends more computing power and more time on each frame of video. ELV can occur in-house, in real time, for immediate placement in the application or transmission. It involves no additional cost for off-line compression. It uses a different algorithm than PLV to compress files. Each image comprises a still image; and ELV files are typically larger than PLV files, with each frame averaging 7 to 10 kilobytes. It supports completely variable frame size and playback speed. ELV can capture data at 10 fps or 30 fps, for example. It can show the resulting files at 1/4 screen, 1/2 screen, or full screen. The ELV image has a resolution of 128 x 120; and line doubling, or interpolation, can display it at 256 x 240 resolution. Presentation Level Video In contrast, the process used to create PLV files currently requires sending the material to a DVI Compression Service facility. "These facilities require developers to submit a l inch NTSC broadcastquality tape and a special form (similar to an edit decision list) that identifies the video sequences selected for compression. When complete, the Compression Service facility returns digital streamer tape that contains motion video files in a DOS format. These files can then be copied onto the development workstation's hard disk and integrated into the application. Like the RTV files, they are played back directly through the ActionMedia delivery boards." 1 The PLV compression process follows several steps. First, it converts the video from an analog to a digital signal. Then, it compresses the digital files by a ratio of over 100:1. The compression algorithm uses a delta encoding scheme, storing differences between frames and eliminating data repeated in each frame. The compression algorithm "looks at" each frame of the video and determines the differences from the previous one. It stores completely the first frame of a sequence, called the reference frame. From the reference frame forward, the algorithm stores only the differences (a process called motion compensation). When the differences become very large, the algorithm inserts a new reference frame. Developers can also elect to have the algorithm insert reference frames every so often, such as every 15 seconds. This proves particularly useful when an application makes reference to a segment that does not occur at the beginning of a sequence. The resulting files are smaller than ELV files and have better quality images, since the procedure applies more processing power and time to each frame for compression. ELV and PLV files differ in quality because of the type of compression used in each process. Another concept that we must consider with motion video systems involves the balance between compression and decompression. A balanced compression/decompression system uses the same hardware for both compression and decompression (as does ELV) and performs both processes at roughly the same speed. Such a system generally requires hardware that proves too costly for a single-user system. Using lower cost hardware, on the other hand, sacrifices picture quality. The use of an unbalanced system which performs the compression on expensive hardware and the decompression on low-cost hardware (as does PLV) effectively bypasses the problem. This works in situations where the single-user system only needs to play back compressed video prepared ahead of time. Most interactive video applications only require the end-user system to have decompression capability. This permits compressing motion video for this class of application only once, during the application design process. The end-user only plays back the compressed video. All the users of the application then share the cost of the compression process. A centralized compression service which performs compression for many application developers could result in even further cost sharing. DVI technology supports both balanced and unbalanced motion video compression/decompression. The unbalanced approach, Presentation-Level Video, involves sending video to a central compression facility which uses large computers and special interface equipment. This process produces high-quality pictures for playback on any DVI system. The other DVI compression approach, called Edit-Level Video, can be done on any DVI system that has the video digitizer option installed. Playback of ELV can occur on the same system or any other DVI system. Because ELV involves a balanced approach which uses only the computing power available in a DVI system for compression, ELV has a lower picture quality compared to PLV2. Compressed motion video resolution PLV images have a resolution of 256 x 240 interpolated to 512 x 480 to match the scan rate of a VGA monitor. ELV files get interpolated to display at 256 x 240. It is important to understand, however, that the spatial resolution (the number of horizontal and vertical pixels or dots) of a motion video file does not relate directly to quality as it does in a graphics file. Because the images change rapidly and have a richness of color, the quality of compressed motion video appears much higher than the numbers would suggest. While motion video quality is subjective to some extent, the 256 x 240 resolution should prove adequate for most applications. Still Image and Audio Compression In addition to compressing motion video, DVI technology can also compress still images and audio to balance the storage and playback requirements of various media. The capacity of a 650 MB CDROM using DVI files could yield: Text: 650,000 pages Audio: 5 hours FM stereo or 22 hours midrange monaural or 44 hours near AM quality monaural Video Stills: 5000 very high resolution (768 x 480) or 10,000 high resolution (512 x 480) or 40,000 medium resolution (256 x 240) MotionVideo: 72 minutes of full screen full motion (256 x 240 resolution at 30 frames per second) Mix and match example: 20 minutes of full motion video with 5000 high resolution stills with 6 Hours of audio over stills with 15,000 pages of text The requirements of an application may involve tradeoffs in quality of some forms of data to maximize storage of larger quantities of other types of data. The I750 video processors The i750 PB/DB video processors make possible the compression and subsequent display of motion video and other elements in a multimedia application. They have an architecture that allows the development of multimedia software applications today that will also play on future generations of processors, just as word processors developed for personal computers based on the 8088 microprocessor can also operate on machines using the 80386 microprocessor. The i750 video processor family has also been designed to support planned future generations of motion video compression technology. Applications built with the ActionMedia boards based on the i750A video processors provide a good example in that they can also play on new products based on the i750 PB/DB. In addition, the i750 PB/DB can process other compression algorithms, such as JPEG still algorithms. Resolution Because the i750 video processor is programmable, it can make more than one display resolution available for video imagery. Motion video, for example, displays at a resolution of 256 pixels across by 240 pixels high. Still images can display at a variety of resolutions up to 468 pixels across to 480 pixels high. Most people assume that the higher the resolution of an image, the higher its quality. While true in graphics and, in some cases, still images, pixel depth also plays an important part in the quality of images when displayed on the PC. While motion video displays at a resolution of 256 x 240, we cannot correlate this to the same resolution as it applies to graphics. Instead, we should think about this resolution as VCR quality, also keeping in mind that we can play this motion video on a screen that has 512 x 480 resolution mode. It will play back as 1/4 of the screen. The image has not changed resolution; the screen just has more pixels. Thus, the image displays in a fourth of the available area; and it appears sharper. File size is a critical element in the design of multimedia applications and in understanding the particular challenge of displaying motion video from data played back from a CDROM. Now that we understand how the data to represent a picture is made up, calculating the file size is straightforward math, just as for calculating the size of a single frame graphic. Pixels x color depth / 8 = file size 512 x 480 x l bit deep = 245,760 bits ( 8 = 30,720 bytes or 30 K 512 x 480 x 16 bits deep = 3,932,160 bits ( 8 = 491,520 bytes or 480 K 512 x 480 x 24 bits deep = 5,898,240 bits ( 8 = 737,280 bytes or 720 K Displaying Digital Motion Video in a Multimedia System Displaying motion video on the PC presents a new challenge. Our standard for broadcast video (television) display, NTSC, displays motion by showing 30 frames of video every second. According to the mathematics shown above, 30 frames of 16-bit video at a resolution of 512 x 480 would require over 14 megabytes of storage for every second of video, and almost 1 gigabyte per minute. It becomes impractical to store such large files on PCs; and they exceed the data-transfer rate of a personal computer or local area network. CD-ROM presents an ideal medium for the distribution of software using multimedia because of its large capacity and its read-only nature. However, any compression of motion video must take into account the CD-ROM drive's limitation of 150 kilobyte-per-second data transfer rate. This averages out to 5 kilobytes per frame. Compression of fullmotion video involves one of the central concepts and technical implementations behind DVI technology. Compression's essential function entails reducing significantly the amount of digital information required for fullmotion video for economical storage and play back through standard personalcomputer storage devices like CDROM, hard disk, or LANs. Compression represents only onehalf of the process involved in making this possible. Decompression is the other half. The processes of compression and decompression (CODEC) are also referred to as encoding and decoding. "Regardless of the terminology, the analog signal produced by video must be converted into digital format prior to compression, a process called capture. Compression is an algorithmic reduction in the amount of information contained in each frame of video. Decompression involves retrieving this information and reconstructing it for display on a computer monitor... The more information introduced in any single frame, either through fast motion, the introduction of new objects, or the extremely fast movement of a camera through a scene, the more difficult the compression task becomes.3" Video formats Video for the production of DVI can be recorded in a variety of tape formats, ranging in quality from VHS, which is used almost exclusively for home/personal recordings, to 1 inch video tape, the high-end broadcast-quality video format. New digital formats, like D2, may eventually replace 1 inch tape. Along the continuum, formats such as 3/4 inch video tape, BetaCam, MII, and other recording formats are also available. Each of these formats has advantages and disadvantages. Generally, the more expensive the format and the recording equipment, the higher the quality of the resulting motion-video imagery. Currently, compression facilities for PLV only accept the highest quality, 1 inch broadcast tape. In the future, these facilities will probably diversify and specialize in different formats. The compression algorithms merely read the information in the frame. They do not correct for color, lighting, or other poor production results. Developers have a wide range of choices for creating motion video products for the PC. They can use analog or digital video; and they can use a software-only or a hardware-based approach. They have a variety of video cards to choose from that perform the compression/decompression tasks. They also have several options for accomplishing the same tasks without the addition of a motion video card. Now that we have examined the data formats that comprise multimedia presentations, we turn our attention to authoring environments or programs that support the production of multimedia presentations. 1. Bunzel, Mark J. Multimedia applications development: using DVI technology. New York : McGrawHill, 1992. p. 27 2. Luther, Arch. Digital video in the PC environment: featuring DVI technology. New York : Intertext Publications; McGraw-Hill Book Co., 1991. pp. 206-207 3. Bunzel. op. cit. pp. 175-76    #Ť ż Š Ÿ   ł âíŠÁÓ&Ţ&ĺ'ě'đ'ű'(,(.(W(a(ƒ(˘-Ň-Ţ/ý/ß01Ó1ő1r2‰23H3t3”3á346)6B&BňL M˘OŁOťTÂTLVVV\\ňŢĎşŢňŻňŻňŻňŻňŻňŻňŻĄŻĄŻĄŻĄŻĄŻňŻĄŻĄŻĄŻĄŻĄŻĄŻĄŻňŻňŻňŻ•ŻĄŻĄŻ•hĹ5Ĺhćh/H*OJQJhĹ5Ĺhćh/6OJQJ]hĹ5Ĺhćh/OJQJ)jhĹ5Ĺhćh/5OJQJU\hĹ5Ĺhćh/5OJQJ\&jhĹ5Ĺhćh/5OJQJU\hĹ5Ĺhćh/5OJQJ\:#$^_ˇ¸ö÷Ş Ť ż Ŕ é ę ‰ Š Ÿ   ´ ľ ţ˙67z{öö$˛ö$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛ö$˛đ$˛đ$˛đ$˛đ $˛đ$˛ö$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛đ$˛dđ*$ $dđ*$a$é{ő{ýý{,-  –—+,ĆÇáâîďĐŃŠŞÂĂ˝žôőw x l"m"N$ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛dđ*$N$O$Ň&Ó&ß&ŕ&…(†(„)…)Ł)¤)ű)ü)k*l*¤*Ľ*:+;+{+|+Ą-˘-ˇ-¸-Ó-Ô-ł/ů$˛ů $˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛đ$˛ů$˛ů$˛ů$˛ů$˛ $dđ*$a$dđ*$ł/´/Ý/Ţ/Ţ0ß0Ň1Ó1q2r233s3t3ŕ3á34466*6+6‰7Š7y:z:‡;ˆ;‚=ƒ=ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů$˛ů$˛dđ*$ƒ=Ó?Ô?BB'B(B2D3D/G0G×HŘH\J]JńLňL M M¤OĽOâPăPfSgSmTnTeWfWOYů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛dđ*$OYPY\\?\@\Đ^Ń^ó^ô^Ő_Ö_ę_ë_`&`I`J``¨`Î`Ď`1a2anaałaÉaů$˛ů $˛ů$˛ů$˛ů$˛ů $˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ů$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ď$˛ Ć0ýdđ*$dđ*$\\>\Ń^ň^eb~báeëeĂkÄk l lSlTlslŠltžtĄtŽtÍz{>{{{é{ę{ë{ě{í{î{ď{đ{ń{ň{ó{ő{ö{őçőçőçőŮőËőËőËőçőżőçőŮőŮőľą­§­§ą­§ą­ő hćh/^JhĹ5Ĺhćh/jhćh/U^JhĹ5Ĺhćh/H*OJQJ j¸đhĹ5Ĺhćh/OJQJhĹ5Ĺhćh/6OJQJ]hĹ5Ĺhćh/5OJQJ\hĹ5Ĺhćh/OJQJ%Éadbebb€bFdGdŕeáeěeíe'g(ghhjjtkukœkkßkŕk(l)lqlrlő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ŕ$„¸ő$˛ŕ$„¸ő$˛ŕ$„¸ő$˛ Ć 0ýĐ„ „`údđ*$^„ `„`ú Ć0ýdđ*$rlslŞlŤlˇn¸nüoýoOrPr tĄtŻt°twwcxdxšzşz,{-{Č{É{č{é{ë{ě{ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő $˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛ő$˛đîgdćh/ Ć0ýdđ*$ě{í{î{đ{ń{ó{ô{ő{ö{úřóřóřřé$˛ Ć0ýdđ*$gdćh/dě˙400P:pćh/°Đ/ °ŕ=!° "° # $ %°° ° QD phoenixç!œX@ń˙X Normal1$7$8$H$$CJOJQJ^J_HaJmH sH tH DA@ň˙ĄD Default Paragraph FontRió˙łR  Table Normalö4Ö l4Öaö (k@ô˙Á(No List 8+@ň8  Endnote Text^J>*@˘> Endnote ReferenceH*:@:  Footnote Text^J@&@˘!@ Footnote ReferenceH*T@T TOC 1/ Ɛ$ „Đ„Đ„0ýdđ¤ŕ*$]„Đ^„Đ`„0ýH@H TOC 2# Ɛ$ „Đ„Đdđ*$]„Đ^„ĐH@H TOC 3# Ɛ$ „Đ„Đdđ*$]„Đ^„ĐH@H TOC 4# Ɛ$ „Đ„Đdđ*$]„Đ^„ĐH@H TOC 5# Ɛ$ „Đ„Đdđ*$]„Đ^„ĐH@H TOC 6# Ɛ$„Đ„0ýdđ*$^„Đ`„0ý@@@ TOC 7„Đ„0ýdđ*$^„Đ`„0ýH@H TOC 8# Ɛ$„Đ„0ýdđ*$^„Đ`„0ýH@H TOC 9# Ɛ$ „Đ„0ýdđ*$^„Đ`„0ýL @L Index 1# Ɛ$ „Đ„0ýdđ*$^„Đ`„0ýD @D Index 2 Ɛ$ „Đdđ*$^„ĐD.@D  TOA Heading Ɛ$dđ*$."@. Caption^J:ţOň˙: _Equation Captionös”˙˙˙˙ ˙˙ z™ ˙˙ z™ ˙˙ z™ ˙˙ z™ ˙˙ z™ ˙˙ z™ ˙˙ z™ ˙˙ z™ ˙˙  z™ ˙˙  z™ ˙˙  z™ ˙˙  z™ ˙˙  z™6Đ#Ő$Ľ,Ó7]B6MÖWv_&iČsös+Ěx”/ ž )  #$^_ˇ¸ö÷ŞŤżŔéꉊŸ ´ľţ˙67z{, - – — + , ĆÇáâîďĐŃŠŞÂĂ˝žôőwxlmNOŇÓßŕ… † „!…!Ł!¤!ű!ü!k"l"¤"Ľ":#;#{#|#Ą%˘%ˇ%¸%Ó%Ô%ł'´'Ý'Ţ'Ţ(ß(Ň)Ó)q*r*++s+t+ŕ+á+,,..*.+.‰/Š/y2z2‡3ˆ3‚5ƒ5Ó7Ô7::':(:2<3</?0?×@Ř@\B]BńDňD E E¤GĽGâHăHfKgKmLnLeOfOOQPQTT?T@TĐVŃVóVôVŐWÖWęWëWX&XIXJXX¨XÎXĎX1Y2YnYYłYÉYdZeZZ€ZF\G\ŕ]á]ě]í]'_(_``bbtcucœccßcŕc(d)dqdrdsdŞdŤdˇf¸fügýgOjPj lĄlŻl°loocpdpšrşr,s-sČsÉsčsésęsësěsísîsđsńsósôs÷s˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€˜0€€p˜0€€ˆ˜0€€p˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€ˆ˜0€€˜0€€˜0€€p˜0€€ˆ˜0€€p˜0€€ˆ˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€ˆ˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€˜0€€p˜0€€p˜0€€ˆ˜0€€˜0€€˜0€€˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€ ˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€ˆ˜0€€p˜0€€p˜0€€p˜0€€ˆ˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€ˆ˜0€€ˆ˜0€€ €˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€˜0€€˜0€€p˜0€€ˆ˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€˜0€€˜0€€p˜0€€ˆ˜0€€H˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€ˆ˜0€€ˆ˜0€€p˜0€€ˆ˜0€€˜0€€˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€p˜0€€X˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€˜0€€p˜0€€p˜0€€˜0€€p˜0€€˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€ˆ˜0€€ˆ˜0€€`˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€p˜0€€˜0€€˜0€€ˆ˜0€€˜0€€˜0€€p˜0€€ˆ˜0€€ˆ˜0€€ˆ˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€p˜0€€p˜0€€p˜0€€p˜0€€p˜0€€˜0€€ˆM90D ›xŽÍĹáâîďM90›M90›M90›M90›M90›M90›M90›M90› \ö{>F{N$ł/ƒ=OYÉarlě{ö{?ABCDEGHIő{@ös÷sbhťÉú hÉX#y#Ÿ&Ž&Ä*Ć*ĄA´AĺDďDńD÷s:::::::::ňDčs÷sés÷s˙˙Normdd˙˙˙˙˙˙˙˙˙....()()))˙d˙˙˙˙˙˙ WP List 0˙˙ĺćh/EHĹ5Ĺ˙@PDFCreatorNe00:winspoolPDFCreatorPDFCreatorXXLetterPRIVâ0''''Ä\KhCçąKL ˙PDFCreatorXXLetterPRIVâ0''''Ä\KhCçąKL ˙€ř%ÄösP@˙˙Unknown˙˙˙˙˙˙˙˙˙˙˙˙G‡z €˙Times New Roman5€Symbol3& ‡z €˙ArialK,‡ŸBookman Old Style71 Courier"ˆ)đĐśNB§ĆNB§ĆLb ;ŇLb ;Ň$)đP€ĽŔxxƒŽsŽs3ƒ)đP€ßß đ˙?˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ćh/˙˙ Chapter 5NormNorm ţ˙ŕ…ŸňůOhŤ‘+'łŮ0l˜Ź¸ČÔŕđ   ( 4 @LT\dä Chapter 5 hapNormer ormormNormal Norml 2rmMicrosoft Word 10.0@@\9`˘Ć@\9`˘Ć Lbţ˙ŐÍ՜.“—+,ůŽ0đ hp|„Œ” œ¤Ź´ ź ŇäeŇ;ŽsA  Chapter 5 Title  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJţ˙˙˙LMNOPQRţ˙˙˙TUVWXYZ[\]^_`abcdefghijklţ˙˙˙nopqrstţ˙˙˙vwxyz{|ţ˙˙˙ý˙˙˙ţ˙˙˙Root Entry˙˙˙˙˙˙˙˙ ŔF xŸ˘Ć‚€Data ˙˙˙˙˙˙˙˙˙˙˙˙K1Table˙˙˙˙SZ3WordDocument˙˙˙˙6”SummaryInformation(˙˙˙˙˙˙˙˙˙˙˙˙mDocumentSummaryInformation8˙˙˙˙˙˙˙˙uCompObj˙˙˙˙˙˙˙˙˙˙˙˙j˙˙˙˙˙˙˙˙˙˙˙˙ý˙˙˙ţ˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ţ˙ ˙˙˙˙ ŔFMicrosoft Word Document MSWordDocWord.Document.8ô9˛q