Lines Matching full:bitstream

566 If only one stream is present, it is a single bitstream occupying the entire
611 followed by the bitstream.
613 …ction_Header` | [`Literals_Length_Table`] | [`Offset_Table`] | [`Match_Length_Table`] | bitStream |
683 and interleaved with raw additional bits in the same bitstream.
690 the result of reading `Number_of_Bits` bits from the bitstream,
719 the result of reading `Number_of_Bits` bits from the bitstream,
768 must read the bitstream _backwards_.
770 To find the start of the bitstream it is therefore necessary to
776 padding. The last byte of the compressed bitstream cannot be `0` for
781 the first `1`-bit it occurs. Afterwards, the useful part of the bitstream
793 The bitstream starts with initial FSE state values,
802 so the 'start' of the bitstream is at the highest position in memory,
808 Since the compressor writes the bitstream in the forward direction,
829 See the [FSE section](#fse) for details on how to update states from the bitstream.
832 At the end, the bitstream shall be entirely consumed,
833 otherwise the bitstream is considered corrupted.
1045 It's a bitstream which is read forward, in __little-endian__ fashion.
1046 It's not necessary to know bitstream exact size,
1049 The bitstream starts by reporting on which scale it operates.
1105 The bitstream consumes a round number of bytes.
1186 Therefore, to find the start of the bitstream, it is therefore to
1191 padding. The last byte of the compressed bitstream cannot be `0` for
1196 the first `1`-bit it occurs. Afterwards, the useful part of the bitstream
1199 The bitstream contains Huffman-coded symbols in __little-endian__ order,
1297 It's a single bitstream with 2 interleaved states,
1300 To decode an FSE bitstream, it is necessary to know its compressed size.
1306 An FSE bitstream starts by a header, describing probabilities distribution.
1320 by tracking bitStream overflow condition:
1358 Each bitstream must be read _backward_,
1360 Therefore it's necessary to know the size of each bitstream.
1366 And the final-bit-flag itself is not part of the useful bitstream.
1370 it's possible to read the bitstream in a __little-endian__ fashion,
1371 keeping track of already used bits. Since the bitstream is encoded in reverse
1381 Resulting in following 2-bytes bitstream :
1396 If a bitstream is not entirely and exactly consumed,