TR201905028T4 - Arimetic decoding method and apparatus. - Google Patents

Abstract

A decoding method and an arithmetic decoder are described. In one embodiment, an arithmetic decoder includes a sequencer for generating a content identifier for an action of an action sequence; a probability estimator for determining a value for a least likely symbol (LPS) and a probability estimate of the LPS; and a decoding engine including a slot register to assign a value to a range of LPS, where the decoding engine defines the interval value of the LPS based on probability estimation, a value stored in the interval register and the content identifier, and the decoding engine also It determines a value of a binary action as a result of decoding based on the value of the interval and the bits from an information array containing arithmetically coded data.

Description

TECHNICAL FIELD The present invention relates generally to information theory, video coding, and arithmetic encryption. More specifically, the present invention relates to a method and apparatus for creating and using a state machine during arithmetic encryption and byte stuffing, whereby the process is performed separately. PRIOR ART Data filtering is particularly useful for storing and transmitting large amounts of data. For example, the time required to transmit an image, such as a document, through a network transmission, is drastically reduced by the time the filtering process takes to generate the number of bits required to reconstruct the image. Many different filtering techniques exist in the prior art. Sliding techniques can be divided into two broad categories: strong encryption and weak encryption. Strong encryption involves encryption that results in information loss, so there is no guarantee that the original data was perfectly reproduced. The purpose of the recording is to ensure that changes are not made to the original data in a way that can be detected or detected. All information is kept and the data is erased in a way that allows perfect reconstruction. ITU-T Recommendation El-1.263 "Video Coding for low Bitrate Communication" describes an arithmetic encryption method for low bitrate video encoding. Arithmetic encryption is a well-known encryption technique used in some encoding and encryption systems to reduce the number of bits or symbols required for transmission. An arithmetic decoder receives or accesses encoded data. The decoder reads the encoded data stream and produces decoded data, which must be matched to the input symbols received by the decoder. The SLEISTLNA process is achieved by generating fewer bits in the information sequences of the encoded actions. Here, the ratio of actions to encoded information bits can reach 64:1 or even 128:1, depending on the probability of the actions. Preferably, the decoding process is symmetric with the encoding capability. If the encoder and decoder are symmetric during the process, the number of coded data bits read at the decoder should match the number of coded bits generated by the encoder. In some metrical decoders, after the decoding process is initiated, the decoder reads one group of bits ahead. However, because the decoder is one group of bits ahead, a mismatch or asymmetrical matching can occur. One traditional solution to compensate for this asymmetry has been to add extra bits to the encoded data. Another traditional solution does not create any additional encoded bits, but allows the decoder to read forward into the encoded data bitwise and then backtrack. Both of these traditional solutions present inefficiencies. A more efficient solution is desired to reduce the complexity of encryption and decoding algorithms, reduce the data involved in encoding, transmission, and decoding, and reduce storage requirements. BRIEF DESCRIPTION OF THE INVENTION The present invention is defined in accordance with the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be more fully understood from the comprehensive description presented below and the various embodiments of the invention in the appended drawings, but the invention will be explained more fully by referring to specific embodiments, but only for the purposes of explanation and understanding. Figure 1 shows an embodiment of an encryption and decoding system, a block diagram. Figure 2 shows a mental diagram of an encoding process for generating a bit of information. Figure 3 shows an exemplary data format by which encoded data can be transmitted to the system of Figure 1. Figure 4 shows a block diagram of a structure for arithmetic coding. Figure 5 shows a logic diagram of a structure for coding an action. Figure 6 shows a logic diagram of a structure for a coding/renormalization procedure. Figure 7 shows a logic diagram of a process for applying a set bit procedure to a structure. Figure 8 shows a logic diagram of a process for decoding an action before termination. Figure 9 shows a logic diagram of a process for aligning the process to termination. Figure 10 is a block diagram of an arithmetic decoder. Figure 11 is a block diagram of an arithmetic decoder initialization process. Figure 12 is a block diagram of an arithmetic decoder initialization process. Figure 13 is a block diagram of an arithmetic decoder initialization process. Figure 14A and 143 show equally possible logic diagrams for decoding a binary action. Figures 15A and 15B show an example table for applying a 0xZ estimation research to a slot signal or other binary action before the finalization process. Figures 16A and 168 show an example table for applying a 0xZ estimation research. 17 is a block diagram of an exemplary computer system. DETAILED DESCRIPTION OF THE PRESENT INVENTION. A method and apparatus for encoding and decoding information, particularly video data, is disclosed. During the encoding and decoding process, an indicator (e.g., end of slice) is used to indicate the end of the arithmetically encoded actions. In one embodiment, during the encoding of information, padding information of bits or bytes is added to the bitstream of the encoded data created by a coder. These additional bits, called padding bytes or bits, are added to the end of the encoded data to fill in the middle of the bitstream of the encoded data. Such a padding process can be used to maintain a relationship between a sequence of coded actions, a sequence of blocks of video data (e.g., macroblocks), and the size of the generated information array. In the following description, specific scopes are specified to provide a better explanation of the present invention. However, it will be apparent to one skilled in the art that the present invention can be implemented without these specific scopes. In other cases, well-known structures and devices are shown in block diagrams rather than comprehensively to prevent the use of the present invention. Certain sections of the comprehensive El ... It has been proven appropriate to represent these terms as symbols, characters, terms, numbers or the like. However, it should be noted that all such and similar terms will be associated with corresponding physical quantities and are merely convenient labels applied to those quantities. Unless expressly stated otherwise in the following description, throughout the description, discussions using terms such as "processing" or "programming" or "calculating" or "determining" or "displaying" or the like refer to the action and processes of a computer system or similar electronic programming device that manipulates and converts data represented as physical (electronic) quantities within the records or memories of the computer system, into other data represented in a similar manner as physical quantities within the memories or records of the computer system or other such information storage, transmission or display device. The present invention also relates to apparatus for carrying out the processes herein. Such apparatus may be custom-built for the required purposes or may comprise a general-purpose computer that is selectively activated or reactivated by a computer program stored in the computer. Such a computer program may be stored, for example, on computer-readable storage media such as any type of disk, including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any other type of media suitable for storing electronic instructions. The algorithms and images presented herein are not inherently associated with any particular computer or other apparatus. Various general purpose systems may be used with programs according to the teachings contained herein, or may prove suitable for implementing more specialized apparatus to implement the required method names. The necessary structure for these large number of systems will be evident from the disclosure below. Additionally, the present invention is not disclosed by reference to any particular programming language. It will be understood that various programming languages may be used to implement the teachings of the invention as disclosed herein. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read-only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media, optical storage media, flat memory devices, signals (e.g., waveforms, transistor signals, digital signals, etc.) in electrical, optical, acoustic, or other form, and the like. Encoder and Decoder System Overview Fig. 1 is a block diagram illustrating an embodiment of an encoding and decoding system 100. Referring to Fig. 1, the system 100 includes an encoder (E102) and a decoder 104 communicating along a channel 120. Alternatively, the system 100 may include only the encoder 102 or the decoder 104. The channel 120 may be any suitable data communication channel, including wired and wireless channels, or combinations thereof. Any suitable data communication and modulation schemes may be used on channel 120. An example of system 100 is a system for encoding, decoding, and segmentation of video data, including a sequence of images. In one configuration, each image is divided into one or more slices. The encoder 106 has an input 106 to receive input information, such as input data (e.g., video information). In one configuration, the encoder 102 encodes data using arithmetic encryption. Thus, the encoder 102 may include data storage, manipulation logs, and an arithmetic encryption engine. In one configuration, the code (EEQ1OZ) includes a Range register or R register and a Low register or L register. In a further configuration, the code (EEQ1OZ) includes a probabilistic estimation state machine. The coding algorithm implemented by the code (102) may be a well-known, context-adaptive arithmetic encryption, herein referred to as CABAC. Furthermore, the techniques and structures described here can be extended to other encoding and decoding algorithms. The code (EEQ1OZ) has a switch (108) for providing the encoded data to the channel (120). In one configuration, an encoding action that indicates the termination of arithmetic coded data (e.g., a bit stream of encoded data containing a buffer) includes an end of slot signal. The bit stream may include padding bytes or bits (as further explained below). The decoder 104 has an input 110 to receive the encoded data from channel 120 and a switch 112 to provide the decoded data. In one configuration, the operation of the decoder 104 to decode the encoded data is generally symmetrical with the encoding operation of the encoder 102. The system 100 may include multiple encoders or multiple decoders. The encoder 104 and decoder 104 may be used to process video data, such as video data generated by a video processor (e.g., video codec). In one configuration, a video image is recorded and divided into sample blocks of data, which may represent 16x16, 8x8, or 4x4 samples of the recorded image. The blocks are then transformed by the video processor (e.g., using a differential cosine transform) and quantized to provide integer values representing the sample block. Integer values are converted into a sequence of actions (e.g., binary actions) by the video processor, and the encoded data is sent to the encoding server for processing. Alternatively, the video processor can operate directly on individual samples, including transforming and quantizing the samples and converting the quantized integers specific for the sample into a sequence of actions. Figure 2 is a diagram of an encoding process for generating a bitwise integer. The process is performed by hardware, e.g., The circuit is implemented by processing logic, which may involve processing (e.g., special logic), writing (e.g., running on a general-purpose computer system or a specialized machine), or a combination of both. Referring to Figure Z, the process encodes actions in a sequence of actions to produce logically encoded data (process block 201). The actions may be binary decisions. The actions may be from separate slices. In one configuration, an action indicates the termination of the arithmetic encoding (e.g., an end of slice). The encoded data for all operations in the operation logic is then represented by a bitwise buffering bytes (or bits) (operation logic) (202). The padding bytes (or bits) may be placed after a coded indicator indicating the end of the arithmetic encryption. Figure 3 shows data format (300), which is an example of how encoded data can be transmitted to a system such as the system in Figure 1. The format (300) includes a header (302), an arithmetic code (304), one or more stop bits (306), one or more alignment bits (308), and one or more padding bytes (310). In an alternative configuration, the buffer may be represented by one or more padding bytes (310). bits can be used instead of bytes. As noted above, the system of Figure 1 and the data format of Figure 3 can be used to encode/transmit video information, including data associated with a sequence of images. In one configuration, an image is divided into one or more slices, where a slice contains one or more macro blocks, which are 16x16 pixel arrays. Each slice can be encoded independently of other slices within the image. Image data is encoded in the format shown in Figure 3. In one configuration, header 302 starts with a byte sI-E and contains data encoded using fixed-length or variable-length codesE1 (e.g., Huffman coding). Header 302 may be a slice header. As a slice header, header 302 is a bit sequence generated by an arithmetic encryption engine (Figure 1), which includes a start code (SC) identifying the type of slice data, such as the following, and a code such as an arithmetic code (e.g., A series of trailing alignment bits (0 to 7) follow the stop bits (306) and, in one configuration, padding bytes (310) ensure byte alignment. A series of padding bytes (310) incorporated into the data can be one byte, one byte, or multiple bytes, depending on the number of bytes required to maintain the spacing between blocks (e.g., macroblocks) of video data. Code Flow End Bias In one configuration, the coded data encodes an action (e.g., decision) that indicates the termination of arithmetic coded data to a decoder. The arithmetic coded data is thus terminated by the El Bias slice. The end of an arithmetic coded data can occur when a bit of arithmetic coded data stops and is followed by non-arithmetic coded data. Referring to Figure 3, in one configuration, for each macroblock in a slot, the arithmetic code 204 typically contains the following data: a macroblock mode, an end_of_slice_flag optionally separated by motion vectors and transform coefficients. The end_of_slice_flag allows the decoder 104 (Figure 1) to determine when the last macroblock in a slot has been decoded. This flag is used because the last bit of the arithmetic code contains data that opens multiple macroblocks. The advantages of coding arithmetically coded data can be explained by examining traditional applications. In traditional applications, an arithmetic code is generally completed by one of two alternative means. In a first approach, the entire register (L) is transmitted. In a second approach, an offset is placed on the contents of register (L), and only the most significant bits of register (L) are transmitted. The advantage of the first approach is that the decoder reads exactly the same number of bits as those generated by the encoder. However, this comes at the expense of sending extra bits. In the second approach, bits are recorded, but the decoder reads more bits than were generated by the encoder. This can be achieved by stuffing the decoder with bits. An approach that offers the best of both worlds. The decoder sends more bits than necessary, but the same bits are generated by the encoder. This is allowed by the fact that an action, end_of_slice_flag, is encoded to indicate the end of a slice. Given a well-defined probability assigned to this action, a decoder can decode it, but may subsequently be subject to renormalization if the result of the action indicates the end of the process. In other words, during encoding normally, for each symbol encoded, the value R is multiplied by the probability of obtaining a subrange of values. Renormalization then reduces the value R to a range of values. The renormalization process is known to those skilled in arithmetic encryption techniques. The above renormalization process ensures that the number of bit reads matches the number of bits generated by the encoder. In one configuration, after any renormalization is applied, the probability assigned to an end-of-slice action (or other actions indicating the termination of the arithmetic encryption) is defined by a number assigned to the register (R) during the end of the encoding. In one configuration, to ensure that the encoder and decoder are synchronized for the end of the slice signal, the subrange calculation is not applied by multiplying the probability EIJIZI by the value stored in R. Instead, The subrange is assigned a fixed value or constant. In one configuration, a fixed value of 2 is used. More generally, the value depends on the value of the contents of register (R) before the end_of_slice_flag is encoded. This is completed for the last symbol (bit) set to bit alclg. By setting the subrange to a value of 2, the value 1 can be added to the value of register (L) without affecting the decoding process. This allows all lower register (L) contents to be sent by bit alclg. Since all register (L) contents are sent, no renormalization is required in this case. In one configuration, the least significant bit of register (L) is set to 1 before the contents of L are sent. The least significant bit of register (L) is set to 1 before the contents of L are sent. Setting the least significant bit to 1 is equivalent to adding 1 to L if it is not a literal. In this way, the last bit generated by the arithmetic code is equal to 1, and the last byte containing the arithmetic code has a non-literal value. In effect, the least significant bit of the register (L) becomes a stop bit. Adding Padding Bytes In one configuration, padding bytes are added to the arithmetic code of a slot, followed by a stop bit and one or more alignment bits. Alignment bits are added to any added padding bits. The padding bytes are added to ensure that bytes are added. One of the advantages of placing the padding bytes after the stop bit is that a decoder does not have to decode the padding bytes. Therefore, the decoder decodes the same number of bits of encoded data as the number of padding bytes generated by the encoders. In a structured process, the padding bytes added to the stop bit are called the padding bytes. The number of bits added to the encoding depends on maintaining a relationship between the number of bits of the data blocks. The relationship is further elaborated below. In a configuration, the padding bytes have a specific pattern. The pattern can be unique, such that a decoder can detect that padding bytes II El, a stop bit, and one or more alignment bits are present by identifying bits with this specific pattern, followed by a single padding byte. Once such a detection is established, the decoder does not need to decode the padding bytes II. In a configuration, the decoder includes demultiplexing functionality that prevents the padding bytes II El from being sent to an arithmetic decoding engine in the decoder, similar to the header bits (which are not sent to a decoding engine). In a configuration, the padding bits pattern is a three-byte string (000003 Hex) appended with the bitwise quotient. The first two bytes represent a single word (0000), and the third Byte (03) is defined by the decoder after an end of a slice to identify bytes as padding bytes. In a structured structure, the padding bytes (310) padded at the end of a slice guarantee that the numerical value of the bit counting of the decoding operations is less than or equal to four. With a code like Figure 1 (EGIOZ), EISI can use a register (C) to count or otherwise keep track of the ratio of actions (decoding operations) to bits (or bytes). Each time an action is processed, the counter (C) is incremented by 1, and each time a bit is generated, the counter (C) is incremented by 4 (or each generated bit). In a structure, the counter takes into account all the bits in the slice (or other action set), including the header and trailing stop and alignment bits. In a structure, the decoding operations for the end_0f_slice_flag action must be counted with counter(C) (although in an alternative implementation they could be counted). However, it is known that such an action exists in the macroblock and that the count of such actions is well correlated with the image size. In this case, the counting of the end_0f_slice_flag actions is equivalent to counting (in this way, the macroblock C is incremented by 1), but at the same time, C is counted at every 256 pixels (macroblock (press. once) is decremented by 1. Alternatively, C can be decremented by any value for each macroblock. In a building, the padding bytes described here guarantee a minimum length for the encoded slice. Compared to the traditional technique of adding padding bits in the middle of a coded slice, this improvement simplifies the process of encoding data, particularly how much data to encode. The sequence of actions can be divided into segments or blocks of input data represented in the sequence of actions as a function of the number of information bits in the sequence of information bits. For example, the decrement operation can take the form of a linear combination: e, the action represented in the sequence of information bits (or other elements) count-B B represents a counter that is decremented by an array of bits of information (or other elements) in the sequence of bits of information (e.g., macro blocks El) represented in the sequence of segments (e.g., macro blocks El) and [3 represents a counter that is decremented by an array of bits of information generated and a count of the actions of the sequence of segments processed. The values for a and ß are typically provided to a controller of an arithmetic code, and the derivative of ß and ß will be decomposed as follows. The value of oc can represent a counter that is decremented by an array of bits of information (e.g., macro blocks El) after the processing of a block of data is completed, for example. The value of ß can represent a counter that is decremented by an array of bits of information (e.g., macro blocks El) after the processing of a segment is completed. Alternatively, the value of ß can represent a counter that is decremented by an array of bits of information generated and a count of the actions of the sequence of segments processed. Initially, or as will be understood by those skilled in the art, a counter can be decremented by its value at any other time during the processing of a block of data. Since the total block count (EJS) and B value are known, the product [3 x 5] can be calculated as the action count (e) for the sequence of actions after processing blocks of input data (e.g., macro blocks). For example, when a counter is used to calculate the action count (e) for the generated bit counts, the counter can first be decremented by a value of β x 5 and then decremented by a value of β for each generated bit of information, while the counter is incremented by "1" for each action of the sequence of actions processed by the entropy coder. The ß value can typically be any value in the range of 1 to 100 and can be determined as follows. The oc value can typically be any value in the range of 1 to 10 and can be determined as follows. In some cases, the number of blocks of input data to be processed is not known in advance, for example, where the medium is limited to the number of bits of information that can be provided in the information stream. This might occur, for example, where the information stream is transmitted over the Internet as an Internet Protocol (IP) packet, where the IP packet has a maximum size. In these cases, depending on the complexity of a particular image, one or more sequences of bits of information may be required to represent a single image of the input data. However, the maximum number of bits of information that can be provided in a sequence of bits of information is Since the number of processed segments of the input data to be processed may not be known in advance, the number of blocks used to form a sequence of information bits may not be known in advance. Where the number of input data segments to be processed is not known in advance, the controller can take into account sequences of actions by coding one or more blocks representing a particular sequence of actions. For example, where a counterEl is used to personalize the action countEl sensitive to the generated bit count, the counter can be decremented by a value of 3 for each block processed and decremented by a value of 0 for each information bit generated, while the counter can be incremented by 1 for each action of the sequence of actions processed by the entropy coder. The values of On and B are calculated according to one or more of the above-mentioned blocks. In a system design involving encoding, the values of a and b may be determined in advance and provided to the controller. Alternatively, or additionally, the values of c and b may be determined by the controller or any other component of the encoder according to one or more of the configurations described above or as encoded/array values. Where the controller determines the values for a and b using one or both configurations imposed by the standard or by a decoding device, information about one or more configurations may be stored in a memory of the controller (not shown) and is available to the controller in determining the values of a and b. Additionally, or alternatively, information about the configurations may be stored in an external memory (i.e., a Digital Video Disc (DVD)), a DVD The information may be provided to the controller by means of a specific external device, such as a playback device, or by a systems engineer performing specific functions, such as encoding specific input data. In the latter case, the systems engineer may enter information on a console or other input device (not shown), or otherwise specify information regarding the conventions imposed as a result of an encoding standard and/or a decoding device, as will be appreciated by one skilled in the art. In addition, when values of α and β are detected, considerations can be made as to whether the complexity of the β and β values is too low, for example, whether the values of β and/or β are too low. A high padding bit at the end of a sequence of information bits is proportional to the extent that the sequence of information bits is approximated or A count of padding bytes (or bits) greater than %Z may show this to be very inconsistent. One skilled in the art may be able to indicate a higher padding bit ratio considering other ratios, e.g., the particular standard and/or codec available. For example, if the values 01 and 3 are found to be very small, the values of on and B can be increased to reduce the likelihood of padding bytes being added (in other words, to reduce the likelihood of a penalty being incurred in the encoded information sequence). Considerations can be created based on the impact of the mixed-case relationships on the decoder that will be used to decode the encoded information sequence. Such considerations may include the cost of implementing the decoder. If the mixed-case relationship is very high, more processing power may be required in the decoder. An increase in the required processing power can likely lead to higher implementation costs. In a structure, it is stated that changes to or and ß can be generated after the data from each macroblock is encoded. The values of or and ß can be determined experimentally using linear regression techniques. A sequence of actions, each representing an S segment, can be encoded without any complex coding. For each action sequence (2), the number of information bits (B(z)) generated for the action number (e(z)) is counted. Using linear regression, a line (e+c*B+d) can be determined that approximates the data pairs (e(z), B(2)). An initial value of a and/or ß can be increased to reduce and potentially minimize the number of date pairs ((e(z),B(z))) found up-a line (e: d*B + ß*S). Among the various techniques described above, one or more of them can account for a value of ;t (i.e., a counter is decremented by the value of ;or) for each bit of information generated by the code, using values 0( and ;5), as determined by the user, and can account for a value of ;3 (i.e., a counter is decremented by the value of ;b) after the completion of a segment of input data. For example, where the values OL and B are integer values, such an account (i.e., a counter is decremented by the value of ;b) can be completed directly. For example, where one or both of the values ß and ;3 are fractional values, a common denominator can be used to provide non-fractional values of ;t and ;b. In this case, new, non-fractional values of θ and θ can be taken into account, such as by decrementing/exceeding a counter by the values 0( and B after the information bit is generated and the segment operation is completed. The common denominator, for example, the common denominator Ei, can be taken into account by adding it to the counter value after processing each action of the action sequence. For example, where the values o and [3 are determined to be 4/3 and 25, a common denominator can be determined to be 3. The non-fractional values (x and [3) can be determined to be 4 and 75 using the middle denominator. In this way, a counter, a and [3 Where used to account for their values, the counter can be decremented by 4 for each bit of information generated, decremented by 75 after processing of each segment is completed, and incremented by 3 for each action processed. Exemplary Coding Processing Figure 4 shows a block diagram of an arithmetic code structure. Referring to Figure 4, the arithmetic code EEQ400 includes a sequencer 405, a probability estimator 410, and a coding engine 415, each of which is connected together. One or more input data lines 420, code 400, a sequence of actions 425 (e.g., a sequence of binary actions) The sequence of actions is processed by the encoder 400 to generate a sequence of information as described below. In one configuration, the sequence of information is a sequence consisting of at least one information element (e.g., bit). In one configuration, the number of information bits in the sequence is less than the number of actions in the action sequence. The sequence 430 provides an output port for sending the sequence 435 to the encoder 400. The sequence of bits in the sequence includes one or more bits having a value of "0" or "1." After receiving the sequence of actions 425, the sequencer 405 then assigns the actions 425 to the probability estimator. 410 and transmits it to the encoding engine 415. For each binary action of the action sequence 425, the serializer 405 uses the context information of the binary action to generate a probability estimate (P(A)), which is transmitted to the encoding engine 415. In one configuration, the probability estimator 410 sends a number of probability estimates to the encoding engine 415, and the encoding engine 415 selects one of the possible estimates based on the R value. Alternatively, the R value can be sent to the probability estimator 410, which uses it to select a probability estimate to be sent. The probability estimator 410 uses the R value to generate the binary action. The encoding engine 415 updates its internal condition depending on the value of the action. The encoding engine 415 generates 0 or more information bits using the given binary action and the associated probability estimate (P(A)). In one configuration, the encoding engine 415 encodes an action indicating a termination of arithmetically coded data. The action is an end of slot signal or a sequence of non-arithmetically coded data. In generating one or more information bits, the encoding engine 415 uses various registers, including an interval register (465), a low register (470), a distinguished register (475), and a counter register (480). To implement arithmetic encoding, the The code(400) operation is well known in the art. In one configuration, code(400) associates a relationship of actions to bits of information denoted elsewhere. Code(400) implements this operation by additionally adding padding bytes (or bits) to the sequence of information denoted here, as shown in Figure 5. Figure 5 shows a logic diagram for a configuration for encoding an action. The process is implemented by processing logic, which may involve hardware, e.g., circuitry, specialized logic, or the like, software (e.g., running on a general-purpose computer system or a specialized machine), or a combination of both. Inputs to the arithmetic encryption process are represented by the content ID (content ID) that identifies the content and the code. are the decoded binary operations, and the values R, L, and n are the bits resulting from the encoding. In one configuration, the encoding is symmetrical with the decoding process, and as shown above, the state of the arithmetic encryption engine is represented by the value of L, which points to the lower end of the subrange EL, and the value of R, which points to the corresponding range of the subrange E. In one configuration, the encoding process is started only after the encoding engine has been started. In one configuration, the starting operation is done by sending the value L equal to lele and the value R equal to 0x01FE, setting the first bit flag to one, the value of the bits distinguished (BO) and the counters significant (C) equal to sm The first bit signal, code-lEl, is used during coding to indicate that a bit procedure has been performed for the first time. The counter stores a value indicating the coded action count-@. Referring to Figure 5, the process begins coding a single action (e.g., bit) by deriving the RLps value as follows (process block 501). In one implementation, the processing logic derives the RLps variable by setting the R index (or Ridx) equal to the R value, shifting the submotion to the right and ANDed say-El with 3 Hex. The processing logic then calculates the RLps value using the RidX value and the status value of the current context associated with the context, as shown in Figure 16A. The ZJ estimation station then accesses the machine table and sets the R value equal to a determined value. The R value is then set to the current R value minus RLps. After calculating the MPS numbered subrange, the transaction logic checks whether the encoded binary action value is equal to the MPS value (transaction block 502). If the binary action value is equal to the MPS, the transaction logic takes the MPS path and updates the transaction block 503, where the transaction logic passes the state machine to the next state shown in the state machine for the content, using the table and transaction block 508 in Figure 168. The transaction logic checks whether the encoded binary action is equal to the MPS value. In case of non-determination, the transaction logic takes the LPS path (504) and the transaction logicEl passes to the transaction block (504) where it sets the L value equal to the L value plus the R value equal to the RLps value. From there, the transaction logic determines whether the status of the specific content is equal to sm (505). In one configuration, the sfEl state is a state that corresponds to a 50/50 probability Eg. Alternatively, the sfEl state is a state that corresponds to another probability, such as a state with a 50/50 probability approximation. If the content state is not equal to sm, the transaction logic switches to transaction block (507). If the content state is equal to sm, the transaction logic changes the mean of the MPS (transaction block (506)) and passes the transaction to block (507), and the transaction logic updates the content state count to the next state using the table in Figure 16B (transaction block (507)). After applying transaction blocks (507 and 503), the transaction logic switches to transaction block (508), where it applies the renormalization procedure as in Figure 6. The transaction logic increments the transaction counter by 1 (transaction block (509)) and the transaction terminates. Figure 6 is a structured logic scheme of a coded renormalization procedure. The process is implemented by processing logic, which may include hardware (e.g., circuitry, specialized logic, etc.), software (e.g., running on a general purpose computer system or a specialized machine), or a combination of both. Referring to Figure 6, the process tests whether the logic value is less than 100 Hex (process block 601). If not, the process is completed. If so, the process transitions to the transaction block (602) where the transaction logicEl tests whether the value of L is less than 100 Hex. If so, the transaction block transitions to the transaction block (603) where a bit procedure is applied with parameter 0 and from there, the process transitions to the transaction block (608). If the transaction logicEl is greater than/or equal to 100 Hex, the transaction logicEl tests whether the value of L is greater than 200 Hex. If this is not the case, the transaction logic sets the L value, 100 Hex, to the result of subtracting the L value from the L value and increments the distinguished bit (BO) value by one with parameter 1. This is done in transaction block (605) and the transaction passes to transaction block (608). If the L value is greater than/equal to 200 Hex, the transaction logic sets the L value, 200 Hex, to the result of subtracting the L value from the L value and passes to transaction block (606). The transaction block (607) and passes to transaction block (608) to process block (609) and the transaction logic sets the R value, The bit procedure is implemented by processing logic, which can involve hardware (e.g., circuitry, special logic, etc.), software (e.g., running on a general-purpose computer system or a special machine), or a combination of both. Referring to Figure 7, the logic operation first checks whether the first bit signal is equal to or equal to (operation block 701). If the first bit flag is set to 1, the transaction sets the first bit flag equal to 1 (transaction block (702)) and the transaction passes to transaction block (704). Otherwise, the transaction sends a bit with the value of logically exclusive bits (BO) (transaction block (703)) and passes to transaction block (704). In transaction block (704), the transaction tests whether the value of the logically exclusive bits (BO) is greater than 1. If not, the transaction terminates. If so, the transaction sends a bit with the value of logically exclusive bits (BO) and decrements the BO value by one (transaction block (705)). From here, the operation moves to the logic operation block 704. Figure 8 is a schematic diagram of a process for decoding an action before terminating. This process can be used to encode any other binary action that signals the end of the slice, as well as the termination of the arithmetic encryption. The process is implemented by logic operation, which can involve hardware (e.g., circuitry, custom logic, and the like), software (e.g., running on a general purpose computer system or a dedicated machine), or a combination of both. Referring to Figure 8, the operation logic first decrements the value of R by 2 (Figure 8). Then, the transaction logic tests whether the coded binary action value is equal to s m (transaction block (802)). If the action is equal to s m , the transaction logic applies a renormalization procedure as shown in Figure 6 (transaction block (803)) and the transaction passes to transaction block (806). If the binary action value to be coded is not equal to s m , the transaction logic sets the value of s L to the result of adding the value of R (transaction block (804)), applies a coding procedure (transaction block (805)) and passes to transaction block (806). In transaction block (806)), the transaction logic increments the action counter by 1 and the coding process is completed. As can be seen from the above process, in a structure, when the binary action value is equal to 1, the arithmetic encryption is terminated and the alignment procedure is applied after the action is encoded. In such a structure, the last bit written includes a stop bit equal to 1. Figure 9 shows a logic diagram of a process for alignment in the terminating Elna process. The process is implemented by logic processing, which may involve hardware (e.g., circuitry, specialized logic, etc.), software (such as running on a general purpose computer system or a specialized machine), or a combination of both. Referring to Figure 9, the process logic first sets the value of R to 2 (Explanation block 901). The process logic then applies a renormalization procedure such as the renormalization procedure shown in Figure 6 (Explanation block 902). The process logic then applies the insert bit procedure shown in Figure 7, which ANDs the value of 1 Hex and a value equal to the value of L, which is shifted to the right nine places (Explanation block 903). Applying the ANDing operation on the contents of the register value L, the results are generated using the bit procedure set in the three-tenth bit position (counting from the last significant bit) and then sent. Finally, the operation sends the two logical bits to the L register, shifted seven places to the right, equal to the ANDed value with a value of 3 Hex, and then equal to the ORed value with a value of 1 Hex (operation block 904). An ORing operation with a Hex value of 1 is applied to add the stop bit. Illustrative Decoder Operation Figure 10 includes a decoding engine 1015 connected together as a block diagram of an arithmetic decoder 1000. An input 1020 provides a port to the decoder 1000 for an index of interest 1025 (e.g., an array of binary bits). The binary bits of the index 1025 can have a value of "0" or "1". In one configuration, the decoder 1000 processes the array of information to form an action sequence 1035. The generated sequence of actions is a sequence of actions containing multiple actions (e.g., binary actions) that may have values other than single bit values. The action sequence is provided to the decoder 1000 via a sequence of bits 1030 containing at least one bit. After the information sequence 1025 is read, the serializer 1005 passes one or more bits to the decoding engine 1015. The decoder 1000 iteratively generates one or more actions of the action sequence as follows. For each action, the serializer 1005 passes a related content to the probabilistic estimator 1010. Depending on the value of the received content, the probability estimator 1010 generates a corresponding probability estimate (P(A)), which is sent to the decoding engine 1015 and used in the decoding engine 1015 to generate the action. In one configuration, the probability estimator 1010 sends a plurality of probability estimates to the decoding engine 1015, and the decoding engine 1015 selects one of the probable estimates based on the value of R. Alternatively, the value of R can be sent to the probability estimator 1010, which uses it to select an event estimate to be sent. The probability estimator (1010) updates its internal state depending on the value of the binary action received from the decoding engine (1015). The decoding engine (1005) then consumes the extra bits of information, which are either zero or zero, of each binary action generated. The serializer (1005) then uses various registers, including the decoding register (1070), to generate the actions of the action sequence (1035) from the information sequence. The operation of the decoder (1000) is illustrated in the diagram below. The diagrams below illustrate the decoding operations performed in a slice by a configuration of a decoder such as decoder (1000). In a configuration, the decoder decodes a content The decoding process is performed according to the schematics shown in Figures 12, 14A, 14B, 15A, or ISB, depending on the value. The processes shown can be incorporated into other processes, modified, or otherwise adapted to take advantage of the improvements made herein. In one configuration, the decoder reads one byte at a time. In an alternative configuration, the decoder reads one bit at a time. Figure 11 is a schematic diagram of an arithmetic decoder initiation process. The process is performed by processing the logic, which may involve hardware (e.g., circuitry, special logic, etc.), software (e.g., running on a general-purpose computer system or a specialized machine), or a combination of both. Referring to Figure 11, the process begins with transaction logic (transaction block (1101)), which sets the interval R to a predetermined number (transaction block (1101)). In one configuration, after the predetermined number 0xff00 is initialized, the transaction logic reads two bytes of data from the buffer (V) (transaction block (1002)). In one configuration, buffer(V) stores the buffer(V) bits one byte at a time. In one configuration, buffer(V) can be implemented to store the buffer(V) bits one bit at a time, but the constants used in the process described here would need to be modified accordingly. More specifically, as shown, the operation logically reads in a byte, shifts it 8 places to the left, and then adds it to another byte, which is added to the register (V), using an arithmetic (OR) operation. When the data is read into register (V), the operation logically sets the value of register (B) to a predetermined value. Register (B) indicates the number of extra bits in register (V) available for operation. When the value of register (B) is less than 0, another byte of data must be shifted. In one configuration, the predetermined value is 7. Figure 12 is a schematic diagram of a process for decoding a binary action. The process is implemented by processing logic, which may include hardware (e.g., circuitry, specialized logic, etc.), software (e.g., running on a general-purpose computer system or a specialized machine), or a combination of both. Referring to Figure 12, the process begins by calculating the size of the LPS interval (e.g., Operation block 1202). In one configuration, this calculation is implemented by a multiplier. The multiplier can be approximated using a state-dependent scan step associated with the content (CTX). In one configuration, a finite state machine is used to indicate which possible E is connected to the machine state. For later scanning, the state value and the two most significant R bits are used after the most significant R bit. A table for the implementation of the scanning operation is shown in Figure 16A. An exemplary method for creating the table is presented below. The result of the table scan is recorded by this application, since it reads bytes at a time instead of bits. The result of the table scan is calculated by taking the value of the LPS subrange (R) of the reserved transaction block (Rlps) and calculating the subrange of the MPS. The logic sets the R value to be equal to the result of the calculation. After calculating the subrange of the MPS, the logic determines whether the value of the MPS stored in the register (R) is greater than or equal to the value of the MPS. The current bit being processed is called the LPS subinterval, operation block 1203. Otherwise, the operation logic takes the MPS path, and the operation logic passes to operation block 1204, where the decoded value (i.e., the returned result) (5) is set equal to the value assigned to the MPS for the specific context and updates the Figure state machine. In a structured manner, for an MPS, the state machine update increments the state in the state table by one. If the transaction logic determines that the value (V) is greater than or equal to the value in the register (R), the transaction logic takes the LPS path and moves to transaction block 1205, where the result (S) is set equal to the LPS (not MPS) for the specific content (CTX) and the interval value R is set equal to the result of the binary action from the current value V. The transaction block 1205, primarily the RLPS, determines whether the status of the content of the binary action is siEl (transaction block 1206). In one configuration, state 0 is a state that corresponds to a 50/50 probability. Alternatively, state 11 is a state that corresponds to another probability, such as a near 50/50 probability. If this does not happen, the transaction transitions to transaction block 1208. If this does not happen, the transaction logic changes the meaning of the MPS (transaction block 1207). From there, the context is updated to the next state (transaction block 1208) using the table in Figure 168, and the transaction logic applies a renormalization procedure that unfolds further down the transaction block (transaction block 1209). Figure 13 illustrates a renormalization procedure implemented by processing logic, which may involve hardware (e.g., circuitry, specialized logic, and the like), software (such as running on a general-purpose handheld computer system or a specialized machine), or a combination of both. Referring to Figure 13, the process begins with the processing logic that tests whether R is less than 8000 Hex (process block 1301). If R is greater than or equal to 8000 Hex, the renormalization process terminates. Otherwise, the processing logic doubles the values of R and V (process block 1302). In one structure, the operation logic doubles the values of R and V by shifting the bits IZIR and V one position to the left. The value of B is decremented, ensuring that one less bit is available for the operation. The operation logic then checks whether the value of B is less than 0 (operation block 1303). If not, the operation moves to operation block 1301 and the process is repeated. If the value of B is less than 0, the operation concludes by setting the value of B to 7 and bringing in another byte to be processed. Logically, the operation registers the value of B to be set to 7 and another byte is brought in. (V) moves to transaction block 1304, where the ORed value is fetched with its current contents. From here, the transaction moves to transaction block 1301, and the process is repeated. Figures 14A and 148 show reasonable diagrams for decoding equally likely binary actions. Figure 14A can be used when the register (V) size is greater than 16 bits, while Figure 14B can be used when the register (V) size is 16 bits. These implementations can be used when fetching one byte at a time. The process is hardwareE.g. circuit, special logic, and so on), or a combination of both. These processes can be used where the probability of a positive or a negative value occurring is rarely the same. For example, coefficients can be used when a sign value is being processed. Instead of predicting whether it will be positive or negative, fixed estimates are used that define a probability of 0 to 50/50. In this way, there is no need to perform a table scan with a probability multiplied by R. Note that this does not affect the final calculation. Referring to Figure 14A, the process begins with the operation logic (operation logic (1401)), which doubles the value of V and decrements the value of B by 1. The doubling of the value of V can be implemented by shifting the V bits one position to the left. The operation logic then checks whether the B value is less than 0 (operation block (1402)). If not, the process moves to operation block (1404). If the B value is less than 0, the process proceeds to the operation block (1404), where the B value is set to 7 and another byte is brought in to be processed, and the mantilla is entered. (V) moves to the transaction block (1403) where the ORed value is fetched with its current contents. In the transaction block (1404), the transaction logic tests whether the V value is greater than or equal to the R value. If so, the transaction logic sets the result (5) to 1 and sets the V value to the result that the R value is subtracted from the V value. (Transaction block (1405)) and the process terminates. If not, the transaction logic sets the result (S) to 0 (Transaction block (1406)) and the process terminates. Referring to Figure 14B, the process begins with the operation logic (1411) which sets V' equal to V', doubles V', and decrements B' by 1. The doubling of V' can be implemented by shifting the N bits one position to the left. The operation logic then checks whether B' is less than 0 (operation block 1412). If not, the process moves to operation block 1414. If B' is less than 0, the process returns B', where B' is set to 7, and another byte is fetched to be processed, and, logically, the register. (V) moves to transaction block (1413) where the ORed value is fetched with its current contents. In transaction block (1414), the transaction logic tests whether the value of V is greater than or equal to the value of R or whether the value of V is greater than or equal to 8000 Hex. If so, the transaction logic sets the result of S to 1 (El) and sets the value of V to the result of R being subtracted from V (transaction block (915)) and the process terminates. If not, the transaction logic sets the result of S to 0 (El) and the process terminates. Figure 15A is a schematic diagram for decoding coded actions that indicate the termination of an arithmetic encryption. Such an action may include an end of a slice signal. Syntax based on the end of a slice signal can be used to indicate to a decoder the presence of an end of a slice signal. In a structure, this process is performed for each macroblock, but only for the last macroblock in the slice is the result that continues to indicate the end of a slice (e.g., sending a result of 1). The termination of an arithmetic encryption (a decoder) is A signaling action can be used when data continues to follow bitwise arithmetic encoding in an encoding technique other than arithmetic encoding. Note that additional arithmetic encoded data can follow this signaling data or data encoded by a non-arithmetic encoding technique. Thus, the signaling action can be used in situations where non-arithmetic encodings are interspersed with arithmetic encoded data. The process is performed by the hardware, e.g. The circuit is implemented by processing logic, which may include special logic, software (such as when running on a general-purpose computer system or a specialized machine), or a combination of both. Referring to Figure 15A, the operation logic tests whether the value of V is less than 100 Hex (operation logic:1501)), indicating that the last macro block in the slice has been reached. If so, the operation logic sets the result (S) representing the decoded symbol to 1 (operation logic:1502)), and the decoding process of the slice ends. If this is not the case, the logic sets the result of the pair (S) to 0, sets the value of R to the result of subtracting the value of 100 Hex from the value of R, and sets the value of V to the result of subtracting the value of 100 Hex from the value of V (logic:1503)). The logic applies the renormalization procedure of Figure 3 (logic block (1504)) and the process terminates. In a structured manner, the convention between MP5 and LPS can be changed. Figure 158 is a logic diagram for a process for coding an action before termination when a convention between MP5 and LPS is changed. The process can be implemented by logic processing, which can include hardware (e.g., circuitry, specialized logic, and so on), software (e.g., running on a general purpose computer system or a specialized machine), or a combination of both. Referring to Figure 15B, the process logic begins by subtracting 100 Hex from the value R (process block 1511). The process logic tests whether the value R is greater than or equal to the value R (process block 1512). In this case, the transaction logic sets the decoded result (S) representing the decoded symbol to one (transaction block 1513)) and the decoding process for decoding the action before the termination transaction terminates. In this way, no renormalization is applied. In this case, the transaction logic sets the decoded result (S) to one (transaction block 1514)) and applies the renormalization procedure of Figure 13 (transaction block 1515)) and the process terminates. Construction of a State Machine for Probability Estimation: An exemplary process for construction of a state machine in Figure 16A and 16A is presented in the following C code. float prob64[N]; int next_state_MPS_64[N]; int next_state_LPS_64[N]; int switch_MPS_64[N]; int qLPS[N][4]; alpha = pow(Pmin/Pmax,L.O/(N-l)); next_state_MPS_64[i] = (i==N-l)? N-1:i+1; q = q/prob64[i]; q = -log(q)/Log(alpha); k : (int)(sum); next_state_LPS_64[i] = (i-k RTAB[i][j] = (int)(ONE/8*prob64[i]/log((j+5.0)/(j+4.0))+0.5); if (j == 0 && RTAB[i][j] ONE/4) RTAB[i][j] = ONE/4; In the above two codes, N represents the number of states in a state machine. In a configuration, the state machine is symmetric and the total number of states is EJZ*N (128 in this example). A state can be represented by two variables: the state (a number between 0 and N-1 inclusive) and an MPS flag (which indicates whether 0 or 1 is the MPS). In a configuration, the state represents the number of states in a higher state machine, the LPS. The state machine is organized as follows: (a) if an LPS is observed, then p(LPS) <-- p(LPS) * alpha (b) otherwise p(LPS) <-- p(LPS) * alpha + (1-alpha) where alpha is an adaptation rate. Alpha is typically in the range of 0.9 to 1 but can extend to other ranges or be in other ranges depending on the desired adaptation. In the above code, alpha is defined as 0.01875 (Pmin), which is defined as an LPS probability for state (N-1). 0.5 (Pmax), which is defined as an LPS probability for state (0). 1.0/63 is defined as an LPS probability for state (N-1). Consider the following (number 1 along N-1). The array named prob64 contains the float points representing an LPS probability associated with each state. Prob64[i] is set to state Pmax*pow(a|pha,i). Prob64[0] is equal to Pmax and Prob64[N-1] is equal to Pmin. Next_state_MPS_64[i] defines the state transition after an MPS observation. If i differs from N-1, the state is incremented by 1. Otherwise, the state remains unchanged. By giving the combination of Prob64[i] and Next_state_MPS_64[i], part of the update procedure described above can be well approximated. For the update procedure described above, Next_state_LPS_64[i] is i-(- value is an integer and is not an integer. In one configuration, the value is rounded to the nearest integer. However, in an alternative configuration, rounding up and For better balance with rounding, a variable sum is used such that the difference included by rounding is approximately 533 on average. The value RTAB[i][]'] is calculated to approximate R*prob64[i]. The variable (j) represents the expected value of R given R as (ONE*4)/8, /8 - 1, 319, and so on. The calculation of (ONE/8)/I0g((j+5)/(j+4)) represents the expected value of R. For better applications, it is desirable to guarantee that at most one renormalization iteration occurs with an MPS coding. Consequently, RTAB[i][0] is associated with ONE/4. Therefore, Because R cannot be less than ONE/4 before renormalization. More generally, in a structure, RTAB[i][j] is called (ONE/4)+(ONE/8)*j, but this does not occur for ∈0 in the present example. Thus, using the technique explained above, the state tables of Figures 16A and 16B can be constructed by excluding a state in a structure. In Figure 16A, the state is state (63). In this way, the state does not change whether an LPS occurs or an MPS occurs. The remaining Figure is Example Structures in the Source Code. The sample codes in C are given in the source code and a A sample decoder is presented below. These methods can be implemented using any suitable processing device for encoding and decoding data (e.g., video data). In some cases, the process can be implemented with a combination of hardware or software elements. Other implementations can be created. The functions for encoding and decoding are presented in the following C form: void starc_enccde() { encodeusiice_headert; while (lbyte_aligned) send_bit(0); 3 = Üxlfe; void finish_encode() { renorm_encodc(; bit_pius_follow(lL » 9) & li: send_bit((L › 8) &ll;sand_bit(1); !f 5L0p_bit whili (Ebyto_allgned(l) send_bitlû); if aliqnment_bit void biL_plusHfollowlint b) [ sind_bit(b): send_bic[lb}: void encodc_renorm() { while [!( R&0x100) ( bit_plus_follcw(0): else ;5 (L ›= OxZOD) ( bit_p.us_(ollow(i); L -i OXBOD; 304%; void encode_event(int ccx. int b) ( rLPS v table[statc[ctx!][( R»6)-4]; ii (b == H? S[stato[ctx]]) statelctx] - nexc_state_MPS[statalctx}J; L 6: R: H25[state[ctx]] - ! MPS[state[ctx]J; atncolctxl i nixt_stati_LPs[state[CCX]1; encode_renorm(): void encodeuequiprob_event[in: b› { if (L+R 4 ûxâoû) bit_plus_follow(0): else i! &L = 0x400) { bit_p1us_follow(i); 80+6; void encode_end_of_slice_flag(int bi ( encode_renormt)r Decoder (bavt based): void start_decode() { decode_slici_hiader{)z while {! byte_aliqned()› got_bi:l); R= Oxtlßo; V - get_bytel) « 3: v |i get_byte(ls void finiih_dccode(› [ while (more_bytea_iu_elicel)) get_bytif); f/ stuffing bytu void deccde_renorm() ( while (R<0x8000) { v Ir get_bytet); int decode_equiprob(l ( V |= aet_hy:e(l: return bit; int decode_evcntiint Ctx] ( stattlctxl = next_state_KPS[statelctx]l; bit i HPS[5:a:o[ctx]1; bi: - ! MPS{sta:eich]l; V -1 R; E i rLPS; if (ntatalctxl == Be Mpststatelctxll i ! MPslstntatctx]I; nax:_srata_LPs[state[ctxî]; decode_renormi); return bi:: in: dec0d0_cnd_of_slice_flagIk l 1& (v < 0x100) decode_renorn(); return bit; MPS/LPS convention deg/'stiriîd/ginde usage/anma Direction/ik language/m decoding a/temaüfbyt base/@cu int dccode_ind_o{_siico_tLag(i( decode_ren0rm(l; xcturn bit: . Decoder (bitwise): void atart_dccoéo() { decode_slicu_headerll: while l! byte_nligned()î aet_bit(i; E I Oxlfi: for {i=0; i<9; i++) ign V = (V«1) | void finish_decode() { while (5byte_aligned()) get_bit{); // alignement bit While (more_bytes_in_slice()) get4byte(); // stuffing byte int decode_renorm(} { while (R V : (V«1}|get_bit(); int decode_equiprob(} { v = (V«l) | get_bit(}; return bit; int decode_event(int Ctx) { rLPS = table[state[ctx]][(R»6)~4]; state[ctx] = next_state_MPS[state[ctx]]; bit = IMPS[state[ctx]]; if (stateEctxJ == 0) state[ctx] = next_state_LPS[state[ctx]]; decoda_end_of_slice_flag(} [ 0130 { decodi`rinorw(i; return bit; The MPS/LPT convention is not used in: decode_end_of_slice_flag(1( dccoda_rinorw(î: return bit: Note that the arithmetic code above has a range divided into two, an upper range and an lower range. One of the ranges represents an MPS and the other represents an LPS. In one configuration, the assignment of MPS and LPS to ranges results in a 1 being assigned to one range and a 0 being assigned to the other In the above source code, the range end_of_slice_flag is assigned to the upper and lower range, MP5 (value 0). It is also possible to assign MPS to lower ranges. The following code shows another example code. Note that the code specifies the minimum number of bytes in the slice to be used to connect the upper and lower ranges of the open-ended relationship. In the above code, the first byte of the header is sent to a NAL unit to indicate the type of data being used. The NAL unit and its usefulness are well known in the art. The RBSP_to_EBSP() function allows the called data to be added to the bitwise data. More preferably, in a configuration, a sequence of 03 Hex, a predetermined number of bits, can be used as resynchronization markers after the 0000 Hex bytes, preventing bit recognition. When the 000003 Hex pattern is encountered by a decoder, a reverse procedure is used to recognize the "03" bit. Although the codecs and decoders described herein are capable of encoding and decoding such useful video data, a person skilled in the art will understand that the codecs and decoders described herein are capable of encoding and decoding a sequence of information in the case of a sequence of actions, such a sequence of information is not decoded in the case of a decoder. It will be understood that the previous explanation of coding involves processing a sequence of actions containing multiple binary actions into a sequence of information containing at least one bit, and that for the decoder, a sequence of information containing at least one bit into a sequence of actions containing multiple binary actions. However, as will be appreciated by a person skilled in the art, the coding/decoding can be performed using the teachings explained herein, operating on sequences of actions and information directories consisting of M-ary actions (in other words, each M-ary action represents multiple bits of data). An Exemplary Computer System Figure 17 is a block diagram of an exemplary computer system capable of executing one or more of the operations explained herein. These blocks, or a subset of these blocks, e.g., Note that the computer system 1700 can be integrated into a device such as a cellular phone to implement the techniques described. Referring to Figure 17, the computer system 1700 includes a communication mechanism 1711 for transmitting information and a processor 1712 coupled to the data bus 1711 for processing information. The processor 1712 includes a microprocessor, such as a Pentium™, PowerPC™, Alpha™, and the like, which may be used interchangeably. The system (or other dynamic storage device 1704) coupled to the data bus 1711 for storing information contains instructions to be executed by the processor 1712 (referred to as main memory). Main memory 1704 is separated from the processor 1712 and contains temporary storage devices for executing instructions on the processor side. The computer system includes another static storage device (1706) coupled to the data bus (1711) for storing static information and instructions, and a data storage device (1707), such as a magnetic disk or optical disk and associated disk drive. The data storage device (1707) is coupled to the data bus (1711) for storing information and instructions. The computer system (1700) may also include a display device (1721), such as a computer, for displaying information. An alphanumeric input device (1722), including alphanumeric and other keys, may be coupled to the data bus (1711) for transmitting information and sending commands to the processor (1712). An additional device (1707) may also include a display device (1721) for transmitting information and sending commands to the processor (1712). A cursor control 1723, such as a mouse, trackball, touchpad, needle, or cursor direction switches, is coupled to the data bus 1711 for commanding selections to the processor 1712 and controlling cursor movement on the display 1721. Another device that may be coupled to the data bus 1711 is a software device 1724 that can be used to print instructions, data, or other information on a medium such as paper, film, or similar media types. Furthermore, a sound recording and playback device, such as a speaker and/or microphone, may optionally be coupled to the data bus 1711 for audio interfaced with the computer system 1700. Another device that may be coupled to the data bus 1711 is a telephone, a handheld radio device, or a device capable of transmitting to another device. is the wired/wireless communication capability 1725. Note that any or all components of system 1700 and associated hardware may be used in the present invention. However, it should be appreciated that other configurations of the computer system may incorporate some or all devices. Many alterations and modifications of the present invention will undoubtedly be apparent to those skilled in the art after reading the foregoing description. It is understood that any specific configurations illustrated and explained by way of description are not intended to be in any way exclusive. Therefore, the references given are not intended to be exclusive of those features which are fundamental to the invention. TR TR TR TR TR