Subject: Question about the MPEG-4 SL Payload Format

From: "Norihito Takatori" <[email-masked]>
Date: Fri, 26 Nov 1999 21:26:49 +0900

Hello all,

I am implementing a RTP system in compliance with I-D
“draft-ietf-avt-rtp-mpeg4-01.txt”. In the draft, it is written that
Sequence Number is derived from the sequenceNumber field of the SL
packet by adding a constant random offset.
I have a question as regards the Sequence Number.  My understanding is
that when a RTP client issues “SEEK” operation from current position
to a previous position (e.g. 0 position) , the Sequence Number should
return the previous Sequence Number.
On the other hand, it is written that the sequence number increments
by one for each RTP data packet sent in RFC1889.
Which should I comply with ?
Also, I guess that the same problem will occur as regards the
timestamp.

Thanks.

---------------------------------
Norihito Takatori
E-mail: [email-masked]
Information　Technology　R＆D　Center
Mitsubishi Electric Corporation
TEL: +81-467-41-2103,  FAX: +81-467-41-2137

---

From: "Ram Kordale" <[email-masked]>
Date: Fri, 26 Nov 1999 11:11:07 -0800

Generally speaking, the sequence number of consecutive RTP packets should
either stay the same (allowing for deliberate repeated packets) or be
incremented. This mechanism is used to gracefully handle problems arising from
"non-ideal" networks.

On the other hand, since the timestamp reflects the sampling instant of the
first octet in the RTP data packet, the timestamp of an RTP packet after
a reposition can indeed be lower.

Ram

On Nov 26,  9:26pm, Norihito Takatori wrote:
> Subject: Question about the MPEG-4 SL Payload Format
> Hello all,
>
>-- End of excerpt from Norihito Takatori

-- 
Ram Kordale
Advanced Media Products

---

From: Colin Perkins <[email-masked]>
Date: Sat, 27 Nov 1999 15:08:25 +0000

--> Norihito Takatori writes:
>draft-ietf-avt-rtp-mpeg4-01.txt. In the draft, it is written that Sequence
>Number is derived from the sequenceNumber field of the SL packet by adding
>a constant random offset.  I have a question as regards the Sequence
>Number.  My understanding is that when a RTP client issues SEEK operation
>from current position to a previous position (e.g. 0 position) , the
>Sequence Number should return the previous Sequence Number.  On the other
>hand, it is written that the sequence number increments by one for each
>RTP data packet sent in RFC1889.  Which should I comply with ?  Also, I
>guess that the same problem will occur as regards the timestamp.

This is actually a generic issue when streaming from a file, rather than an
MPEG-4 specific issue. 

The RTP sequence number must be incremented by one for each packet sent. If
packets are sent with a previous sequence number, the receiver may discard
them as duplicates (and the RTCP statistics will be incorrect). 

Receivers use the RTP timestamp to determine when to playout media data. If
this jumps backwards as a result of a seek operation, this indicates to the
receiver that the data is old - has arrived too late for playout - and
should be discarded. 

The result is that you should remap the sequence number and timestamp to be
a contiguous sequence when seeking, as if the data were a single continuous 
stream.

Colin