Subject: (Fwd) MPEG-1 over RTP (RFC 2250) conflict?

From: "Ram Kordale" <[email-masked]>
Date: Thu, 9 Dec 1999 20:17:01 -0800

I am surprised at the silence on this list regarding this question. Is my
question way off or does this point to an obvious limitation of the RFC?

I forwarded my message to one of the authors of RFC 2250. He suggested that the
solution to my example scenario is that P13 and P23 would have different
timestamps. I disagreed because 1) they need not have different timestamps and
2) even if they are different there is no mechanism in RTP headers to
distinguish them. I have not heard from him since!

Suggestions?

Thanks
Ram
--- Forwarded mail from <kordale> ("Ram Kordale")

From: "Ram Kordale" <kordale>
Date: Fri, 3 Dec 1999 15:26:06 -0800
To: [email-masked]
Subject: MPEG-1 over RTP (RFC 2250) conflict?

Could someone please clarify the following "conflict" I see in the spec?

In the event of data loss, RFC 2250 has mechanisms to recover at the slice
level(basically by discarding RTP packets until you find one with the
BeginningOfSlice bit set to 1).

However, if you lose a few RTP packets, one is **really forced** to skip
until the beginning of the next GOP!

This is an incredible amount of loss or I have misunderstood the spec. Could
someone please clarify?

Details:
-------

Consider the following segment of MPEG-1 system stream.
...GOP_H P11 P12 P13 ... P1n GOP_H P21 P22 P23 ...

GOP_H refers to GOP Headers. Pij refers to picture j of the ith GOP.

For simplicity, assume that the stream and display order are the same. Thus,
Pij will have a "Temporal Reference" of j. For simplicity, assume each
picture is split into 5 RTP packets.

Suppose I receive RTP packets containing all of the first GOP header and
P11 and I receive 1 RTP packet containing the first "piece" of P12.

Suppose the next RTP packet I received contains the "Temporal Reference"
of 3, how do I know which GOP this picture belongs to. In other words, how
do I know it belongs to P13 or P23 or in general Pi3.

If I cannot know, I will have to insert a broken GOP thus essentially
losing data until the next GOP header is received.

Thanks for your help.
Ram

--
Ram Kordale
Advanced Media Products

---End of forwarded mail from <kordale> ("Ram Kordale")

-- 
Ram Kordale
Advanced Media Products

---

From: Stephen Casner <[email-masked]>
Date: Mon, 13 Dec 1999 00:35:08 -0800 (Pacific Standard Time)

> distinguish them. I have not heard from him since!

Your 1) is not correct.  P13 and P23 must have different timestamps.
Even P12 and P13 must have different timestamps.  That is how the
multiple packets of one picture are distinguished from the multiple
packets of another picture.  This is a characteristic of most video
payload formats for RTP.

Your 2) I don't understand.  The timestamps are in the RTP header and
they are the mechanism to distinguish the two GOPs.  Granted, one must
be able to tell from the delta between timestamp values whether the
lost packets constitute a gap of one frame or a whole GOP.  If the
frame rate is constant and known, as it usually is for MPEG, then this
is easy.  If the frame rate is variable, you might not be able to
tell.
							-- Steve

---

From: [email-masked] (Ram Kordale)
Date: Mon, 13 Dec 1999 07:50:13 -0800 (PST)

> packets of another picture.  This is a characteristic of most video

Thank you very much for the response.

I was interpreting the RTP timestamps for MPEG ES encapsulation to be the
PTS from the MPEG system stream and so I was asserting (1).

> is easy.  If the frame rate is variable, you might not be able to

This is exactly the case I am talking about. I am thinking of the
following solution to the problem. However, it breaks your assertion 
that P12 and P13 must have different RTP timestamps. I would really 
appreciate the group's input on the pros and cons. 

Posssible solution: Let all pictures between two I-pictures (including 
the first I-picture) be called a "mini-GOP"; then, the following apply:
1) All RTP packets for pictures in a mini-GOP must have the same RTP
timestamp.
2) RTP packets for pictures from different mini-GOPs must have different
RTP timestamps.

This gives the mechanism to recover from (2) and the ability to
reconstruct valid and useful GOP headers.

Ram

-- 
Ram Kordale
Advanced Media Products

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Mon, 13 Dec 1999 11:25:05 -0500

----- Original Message -----

> > is easy.  If the frame rate is variable, you might not
be able to

The temporal reference field, TR, in the header, which
counts pictures and
resets at each GOP header, is to be used for this purpose.
Please, READ the appendix of RFC 2250.

------------------------------------------------------------
-----------
M. Reha Civanlar
Division Manager, AT&T Labs - Research
100 Schultz Drive, Red Bank, NJ 07701, U.S.A
[email-masked]
Phone: +1 732 345 3305 Fax:+1 732 345 3033
http://www.research.att.com/info/mrc

---

From: "Ram Kordale" <[email-masked]>
Date: Mon, 13 Dec 1999 10:18:17 -0800

I have read the appendix. Let me make my example simpler. Consider the
following stream:  GOPHdr1 P11 P12 GOPHdr2 P21 P22 GOPHdr3...

For simplicity, I am not distinguishing picture types and maintaining only one
temporal reference counter. Suppose:

1) Each of the pictures is fragmented into 3 RTP packets.
2) Client receives the first RTP packet of the first GOP and loses the next
two.
3) Client then receives first RTP packet corresponding to P22.

The scheme in your appendix will not help the client recognize that a GOP hdr
was lost because the client TR counter is at 2 and the TR field in the RTP
packet is also 2.

Have I assumed something wrongly here?

Thanks.
Ram

On Dec 13, 11:25am, M. Reha Civanlar wrote:
> Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict?
>

-- 
Ram Kordale
Advanced Media Products

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Mon, 13 Dec 1999 15:15:21 -0500

Yes, if you allow for variable framerates AND large variations in the bitrates
AND you loose a large number of packets (covering one or more GOP's
entirely), you may not be able to tell whether you lost a GOP header or not
using the existing mechanisms. However, under these circumstances, I don't think
that you will be able to do much even if you do detect a GOP header loss.

-Reha

----- Original Message -----
From: Ram Kordale <[email-masked]>
To: M. Reha Civanlar <[email-masked]>; Stephen Casner
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, December 13, 1999 1:18 PM
Subject: Re: MPEG-1 over RTP (RFC 2250) conflict?

---

From: "Ram Kordale" <[email-masked]>
Date: Mon, 13 Dec 1999 13:45:04 -0800

I do not see what frame rate and bit rate have to do with this given that they
have no relationship to the number of pictures in a GOP. Given this, losing a
GOP is not abnormal.

However, you may be right in that we should *NOT* be looking for a GOP header
loss after all. We could either
(i) Just recover at the slice level and not care which GOP a picture belongs to
and possibly deteriorate viewing quality.
(ii) OR add provisions in the spec to determine an I picture loss (which is
more significant anyway).

My "mini-GOP" proposal addresses (ii).

I would appreciate comments on (i) vs (ii) and on the proposal for (ii).

Thanks.
Ram

On Dec 13,  3:15pm, M. Reha Civanlar wrote:
>-- End of excerpt from M. Reha Civanlar

-- 
Ram Kordale
Advanced Media Products

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Mon, 13 Dec 1999 17:47:05 -0500

The bitrate and the framerate get into the picture
because, for conventional rates and applications,
you can use the sequence number and the timestamp
to determine the possibility of a GOP header loss
most of the time even under large packet losses
that cover one or more GOPs.

The problem with your proposal is that it decreases the
accuracy of the timestamps which are used for many
important functions including jitter computation and
media synchronization.

As I mentioned before, if the extent of the packet loss
is such that an entire GOP is lost, knowing that a
GOP header is lost may not be useful for any practical
purpose.

-Reha