Subject: RE: RTP (encapsulating H263) framing mechanism?

From: "Adam Li" <[email-masked]>
Date: Wed, 17 May 2000 19:31:12 -0700

Thanks for the message.

Unfortunately, RFC 2429 doesn't specify packet length.
H.263 payload in RTP has header :
      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   RR    |P|V|   PLEN    |PEBIT|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There is no length field (and indeed shouldn't be a length field).

RTP is not designed to be used as a stream. In another word,
you can not search for a code that signals a new packet
(like what you can do in H.263 with PSC). There is nothing
to prevend the H.263 bitstream to emulate a valid RTP header.

If you wrote a bounch of RTP packets into a file (for simulation
or whatever), the solution is to record the starting position of
each packet in a seperate file.

Hope it helps.

Adam

----------
Adam H. Li
Image Communication Lab                          (310) 825-5178 (Lab)
University of California, Los Angeles            (310) 825-7928 (Fax)

  -----Original Message-----
  From: Tom Morrison [mailto:[email-masked]]
  Sent: Wednesday, May 17, 2000 7:14 PM
  To: Adam Li; Mohamed K CHERIF; [email-masked]
  Subject: Re: RTP (encapsulating H263) framing mechanism?

  excuse me for inject my humble opinion...

  but isn't he asking how to figure out
  the total size of RTP packets that
  he has received that has an H.263
  Payload type?

  I haven't looked specificially at the RFC payload
  type for H.263, but I am betting that there
  is some type of extended header that shall
  define the length of the rest of the packet
  (and if I remember from my picturetel dayz...
  so long ago...)

  wasn't there also some requirement to define the
  start of a H.263 Video frame within that extended
  header...

  I hope I read his question correctly, and remember something...?

  ...sorry, I'll go back to my lurking...

    ----- Original Message -----
    From: Adam Li
    To: Mohamed K CHERIF ; [email-masked]
    Sent: Wednesday, May 17, 2000 9:24 PM
    Subject: RE: RTP (encapsulating H263) framing mechanism?

    RTP is for packet-switch network. That means you get them in individual
packets, not a continues bitstream as in circuit-switched case.

    Hope it helps.

    Adam

    PS:

    In RFC 1889 :
        o The length of the packet must be consistent with CC and
             payload type (if payloads have a known length).

    H.263 payloads don't have a fixed length.

    ----------
    Adam H. Li
    Image Communication Lab                          (310) 825-5178 (Lab)
    University of California, Los Angeles            (310) 825-7928 (Fax)

      -----Original Message-----
      From: Mohamed K CHERIF [mailto:[email-masked]]
      Sent: Wednesday, May 17, 2000 10:21 AM
      To: [email-masked]
      Subject: RTP (encapsulating H263) framing mechanism?

      Hi All,
      I need to depacketize RTP packets which encapsulate H263 streams. I
was =
      thinking that there should be a packet length field in the RTP header,
=
      but there was not. If an RTP stream is provided, is there a way to
tell =
      where does the second RTP packet starts?
      Thank you so much.
      Mohamed

---

From: "Mohamed K CHERIF" <[email-masked]>
Date: Thu, 18 May 2000 11:06:50 -0700

Thanks for Adam, Tom and Martin for their interesting reply. I agree with Adam in that the input to my RTP depacketizer is not supposed to be a continous octet stream. As Tom said too the bytes might not be aligned and the start offset has to be read from the extension payload header (this is only valid for H263 not H263+ I believe). 
One last question guys, is the time stamp increment for H263+ equal to one? (I assume a 90 Khz clock). In that case, I think of an "artificial" way to get the next packet from the RTP stream (even if it's continuous). I just need to calculate the next timestamp and assume the data is unlikely to produce a pattern (sequence # + timestamp).
Thanks a lot for all.

Mohamed K Cherif, M.A.Sc. - UBC
UB Video - Application Developer
Tel 737 2426 Ext 26
  ----- Original Message ----- 
  From: Adam Li 
  To: Tom Morrison ; Mohamed K CHERIF ; [email-masked] 
  Sent: Wednesday, May 17, 2000 7:31 PM
  Subject: RE: RTP (encapsulating H263) framing mechanism?

  Thanks for the message.

   
   
  Hope it helps.
   
  Adam

  ----------
  Adam H. Li

      ----- Original Message ----- 
      From: Adam Li 
      To: Mohamed K CHERIF ; [email-masked] 
      Sent: Wednesday, May 17, 2000 9:24 PM
      Subject: RE: RTP (encapsulating H263) framing mechanism?

      RTP is for packet-switch network. That means you get them in individual packets, not a continues bitstream as in circuit-switched case.
       
      Hope it helps.
       
      Adam

      PS:
       
      In RFC 1889 :

      ----------
      Adam H. Li

        -----Original Message-----
        From: Mohamed K CHERIF [mailto:[email-masked]]
        Sent: Wednesday, May 17, 2000 10:21 AM
        To: [email-masked]
        Subject: RTP (encapsulating H263) framing mechanism?

        Hi All,
        I need to depacketize RTP packets which encapsulate H263 streams. I was =
        thinking that there should be a packet length field in the RTP header, =
        but there was not. If an RTP stream is provided, is there a way to tell =
        where does the second RTP packet starts?
        Thank you so much.
        Mohamed

---

From: Billy Biggs <[email-masked]>
Date: Thu, 18 May 2000 16:44:03 -0400

Mohamed K CHERIF ([email-masked]):

> Thanks for Adam, Tom and Martin for their interesting reply. I agree with
> Adam in that the input to my RTP depacketizer is not supposed to be a
> continous octet stream. As Tom said too the bytes might not be aligned and
> the start offset has to be read from the extension payload header (this is
> only valid for H263 not H263+ I believe). 

> One last question guys, is the time stamp increment for H263+ equal to
> one?  (I assume a 90 Khz clock). In that case, I think of an
> "artificial" way to get the next packet from the RTP stream (even if
> it's continuous). I just need to calculate the next timestamp and
> assume the data is unlikely to produce a pattern (sequence # +
> timestamp).

  If you're still trying to hack it so you don't have to know the size of
the packet, you're going to get very messed up if you try to do some hack
based on the clock.  What if some broken implementation sends you a
packet that is too long?  What if the clock on the sender is a little
off?

  The only solution would seem to be that your upper layers need to know
the size of the frame.  In the interests of robustness, better re-design
your streamer.

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: "Mohamed K CHERIF" <[email-masked]>
Date: Thu, 18 May 2000 14:31:42 -0700

Thanks Billy.
I'm developing an application which implements RTP only. I need to deliver
it to someone else who will have the packet sizes (I guess inside the IP
pakets). Is there a way to generate a librairy that can get the packet sizes
as input from the upper layers? (I can't deliver source code).
All help is much appreciated.