Hi, I'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can skip it if it doesn?t know how to interpret it." Ok, so I prepend my data as such: speex_bits_pack(&sbBits, 13, 5); speex_bits_pack(&sbBits, length, 5); // bla bla insert my stuff then encode the packet. And this works :) My custom handler, set with SPEEX_SET_USER_HANDLER is called and everything is good. However, I kinda wondered what would happen if that handler WASN'T installed... And things aren't so good then. Looking at the code in speex_callbacks.c, it seems the speex_default_user_handler first unpacks 4 bits as size, then advances 8*size + 5 bits. First of all, shouldn't that be 5 bits for size (to match manual)? And where did that '+ 5 bits' come from? Next, and slightly unrelated question: Why does int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket *packet, spx_int32_t *start_offset); include the packet parameter? It's not used in the code, and it also makes the API slightly confusing as it's very unclear what that parameter should be :)
On Sunday 08 July 2007 02:24, Thorvald Natvig wrote:> Next, and slightly unrelated question: > Why does > int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket > *packet, spx_int32_t *start_offset); > include the packet parameter? It's not used in the code, and it also > makes the API slightly confusing as it's very unclear what that > parameter should be :)The packet parameter is included to allow coming up iterations of the jitter-buffer to improve the perceived quality by changing the packet, without changing the API. Peter -- The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure.
Thorvald Natvig a ?crit :> I'm moving my "metadata" which accompanies some of the speech packets > into the speex bits. However, as usual, I'm a bit confused. > > The manual (PDF from current SVN), section 5.10 (bottom of page 21) > states that: > > "Finally, applications may define custom in-band messages using mode 13. > The size of the message in bytes is encoded with > 5 bits, so that the decoder can skip it if it doesn?t know how to > interpret it."...> Looking at the code in speex_callbacks.c, it seems the > speex_default_user_handler first unpacks 4 bits as size, then advances > 8*size + 5 bits. > First of all, shouldn't that be 5 bits for size (to match manual)? And > where did that '+ 5 bits' come from?I think I messed up (at least twice!) here and you're probably the first to attempt to use this feature. Let me have a closer look at what it should really be.> Next, and slightly unrelated question: > Why does > int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket > *packet, spx_int32_t *start_offset); > include the packet parameter? It's not used in the code, and it also > makes the API slightly confusing as it's very unclear what that > parameter should be :)Peter's earlier answer is correct here. Jean-Marc
pwk.linuxfan@gmx.de wrote:> On Sunday 08 July 2007 02:24, Thorvald Natvig wrote: > >> Next, and slightly unrelated question: >> Why does >> int jitter_buffer_update_delay(JitterBuffer *jitter, JitterBufferPacket >> *packet, spx_int32_t *start_offset); >> include the packet parameter? It's not used in the code, and it also >> makes the API slightly confusing as it's very unclear what that >> parameter should be :) >> > > The packet parameter is included to allow coming up iterations of the > jitter-buffer to improve the perceived quality by changing the packet, > without changing the API. >Ah, so the data in the jitter buffer should still be a pure speex packet? I thought one of the reasons for moving away from speex_jitter_blabla was to make the jitter buffer more generic? I'm currently using 1 byte before the packet for metadata which accompanies each and every packet. I could move that to in-band user data as well, but that would mean it's 2 bytes instead of 1 :(