Я рассматриваю библиотеку C# под названием BitStream, которая позволяет вам писать и читать любое количество битов в стандартный объект C# Stream
. Я заметил, как мне показалось, странное дизайнерское решение:
При добавлении битов к пустому байту биты добавляются к старшему биту байта. Например:
var s = new BitStream();
s.Write(true);
Debug.Assert(s.ToByteArray()[0] == 0x80); // and not 0x01
var s = new BitStream();
s.Write(0x7,0,4);
s.Write(0x3,0,4);
Debug.Assert(s.ToByteArray()[0] == 0x73); // and not 0x37
Однако при указании битов числа как входных первым битом входного числа является младший бит. Например
//s.Write(int input,int bit_offset, int count_bits)
//when referencing the LSB and the next bit we'll write
s.Write(data,0,2); //and not s.Write(data,data_bits_number,data_bits_number-2)
Мне это кажется непоследовательным. Так как в этом случае при "постепенном" копировании байта как в предыдущем примере (первые четыре бита, а потом последние четыре бита) мы не получим исходный байт. Нам нужно скопировать его «назад» (сначала последние четыре бита, потом первые четыре бита).
Есть ли причина для этого дизайна, который мне не хватает? Любая другая реализация потока битов с таким поведением? Каковы соображения дизайна для этого?
Кажется, что битовый поток ffmpeg
ведет себя так, как я считаю последовательным. Посмотрите на величину сдвига байта, прежде чем OR
обозначить его указателем src
в функция put_bits
.
В качестве примечания:
Первый добавленный байт является первым байтом в массиве байтов. Например
var s = new BitStream();
s.Write(0x1,0,4);
s.Write(0x2,0,4);
s.Write(0x3,0,4);
Debug.Assert(s.ToByteArray()[0] == 0x12); // and not s.ToByteArray()[1] == 0x12