On 6/29/2013 9:48 AM, Phil Endecott wrote:
Have you measured the performance of your implementation ... ?
No, I have not measured the performance of ibitstream.
I'm curious to know if you are doing bit-by-bit processing of the fields with shift amounts known only at run time, compared to extracting groups of contiguous bits simultaneously with shift amounts known at compile time - and if so, how much that affects performance.
ibitstream performs bit-by-bit processing. It can be optimized to a certain degree as a follow-on task. I suppose that by exposing some bitstream code to the calling context via inlining, the compiler could perform some optimizations, e.g., strength reduction, but I haven't thought about it.
I have previously tried to do some basic MPEG stream processing on an embedded device and started trying to write a general-purpose facility like yours, but decided that it was not fast enough.
Hmm... I guess I have been thinking that bitstream would be used for something less intensive and more high level like packetization as opposed to being the sole means of a writing and reading bits for a media codec. I believe the performance--once optimized--can be quite good and often good enough, but it will never be as efficient as hand-coded logic. Paul