Subject: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-02.txt

From: "Aaron Wells" <[email-masked]>
Date: Tue, 1 Sep 2009 16:02:58 -0700

All,

I see that the RFC for carrying MPEG2-TS across RTP involves
first parsing and reformatting the MPEG2-TS stream to put various
syntax elements into the RTP TLOV format, then, at the receiver side,
attempting to re-generate a compliant MPEG2-TS stream
so that it can be consumed by the decoder.

Section 7 has the following text:
	The final type of Preamble data is that contained in an
elementary 
	stream.  This includes data from the SEQ, SPS, PPS and SEI
TLOVs.
	Each TS packet begins with a 4-byte TS header containing the PID
value 
	given in the Preamble TLOV element.  The adaptation field
padding can be 
	used to pad the last TS packet to 188 bytes.

1) Is it correct to infer from the above that these syntax elements must
not be left
in the payload (with their information duplicated in the RTP header),
rather
that these syntax elements must be removed from the MPEG2 system stream
and only sent in the RTP header?

If removal is mandatory, what benefit accrues from removing and 
regnerating syntax elements like SPS, PPS and SEI, rather than just
leaving
them at their original position within the payload stream?

Alternatively, if this removal is optional, and if the transmitter does
not choose to
remove these elements, how does the RTP receiver know not to
re-insert(and 
thereby duplicate) this data?

2) Is it intended by section 7 that each of PAT, PMT, CAT, PCR, SPS, PPS
SEI
must be converted to a separate transport stream (TS) packet?
I ask because of the following sentence:
	"The continuity counter value of the final
       packet of Preamble data should be one less than the first packet
       on the MPEG2-TS stream with that same PID."
If so: why?

3) In particular, I read the draft to say that PCR would go into a
separate packet:
	 "A single TS packet is constructed from the PCR TLOV.  This
       contains a 4-byte TS header with correct PID and continuity
       counter as retrieved from the PIDLIST.  The Adaptation Field
       control bits should indicate that only an adaptation_field and no
       payload is present."

It is not uncommon in broadcast to put PCR on the video PID, and in 
fact to put PCR/PES/SPS/PPS/SEI/Slice (PCR/PES/Seq/Gop/Picture in MP2)
all
in the same packet at the start of each GOP, or the appropriate headers
at 
the start of each access unit.

If I read correctly, this draft requirement seems at odds with
an industry practice and may conflict with specifications from 
other standards bodies that require the PCR to remain unmolested,
both in value and in location.

As practical matter, one could imagine problems in taking this stream
off IP 
back on to a fixed bandwidth link, due to data expansion introduced by
moving PCR 
or other syntax elements into separate transport packets and stuffing
them out to a 
188 byte boundary.

Aaron

----------------------------------------------------------------------
Today's Topics:

   1. I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-02.txt
      ([email-masked])
   2. FW: I-D
      Action:draft-ietf-avt-rapid-acquisition-for-rtp-02.txt
      (Ali C. Begen (abegen))

----------------------------------------------------------------------

Message: 2
Date: Tue, 25 Aug 2009 02:36:02 -0700
From: "Ali C. Begen (abegen)" <[email-masked]>
Subject: [AVT] FW: I-D
	Action:draft-ietf-avt-rapid-acquisition-for-rtp-02.txt
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain; charset="windows-1252"

This update addresses several open issues. We also completed two main
missing sections (Security cons. and burst shaping issues).

There are a few remaining open items and we are hoping to address them
before the next meeting. Comments are welcome.

Chairs,

The MPEG2-TS and XR drafts related to RAMS have been updated based on
the comments we received in IETF 75 as well. As the authors, we would
like to finalize these drafts before RAMS is WGLC'ed. Could you please
ask WG about adopting both of these drafts?

Drafts are:

http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-02.txt
http://tools.ietf.org/id/draft-begen-avt-rapid-sync-rtcp-xr-02.txt

-acbegen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 25, 2009 11:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: [AVT] I-D
Action:draft-ietf-avt-rapid-acquisition-for-rtp-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Audio/Video Transport Working Group of
the IETF.

	Title           : Unicast-Based Rapid Acquisition of Multicast
RTP Sessions
	Author(s)       : B. Ver Steeg, et al.
	Filename        :
draft-ietf-avt-rapid-acquisition-for-rtp-02.txt
	Pages           : 45
	Date            : 2009-08-25

When an RTP receiver joins a primary multicast session, it may need to
acquire and parse certain Reference Information before it can process
any data sent in the multicast session.  Depending on the join time,
length of the Reference Information repetition interval, size of the
Reference Information as well as the application and transport
properties, the time lag before an RTP receiver can usefully consume the
multicast data, which we refer to as the Acquisition Delay, varies and
may be large.  This is an undesirable phenomenon for receivers that
frequently switch among different multicast sessions, such as video
broadcasts.

In this document, we describe a method using the existing RTP and RTCP
protocol machinery that reduces the acquisition delay.  In this method,
an auxiliary unicast RTP session carrying the Reference Information to
the receiver precedes/accompanies the primary multicast stream.  This
unicast RTP flow may be transmitted at a faster than natural rate to
further accelerate the acquisition.  The motivating use case for this
capability is multicast applications that carry real-time compressed
audio and video.  However, the proposed method can also be used in other
types of multicast applications where the acquisition delay is long
enough to be a problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-acquisition-for
-rtp-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-avt-rapid-acquisition-for-rtp-02.URL
Type: application/octet-stream
Size: 108 bytes
Desc: draft-ietf-avt-rapid-acquisition-for-rtp-02.URL
Url :
<http://www.ietf.org/mail-archive/web/avt/attachments/20090825/eba9fa38/
attachment.dll>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 1 Sep 2009 19:50:43 -0700

Hi Aaron,

Inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Aaron Wells
> Sent: Wednesday, September 02, 2009 2:03 AM
> To: [email-masked]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-02.txt
> 
> 
> 
> All,
> 

Correct.
 
> and only sent in the RTP header?

Not sure what you mean here. 

We don't remove anything from the original RTP stream/packets. The MPEG2-TS as encapsulated within RTP (RFC 2250) stays untouched.

But, we do gather "important" parts from this stream and prepare bunch of TLOVs. That information is sent to the receiver as RTP payload. We don't carry anything special in the RTP header.

> them at their original position within the payload stream?

As I said, we don't remove anything from the stream. The purpose of preparing the preamble and sending to the receiver is to allow the decoder to get prepared for the incoming new stream and start decoding sooner.

> thereby duplicate) this data?

First the preamble packets will have a different PT number or will be in a different rtp session.

Second, there is not really much duplication. We send the preamble, and we send the original RTP packets (carrying the mpeg2-ts) starting from an appropriate point in the RTP stream. The preamble info is prepared according to this starting point.
 
>        on the MPEG2-TS stream with that same PID."

So that we don't create a jump in CC.

> both in value and in location.

We are not modifying the original stream which should be generated based on the standards, current practices, etc. Our goal in this draft is to define the preamble info and present how to carry it in RTP and how the receiver uses that info. Considering the benefit of doing this, I don’t see much of a problem regarding breaking the mpeg2-ts rules (We might be bending them a little bit).

> or other syntax elements into separate transport packets and stuffing

You might need to consider the main motivation behind this work, which is RAMS. In that context, we already need additional bandwidth (> 1x) to be able to send the burst packets plus any additional payload-specific (such as mpeg2-ts preamble) data at an accelerated bitrate prior to (or during) the reception of multicast packets by the receiver.

Let me know if you have more questions.
-acbegen

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt