Hi Paul, Thanks for offering this. Paul Long wrote:
bool ParseRtpHeader(const BYTE *buffer, RtpHeader &rtp) { ibitstream bin(buffer); static const bitset<2> version(0x2); bitset<4> csrcCount; WORD extensionLength;
bin >> version >> rtp.padding >> rtp.extension.present >> csrcCount >> rtp.marker >> rtp.payloadType >> rtp.sequenceNumber >> rtp.timestamp >> rtp.ssrcIdentifier >> setrepeat(csrcCount.to_ulong()) >> rtp.csrcIdentifier;
if (rtp.extension.present) { bin >> rtp.extension.identifier >> extensionLength >> setrepeat(extensionLength * sizeof(DWORD)) >> rtp.extension.contents; }
return bin.good(); }
Have you measured the performance of your implementation, compared to something more like this (with the shifts etc. obviously made up here): version = (data[0] >> 14) & 0x07f; rtp.padding = (data[0] >> 6) & 0x0ff; rtp.extension.present = data[0] & 0x020; etc. etc. ? 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. 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. My conclusion at the time was that the ideal solution would be to create a "yacc-like" tool that would parse the bitstream spec (preferably copied straight from the MPEG documentation) and generate stream decoding code in the style shown. This was never more than a vague idea of mine. Perhaps a Boost.Spirit kind of parser would be another possibility. Regards, Phil.