Subject: RE: Question: packing several frames in a single RTP packet

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Sep 2000 02:58:32 -0400

This may be of theoretical interest only. In practice, I think that all
frame based codecs are either (1) the same frame length, (2) indicate within
the frame itself what size or type it is, when the lengths are not the same.
Its only for frames that have variable length AND don't indicate their
length that you  need worry about this. Does anyone know of any frame codecs
which are a problem?

-Jonathan R.

Amos wrote:
> -----Original Message-----
> Hello all,
> 
> (I hope I am sending this to the correct mailing list. If 
> not, please accept
> my apology and advise me of the correct one)
> 
> In the new draft "RTP Profile for Audio and Video Conferences 
> with Minimal
> Control"
> (http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-ne
> w-09.txt) that
> is supposed to replace RFC-1890, it says (in section 4.4, 
> Guidelines for
> Frame-Based Audio Encodings):
> 
> "The receiver can tell the number of frames contained in an 
> RTP packet, if
> all the frames have the same length, by dividing the RTP 
> payload length by
> the audio frame size which is defined as part of the 
> encoding. This does not
> work when carrying frames of different sizes unless the frame 
> sizes are
> relatively prime."
> 
> My question concerns the last statement: suppose, for 
> example, that the
> frame sizes are 5 and 7 octets, which are relatively prime, 
> and the receiver
> gets a 35-octet packet. How can he/she tell whether the 
> packet contains five
> 7-octet frames or seven 5-octet frames?
> 
> 
> Amos Guler
> 
> ==================== 
> Amos Guler 
> Comverse Network Systems Ltd.
> [email-masked] 
> http://www.comverse.com 
> 
> 
>

---

From: Orion Hodson <[email-masked]>
Date: Sun, 10 Sep 2000 10:50:22 +0100

<[email-masked]>Jonathan R
> length that you  need worry about this. Does anyone know of any frame codecs
 
VDVI is variable length and has no size indicator.  Since it's a very
low cost codec this isn't a major deal - it's 160 16-entry table
searches per frame.  It's slightly unusual because it is a sample
based codec cast that's effectively cast into a frame based format for
unambiguous decoding.  I can't think of any other's off hand.

- Orion.