Subject: [AVT] Adoption of RAMS-related (MA-XR and MPEG2-TS Preamble) drafts

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 7 Sep 2009 07:22:06 -0700

Chairs,

Following up on our earlier request: In the interest of improving the RAMS protocol, could the AVT WG adopt the following two drafts? There is certainly interest from parties implementing RAMS.

Both of these drafts were presented in the last meeting and have been updated based on the comments. We'd like these documents to be adopted and finalized before the RAMS draft is WGLC'ed. 

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

Thanks.
-acbegen

---

From: Tom Taylor <[email-masked]>
Date: Mon, 07 Sep 2009 23:45:20 -0400

I pass this question to the list. Are we prepared to pick these up as WG work items?

Ali C. Begen (abegen) wrote:
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 8 Sep 2009 09:28:38 -0400

I think that both of these are valuable contributions, are needed in
order to develop interoperable/optimized RAMS implementations, and
should be WG items

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Taylor
Sent: Monday, September 07, 2009 11:45 PM
To: [email-masked]
Subject: Re: [AVT] Adoption of RAMS-related (MA-XR and MPEG2-TS
Preamble) drafts

I pass this question to the list. Are we prepared to pick these up as WG
work items?

Ali C. Begen (abegen) wrote:
> Chairs,
> 
> Following up on our earlier request: In the interest of improving the
RAMS protocol, could the AVT WG adopt the following two drafts? There is
certainly interest from parties implementing RAMS.
> 
> Both of these drafts were presented in the last meeting and have been
updated based on the comments. We'd like these documents to be adopted
and finalized before the RAMS draft is WGLC'ed.

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 08 Sep 2009 10:10:31 -0400

For draft-begen-avt-rtp-mpeg2ts-preamble-02.txt, to me, the work is valid
and should be adopted by the WG only if it is not possible to not scatter
the reference information according to the MPEG-2 TS spec. Could anyone
provide an analysis on why the reference information must be scattered
according to the MPEG-2 TS design? Alternatively, a LS could be sent to MPEG
to get an answer. 

BR, YK 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom Taylor
> Subject: Re: [AVT] Adoption of RAMS-related (MA-XR and 
> MPEG2-TS Preamble) drafts
> 
> > Following up on our earlier request: In the interest of 
> improving the RAMS protocol, could the AVT WG adopt the 
> following two drafts? There is certainly interest from 
> parties implementing RAMS.
> > 
> > Both of these drafts were presented in the last meeting and 
> have been updated based on the comments. We'd like these 
> documents to be adopted and finalized before the RAMS draft 
> is WGLC'ed. 
> >

---

From: Eric Friedrich <[email-masked]>
Date: Tue, 8 Sep 2009 10:46:21 -0400

Thanks Ye-Kui-
   The preamble is necessary as it provides a mechanism to group  
together all parts of the reference information preceding a RAMS  
burst. At the most basic level, a MPEG2-TS is made up of several  
multiplexed streams. Elementary streams such as audio and video and  
program specific information (PAT, PMT) are all multiplexed together  
into a single Transport Stream. The MPEG2-TS spec (Section 2.4)  
provides little guidance as to how these are multiplexed together. The  
interleaving of the different elements can even change as a stream  
passes through the network. Devices such as statistical multiplexers,  
transraters, transcoders and others are free to alter the location of  
reference elements.

   As the preamble draft describes, decoders require such information  
as the PAT, PMT, PCR, and any ECMs (see Slide 3 in http://www.ietf.org/proceedings/75/slides/avt-9.pdf) 
  before they can begin decoding the RAMS burst and I-Frame. Rarely is  
this information directly adjacent in the stream. In most cases, the  
decoder must wait for all of the above elements to occur naturally  
before beginning the decoding. Depending on the stream this can take  
several hundred milliseconds of extra channel change time. I agree it  
would be nice if every I-Frame is preceded by the necessary  
information, eliminating that delay. However the format of the video  
stream is almost always out of the control of the RS and the reference  
information is scattered. The RS cannot change the format of the  
Transport Stream, which is why it must use the preamble. The preamble  
is necessary to group together all these pieces of reference  
information that are otherwise spread throughout the Transport Stream.

There is no requirement for the the reference information to be  
scattered. It may be grouped together if the encoder/multiplexer/etc  
has such intelligence. The need for the preamble arises from the fact  
that such intelligence is rarely used by existing devices and the RS  
is not allowed to re-multiplex the Transport Stream.

Thanks,
Eric

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 08 Sep 2009 12:12:34 -0400

Hi Eric,

Thanks for your quick reply. So the most important point is that RS cannot
change the format of the TS streams. One further question: Based on this
assumption, if the input to the RS is a TS stream, then the unicast burst
RTP stream is A-V multiplexed TS stream. Assuming that the video in use is
H.264/AVC. Then which RTP payload format should be used for the unicast
burst? I guess not RFC 3984? 

BR, YK 

> From: Eric Friedrich [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 10:46 AM
> To: Ye-Kui Wang
> Cc: Tom Taylor; [email-masked]
>    The preamble is necessary as it provides a mechanism to 
> group together all parts of the reference information 
> preceding a RAMS burst. At the most basic level, a MPEG2-TS 
> is made up of several multiplexed streams. Elementary streams 
> such as audio and video and program specific information 
> (PAT, PMT) are all multiplexed together into a single 
> Transport Stream. The MPEG2-TS spec (Section 2.4) provides 
> little guidance as to how these are multiplexed together. The 
> interleaving of the different elements can even change as a 
> stream passes through the network. Devices such as 
> statistical multiplexers, transraters, transcoders and others 
> are free to alter the location of reference elements.
> 
>    As the preamble draft describes, decoders require such 
> information as the PAT, PMT, PCR, and any ECMs (see Slide 3 
> in http://www.ietf.org/proceedings/75/slides/avt-9.pdf)
>   before they can begin decoding the RAMS burst and I-Frame. 
> Rarely is this information directly adjacent in the stream. 
> In most cases, the decoder must wait for all of the above 
> elements to occur naturally before beginning the decoding. 
> Depending on the stream this can take several hundred 
> milliseconds of extra channel change time. I agree it would 
> be nice if every I-Frame is preceded by the necessary 
> information, eliminating that delay. However the format of 
> the video stream is almost always out of the control of the 
> RS and the reference information is scattered. The RS cannot 
> change the format of the Transport Stream, which is why it 
> must use the preamble. The preamble is necessary to group 
> together all these pieces of reference information that are 
> otherwise spread throughout the Transport Stream.
> 
> There is no requirement for the the reference information to 
> be scattered. It may be grouped together if the 
> encoder/multiplexer/etc has such intelligence. The need for 
> the preamble arises from the fact that such intelligence is 
> rarely used by existing devices and the RS is not allowed to 
> re-multiplex the Transport Stream.
> 
> Thanks,
> Eric
> 
> 
> > For draft-begen-avt-rtp-mpeg2ts-preamble-02.txt, to me, the 
> work is  
> > valid
> > according to the MPEG-2 TS design? Alternatively, a LS 
> could be sent  
> > to MPEG
> > to get an answer.
> >
> > BR, YK
> >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 8 Sep 2009 09:18:41 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui Wang
> Sent: Tuesday, September 08, 2009 12:13 PM
> To: Eric Friedrich (efriedri)
> Cc: 'Tom Taylor'; [email-masked]
> Subject: Re: [AVT] Adoption of RAMS-related (MA-XR and MPEG2-TS Preamble)drafts
> 
> 
> Hi Eric,
> 

The packets sent in the burst are formatted as retransmission packets (rfc 4588). So, the incoming packets are RTP packets (be it RFC 2250 or 3984, or whatever). The burst packets are those packets as formatted according to 4588.

Cheers.
-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 08 Sep 2009 14:29:45 -0400

OK, in the context of MPEG-2 TS streams, RFC 2550 will be used for
packetization the TS streams. 

The reasoning from Eric seems good to me. I have no further comments to this
draft (draft-begen-avt-rtp-mpeg2ts-preamble-02.txt), and I have no problem
in adopting the draft as a WG item. 

BR, YK 

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 12:19 PM
> To: Ye-Kui Wang; Eric Friedrich (efriedri)
> Subject: RE: [AVT] Adoption of RAMS-related (MA-XR and 
> MPEG2-TS Preamble)drafts
> 
> 
> 
> Behalf Of 
> > Ye-Kui Wang
> > Preamble)drafts
> > Thanks for your quick reply. So the most important point is that RS 
> > cannot change the format of the TS streams. One further question: 
> > Based on this assumption, if the input to the RS is a TS 
> stream, then 
> > the unicast burst RTP stream is A-V multiplexed TS stream. Assuming 
> > that the video in use is H.264/AVC. Then which RTP payload format 
> > should be used for the unicast burst? I guess not RFC 3984?
> 
> The packets sent in the burst are formatted as retransmission 
> packets (rfc 4588). So, the incoming packets are RTP packets 
> (be it RFC 2250 or 3984, or whatever). The burst packets are 
> those packets as formatted according to 4588.
> 
> Cheers.
> -acbegen
> 
>  
> > BR, YK
> > 
> > > provides little guidance as to how these are multiplexed 
> together. 
> > > The interleaving of the different elements can even change as a 
> > > stream passes through the network. Devices such as statistical 
> > > multiplexers, transraters, transcoders and others are 
> free to alter 
> > > the location of reference elements.
> > >
> > > information as the PAT, PMT, PCR, and any ECMs (see Slide 3 in 
> > > http://www.ietf.org/proceedings/75/slides/avt-9.pdf)
> elements 
> > > to occur naturally before beginning the decoding.
> milliseconds 
> > > of extra channel change time. I agree it would be nice if every 
> > > I-Frame is preceded by the necessary information, 
> eliminating that 
> > > delay. However the format of the video stream is almost 
> always out 
> > > of the control of the RS and the reference information is 
> scattered. 
> > > The RS cannot change the format of the Transport Stream, which is 
> > > why it must use the preamble. The preamble is necessary to group 
> > > has such intelligence. The need for the preamble arises from the 
> > > fact that such intelligence is rarely used by existing 
> devices and 
> > > the RS is not allowed to re-multiplex the Transport Stream.
> > >
> > > Thanks,
> > > Eric
> > >
> > >
> > > > and should be adopted by the WG only if it is not 
> possible to not 
> > > > scatter the reference information according to the 
> MPEG-2 TS spec. 
> > > > Could anyone provide an analysis on why the reference 
> information 
> > > > must
> > > be scattered
> MPEG2-TS 
> > > >> I pass this question to the list. Are we prepared to 
> pick these 
> > > >> up as WG work items?
> > > >>
> > > >> improving the RAMS protocol, could the AVT WG adopt 
> the following 
> > > >> two drafts? There is certainly interest from parties 
> implementing 
> > > >> RAMS.
> > > >>>
> > > >> documents to be adopted and finalized before the RAMS draft is 
> > > >> WGLC'ed.
> > > >>>
> > > >>>
> > > 
> > > >>> Audio/Video Transport Working Group [email-masked] 
> > > >> Audio/Video Transport Working Group [email-masked]