Subject: [AVT] RFC 2250 and H.264 in MPEG2 TS

From: "Aaron Wells" <[email-masked]>
Date: Wed, 22 Oct 2008 14:47:13 -0700

All,

RFC 2250 metions carrying MPEG1 and MPEG2 elementary
video streams, either directly in RTP packets or encapsulated in
MPEG2 transport stream.

In my googling, I see various postings and documents which state
that this recommendation pertains only to MPEG1 and MPEG2.
However, on the market I am seeing devices which encode 
H.264, but claim to conform to RFC 2250.  (From what I can tell, they 
just make the obvious substitution.)

This raises a few questions for me:
1) Does RFC 2250 limit the elementary streams carried in MPEG2
	transport packets to be either MPEG1 or MPEG2 and exclude
	H.264 and other elementary stream formats?
2) If so, is there some sort of "RFC 2250 bis" that extends this to
H.264?
3) When directly packetized into RTP, audio and video are sent 
	separately, if I understand properly.  I also found an 
	RFC 2343 for "bundled MPEG" transport stream in RTP which refers

	to RFC 2250. One of the differentiating features cited in 2343's

	introduction is the sending of audio and video together 
	in a single RTP stream.

	Am I correct to infer from 2343 that RFC 2250 requires the
	separation of audio and video into separate RTP streams, 
	even in the case that both are encapsulated in MPEG2 transport
packets
	as described in section 2?

	If so, is it expected that PSI (PAT, PMT, PCR, SIT, ...) are 
	duplicated and sent in both RTP streams?
	And if so, is the PMT modified in each to contain information
only for 
		the relevant (audio or video) stream?

Apologies in advance if this is the wrong forum to pose these questions.

Thanks

Aaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, October 22, 2008 12:00 PM
To: [email-masked]
Subject: avt Digest, Vol 54, Issue 32

Send avt mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/avt
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of avt digest..."

Today's Topics:

   1. I-D Action:draft-ietf-avt-post-repair-rtcp-xr-03.txt
      ([email-masked])
   2. FW: New Version Notification for
      draft-ietf-avt-post-repair-rtcp-xr-03 (Ali C. Begen (abegen))
   3. Re: [MMUSIC] An optional a=rtp-keepalive SDP attribute?
      (Xavier Marjou)
   4. Re: [MMUSIC] An optional a=rtp-keepalive SDP attribute?
      (Colin Perkins)
   5. G.729 Annex B in RTP (Steve Underwood)
   6. Protocol Action: 'RTP Payload Format for ITU-T Recommendation
      G.711.1' to Proposed Standard (The IESG)

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

Message: 1
Date: Tue, 21 Oct 2008 19:15:01 -0700 (PDT)
From: [email-masked]
Subject: [AVT] I-D Action:draft-ietf-avt-post-repair-rtcp-xr-03.txt
To: [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

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

Message: 2
Date: Tue, 21 Oct 2008 19:15:22 -0700
From: "Ali C. Begen (abegen)" <[email-masked]>
Subject: [AVT] FW: New Version Notification for
	draft-ietf-avt-post-repair-rtcp-xr-03
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="utf-8"

Hi everyone,

Based on the latest comments from Geoff, I added a few sentences
regarding the repair methods that do partial repair. If everything looks
good, can we finalize the WGLC?

BR,
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tuesday, October 21, 2008 7:11 PM
To: Ali C. Begen (abegen)
Cc: Dong Hsu (dohsu); Michael Lague (mlague)
Subject: New Version Notification for
draft-ietf-avt-post-repair-rtcp-xr-03 

A new version of I-D, draft-ietf-avt-post-repair-rtcp-xr-03.txt has been
successfuly submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-ietf-avt-post-repair-rtcp-xr
Revision:	 03
Title:		 Post-Repair Loss RLE Report Block Type for RTCP XR
Creation_date:	 2008-10-21
WG ID:		 avt
Number_of_pages: 9

Abstract:
This document defines a new report block type within the framework of
RTP Control Protocol (RTCP) Extended Reports (XR).  One of the
initial XR report block types is the Loss Run Length Encoding (RLE)
Report Block.  This report conveys the information regarding the
individual Real-time Transport Protocol (RTP) packet receipt and loss
events experienced during the RTCP interval preceding the
transmission of the report.  The new report, which is referred to as
the Post-repair Loss RLE Report, carries the information regarding
the remaining lost packets after all loss-repair methods are applied.
By comparing the RTP packet receipts/losses before and after the loss
repair is completed, one can determine the effectiveness of the loss-
repair methods in an aggregated fashion.  This document also defines
the signaling of the Post-repair Loss RLE Report in the Session
Description Protocol (SDP).

The IETF Secretariat.

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

Message: 3
Date: Wed, 22 Oct 2008 09:54:10 +0200
From: "Xavier Marjou" <[email-masked]>
Subject: Re: [AVT] [MMUSIC] An optional a=rtp-keepalive SDP attribute?
To: "Colin Perkins" <[email-masked]>
Cc: IETF AVT WG <[email-masked]>, [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

We propose to add the following sentence at the end of
http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-04#section-5
:

When using the SDP [RFC3264] offer-answer, the agent SHOULD offer both
the "a=rtcp-mux" and "a=rtp-keepalive" attributes. If "a=rtcp-mux"
attribute is present in the answer, the agent uses RTCP packets being
multiplexed on the RTP port as a keepalive. Otherwise, the agent uses
RTP packets with an invalid  payload type as a keepalive.

Cheers,
Xavier

On Mon, Oct 20, 2008 at 7:42 PM, Colin Perkins <[email-masked]>
wrote:
> [Apologies for the late response]
>
> I have no objections to the idea of an SDP attribute to indicate that
> keep-alive packets will be generated, but this particular attribute
seems
> under-specified. In particular, I think the draft needs to spell out
exactly
> what is included in the offer, and what response results in
multiplexed RTCP
> and RTP packets being used as the keep-alive, versus which results in
using
> RTP packets with invalid payload type as the keep-alive.
>
> I assume the offer should include both the "a=rtcp-mux" and
> "a=rtp-keepalive" attributes, and send RTCP packets being multiplexed
on the
> RTP port as a keep-alive if the "a=rtcp-mux" attribute is present in
the
> answer, and RTP packets with an invalid payload type otherwise, but
this
> should be spelt out.
>
> Colin
>
>
>
>
> On 2 Oct 2008, at 17:12, Tom Taylor wrote:
>>
>> If no further comments are received by 9 October 2008, this will be
>> forwarded to the IESG.
>>
>> Xavier Marjou wrote:
>>>
>>> We, authors, have just submitted a new version. A
>>> draft-ietf-avt-app-rtp-keepalive-04 should appear soon on the AVT WG
>>> list.
>>> This version includes the parameter discussed below, as well as all
>>> the other comments received during the WGLC.
>>> Cheers,
>>> Xavier
>>> On Thu, Oct 2, 2008 at 5:07 PM, Tom Taylor <[email-masked]>
wrote:
>>>>
>>>> It's time this got closed off. Since there has been no comment on
the
>>>> MMUSIC
>>>> list, my Chair's view is to go ahead and add the attribute.
>>>>
>>>> Xavier Marjou wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> In order to solve the remaining issue of the draft
>>>>> http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-03 (cf
>>>>> details at
>>>>> http://www.ietf.org/mail-archive/web/avt/current/msg09656.html
>>>>> ), we would like some feedback from the MMUSIC WG.
>>>>>
>>>>> The issue is the following: When rtcp-rtp-mux can not be
negotiated,
>>>>> there is a need for an agent to send rtp-keepalive (RTP packets
>>>>> containing no media) without consulting the remote agent (ie: no
need
>>>>> for offer/answer negotiation). Some people indicated they would
like
>>>>> to see this feature indicated in the SDP. We would thus like to
know
>>>>> whether it would be acceptable that an agent add an optional
>>>>> a=rtp-keepalive SDP attribute in order to indicate that it will
send
>>>>> rtp-keepalive when rtcp-rtp can not be negotiated.
>>>>>
>>>>> Cheers,
>>>>> Xavier
>>>>>
>>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/avt
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>

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

Message: 4
Date: Wed, 22 Oct 2008 09:00:40 +0100
From: Colin Perkins <[email-masked]>
Subject: Re: [AVT] [MMUSIC] An optional a=rtp-keepalive SDP attribute?
To: Xavier Marjou <[email-masked]>
Cc: IETF AVT WG <[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Looks good to me.
Colin

On 22 Oct 2008, at 08:54, Xavier Marjou wrote:
> We propose to add the following sentence at the end of
> http://tools.ietf.org/html/draft-ietf-avt-app-rtp- 
> keepalive-04#section-5 :
>
> When using the SDP [RFC3264] offer-answer, the agent SHOULD offer both
> the "a=rtcp-mux" and "a=rtp-keepalive" attributes. If "a=rtcp-mux"
> attribute is present in the answer, the agent uses RTCP packets being
> multiplexed on the RTP port as a keepalive. Otherwise, the agent uses
> RTP packets with an invalid  payload type as a keepalive.
>
> Cheers,
> Xavier
>
> On Mon, Oct 20, 2008 at 7:42 PM, Colin Perkins <[email-masked]>  
> wrote:
>> [Apologies for the late response]
>>
>> I have no objections to the idea of an SDP attribute to indicate that
>> keep-alive packets will be generated, but this particular  
>> attribute seems
>> under-specified. In particular, I think the draft needs to spell  
>> out exactly
>> what is included in the offer, and what response results in  
>> multiplexed RTCP
>> and RTP packets being used as the keep-alive, versus which results  
>> in using
>> RTP packets with invalid payload type as the keep-alive.
>>
>> I assume the offer should include both the "a=rtcp-mux" and
>> "a=rtp-keepalive" attributes, and send RTCP packets being  
>> multiplexed on the
>> RTP port as a keep-alive if the "a=rtcp-mux" attribute is present  
>> in the
>> answer, and RTP packets with an invalid payload type otherwise,  
>> but this
>> should be spelt out.
>>
>> Colin
>>
>>
>>
>>
>> On 2 Oct 2008, at 17:12, Tom Taylor wrote:
>>>
>>> If no further comments are received by 9 October 2008, this will be
>>> forwarded to the IESG.
>>>
>>> Xavier Marjou wrote:
>>>>
>>>> We, authors, have just submitted a new version. A
>>>> draft-ietf-avt-app-rtp-keepalive-04 should appear soon on the  
>>>> AVT WG
>>>> list.
>>>> This version includes the parameter discussed below, as well as all
>>>> the other comments received during the WGLC.
>>>> Cheers,
>>>> Xavier
>>>> On Thu, Oct 2, 2008 at 5:07 PM, Tom Taylor  
>>>> <[email-masked]> wrote:
>>>>>
>>>>> It's time this got closed off. Since there has been no comment  
>>>>> on the
>>>>> MMUSIC
>>>>> list, my Chair's view is to go ahead and add the attribute.
>>>>>
>>>>> Xavier Marjou wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> In order to solve the remaining issue of the draft
>>>>>> http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-03  
>>>>>> (cf
>>>>>> details at
>>>>>> http://www.ietf.org/mail-archive/web/avt/current/msg09656.html
>>>>>> ), we would like some feedback from the MMUSIC WG.
>>>>>>
>>>>>> The issue is the following: When rtcp-rtp-mux can not be  
>>>>>> negotiated,
>>>>>> there is a need for an agent to send rtp-keepalive (RTP packets
>>>>>> containing no media) without consulting the remote agent (ie:  
>>>>>> no need
>>>>>> for offer/answer negotiation). Some people indicated they  
>>>>>> would like
>>>>>> to see this feature indicated in the SDP. We would thus like  
>>>>>> to know
>>>>>> whether it would be acceptable that an agent add an optional
>>>>>> a=rtp-keepalive SDP attribute in order to indicate that it  
>>>>>> will send
>>>>>> rtp-keepalive when rtcp-rtp can not be negotiated.
>>>>>>
>>>>>> Cheers,
>>>>>> Xavier
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/avt
>>
>>
>>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>>
>>
>>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

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

Message: 5
Date: Wed, 22 Oct 2008 23:03:17 +0800
From: Steve Underwood <[email-masked]>
Subject: [AVT] G.729 Annex B in RTP
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

I have a question about the use of G.729 Annex B (DTX/VAD/CNG) in RTP.

RFC3551 says an RTP packet may contain a variable number of 10ms G.729 
frames, and the last frame can be the little 2 byte SID frame to 
commence a period of no transmission. Now, let's say we set the 
packetisation to 40ms, and the first 10ms frame of audio we process 
produces a SID frame. We send an RTP packet containing just this. Let's 
say the next 10ms frame is declared to be voice, and a 10 byte G.729 
frame is produced. The next frame is declared to be another start of 
silence, so a SID frame is produced. We send the 10 bytes + 2 bytes as 
an RTP frame, but its now only 20ms since the last RTP packet. Our DTX 
feature, rather than reduce the data rate, has actually created a peak. 
Under difficult conditions it looks like G.729 might produce bursts of 
high traffic in this way.

Does anyone apply any algorithms to mitigate this behaviour?

Regards,
Steve

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

Message: 6
Date: Wed, 22 Oct 2008 08:46:59 -0700 (PDT)
From: The IESG <[email-masked]>
Subject: [AVT] Protocol Action: 'RTP Payload Format for ITU-T
	Recommendation G.711.1' to Proposed Standard
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, avt mailing list
	<[email-masked]>,	avt chair <[email-masked]>,	RFC
Editor
	<[email-masked]>
Message-ID: <[email-masked]>

The IESG has approved the following document:

- 'RTP Payload Format for ITU-T Recommendation G.711.1 '
   <draft-ietf-avt-rtp-g711wb-03.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group.

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g711wb-03.txt

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The International Telecommunication Union (ITU-T) Recommendation
G.711.1 is an embedded wideband extension of the Recommendation G.711
audio codec. This document specifies a payload format for
packetization of G.711.1 encoded audio signals into the Real-time
Transport Protocol (RTP).

Working Group Summary
Was there anything in WG process that is worth noting?
For example, was there controversy about particular
points or were there decisions where the consensus was particularly
rough?

This is a reasonably standard RTP payload format. The document has been
reviewed by the AVT working group and all open issues were addressed

Document Quality
Are there existing implementations of the protocol?
Have a significant number of vendors indicated their plan
to implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive
issues? If there was a MIB Doctor, Media Type or other
expert review, what was its course (briefly)? In the case of a Media
Type review, on what date was the request posted?

Media type review was conducted starting May 7th 2008, with no
objections raised. Vendors who contributed to the G.711.1 specification
have indicated their intent to support this payload.

Personnel
Who is the Document Shepherd for this document? Who is
the Responsible Area Director?

Roni Even is the document shepherd.

The responsible area director is Cullen Jennings.

RFC Editor Note

Section 4.1 2nd paragraph

OLD
  The 5 most significant bits are reserved for further extension and
  MUST be set to zero.

NEW
  The 5 most significant bits are reserved for further extension and
  MUST be set to zero and MUST be ignored by receivers.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

---
Section 4.2 1st paragraph

OLD
  After this payload header, the audio frames are packed in order of
  time, that is, oldest first.  All frames MUST be of the same mode,
  indicated by the MI field of the payload header.

NEW
  After this payload header, the consecutive audio frames are packed in
order of
                                 ^^^^^^^^^^^^
  time, that is, oldest first.  All frames MUST be of the same mode,
  indicated by the MI field of the payload header.
---

---
Section 8 last paragraph

OLD
  This payload format and the G.711.1 encoding do not exhibit any
  significant non-uniformity in the receiver-end computational load and
  thus are unlikely to pose a denial-of-service threat due to the
  receipt of pathological datagrams.

NEW
  This payload format and the G.711.1 encoding do not exhibit any
  significant non-uniformity in the receiver-end computational load and
  thus are unlikely to pose a denial-of-service threat due to the
  receipt of pathological datagrams.  In addition, they do not contain
any

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  type of active content such as scripts.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

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

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

End of avt Digest, Vol 54, Issue 32
***********************************
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Greg Herlein" <[email-masked]>
Date: Wed, 22 Oct 2008 17:28:09 -0700

Aaron,

RFC-2250 says:

   For MPEG2 Transport Streams the RTP payload will contain an integral
   number of MPEG transport packets.  To avoid end system
   inefficiencies, data from multiple small MTS packets (normally fixed
   in size at 188 bytes) are aggregated into a single RTP packet.  The
   number of transport packets contained is computed by dividing RTP
   payload length by the length of an MTS packet (188).

   For MPEG2 Program streams and MPEG1 system streams there are no
   packetization restrictions; these streams are treated as a packetized
   stream of bytes.

So if you use transport streams you just encapsulate the whole
transport stream into the RTP stream - and the audio is in the
transport stream.  Simple.

If the transport stream uses H.264 to encode the video it's stream
type will be set accordingly.  The RTP layer is unaware of this.

At least, this is how it works on the one implementation that I know
of.  :)  I'd love to hear what others have to say.

Greg