Speex dev - Aug 2004 - First draft for Speex RTP profile - Please send your comments

> 
> > I think the SpeeX frame format should not require negotiation of the
> > number of frames to be transmitted.
<snip>
> Personally, I think it's good to make it part of negotiation for two
> reasons.
<snip>

I agree with Jean-Marc.  We discussed this at length and agreed
that including in the packet the number of frames in the packet
is not useful.  Perhaps someone can explain why it would be?  

In general, most apps will use 1 speex frame per packet, simply
to keep latency down.  For streaming apps, perhaps multiple
frames might make sense... but in those scenarios, a pre-arranged
multiple frame per packet arrangement is likely better anyway.

As to multiple frames per packet in general, it can be
dangerous.  Packet loss with lots of frames in one packet leads
to much larger gaps in the audio.  And, since packet loss tends
to be bursty, even duplicate frames in successive packets is not
a good solution in many cases (and it doubles the bandwidth
used!).

I suspect that most applications will in fact use the default of
one frame per packet.  If dynamic changes are needed mid-stream,
they can be arranged out of band easily... the spec shows how to
do that via SDP/SIP.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

(CC'd to the list to have everybody else's opinion on the the subject) 
> I think the SpeeX frame format should not require negotiation of the
> number of frames to be transmitted.
>
> While practically this is done for GSM, ulaw, and alaw, a good
> implementation can handle receiving an arbitrary number of frames and Do
> The Right Thing.  As I recall, Jean made some additions to the protocol to
> enable someone to detect the end of a set of frames.  Perhaps this
> mechanism could be used, or something like it?
Personally, I think it's good to make it part of negotiation for two
reasons. First, because it allows the receiver to explicitly ask for the
number of frames per packets it wants to receive. Second, because the
terminator I was proposing would add one byte to all packets, increasing
bit-rate by 400 bps, even when not needed. In addition, it would
probably require more complex code for jitter compensation in VoIP
applications (since we don't know how many frames were in the packet we
lost).

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: signature.asc
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20021022/e26f55ed/signature-0001.pgp