Subject: [AVT] using RTCP for sending payload information in versteeg and levin rapid synchronization drafts

From: "Roni Even" <[email-masked]>
Date: Sat, 15 Nov 2008 18:44:41 +0200

Hi guys,

Draft
http://tools.ietf.org/id/draft-versteeg-avt-rapid-synchronization-for-rtp-01
.txt suggests a new use for RTCP feedback messages.

More specifically in section 7.2.1. This message is used to carry
information from the payload that is not available very often as described
in the paragraph. My understanding is that there will be a similar case with
H.264 parameter sets which are not sent with every I-frame and are required
in order to decode the stream. 

For H.264 we suggested in 3984bis that a codec refresh point will include
the parameter sets, this is sent as a response to  FIR CCM request (the
video switch case). I think that here they would not want to retransmission
server to send FIR back to the multicast source.

A similar issue is in
http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt that in section 7
have for each message an extension field that is left open without
specifying what it will be used for and can be used for similar information.

The general problem is the same in both cases since some of the information
is available early in the media stream and is not repeated as often as I
frames but still is needed for synchronization. The problem of joining
mid-stream is similar to the video switch case in MCUs.

I am looking for feedback if this is a good use for RTCP based on the RTCP
guideline drafts, and if not any are there any suggestions. 

Thanks

Roni Even

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

---

From: Orit Levin <[email-masked]>
Date: Sat, 15 Nov 2008 12:21:41 -0800

Roni, all,

Just wanted to clarify that in the http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt  the proposed TLV extensions mechanism hasn't been introduced to carry any media/CODEC specific information. In fact, the proposed mechanism is 100% media/data agnostic.  In our view, for further optimization, the MPEG-2 structures could be (re)arranged by the server(s), but this doesn't require IETF standardization because it is transparent both to the defined mechanism and to the receiver.

The reason for introducing the extensions mechanism was to accommodate other standardization bodies (such as ATIS and DVB) that are working on commercial video/TV applications and are planning to use this IETF mechanism in their application architectures. These architectures include their own security frameworks and the protocol details to carry them.

Probably, explicitly saying in the next version of the draft that the TLV extensions MUST not carry any media/CODEC specific information will clarify the point and address the expressed concern.

Thanks,
Orit.
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Roni Even [[email-masked]]
Sent: Saturday, November 15, 2008 8:44 AM
To: [email-masked]
Subject: [AVT] using RTCP for sending payload information in versteeg and levin rapid synchronization drafts

Hi guys,
Draft http://tools.ietf.org/id/draft-versteeg-avt-rapid-synchronization-for-rtp-01.txt suggests a new use for RTCP feedback messages.
More specifically in section 7.2.1. This message is used to carry information from the payload that is not available very often as described in the paragraph. My understanding is that there will be a similar case with H.264 parameter sets which are not sent with every I-frame and are required in order to decode the stream.
For H.264 we suggested in 3984bis that a codec refresh point will include the parameter sets, this is sent as a response to  FIR CCM request (the video switch case). I think that here they would not want to retransmission server to send FIR back to the multicast source.

A similar issue is in http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt that in section 7 have for each message an extension field that is left open without specifying what it will be used for and can be used for similar information.

The general problem is the same in both cases since some of the information is available early in the media stream and is not repeated as often as I frames but still is needed for synchronization. The problem of joining mid-stream is similar to the video switch case in MCUs.

I am looking for feedback if this is a good use for RTCP based on the RTCP guideline drafts, and if not any are there any suggestions.
Thanks
Roni Even

---

From: "Roni Even" <[email-masked]>
Date: Sun, 16 Nov 2008 20:18:32 +0200

Orit,

This is what bother me since you do not specify what the message will be
used for.  http://tools.ietf.org/html/draft-ietf-avt-rtcp-guidelines-00
tries to give some guidelines

Roni

From: Orit Levin [mailto:[email-masked]] 
Sent: Saturday, November 15, 2008 10:22 PM
To: Roni Even; [email-masked]
Subject: RE: [AVT] using RTCP for sending payload information in versteeg
and levin rapid synchronization drafts

Roni, all,

Just wanted to clarify that in the
<http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt>
http://tools.ietf.org/id/draft-levin-avt-rtcp-burst-00.txt  the proposed TLV
extensions mechanism hasn't been introduced to carry any media/CODEC
specific information. In fact, the proposed mechanism is 100% media/data
agnostic.  In our view, for further optimization, the MPEG-2 structures
could be (re)arranged by the server(s), but this doesn't require IETF
standardization because it is transparent both to the defined mechanism and
to the receiver. 

The reason for introducing the extensions mechanism was to accommodate other
standardization bodies (such as ATIS and DVB) that are working on commercial
video/TV applications and are planning to use this IETF mechanism in their
application architectures. These architectures include their own security
frameworks and the protocol details to carry them.

Probably, explicitly saying in the next version of the draft that the TLV
extensions MUST not carry any media/CODEC specific information will clarify
the point and address the expressed concern.

Thanks,

Orit.

  _____  

From: [email-masked] [[email-masked]] On Behalf Of Roni Even
[[email-masked]]
Sent: Saturday, November 15, 2008 8:44 AM
To: [email-masked]
Subject: [AVT] using RTCP for sending payload information in versteeg and
levin rapid synchronization drafts

Hi guys,

Draft

 

A similar issue is in

Thanks

Roni Even

---

From: "Roni Even" <[email-masked]>
Date: Sun, 16 Nov 2008 20:21:11 +0200

Hi Orit,

Still your draft should address the issue presented by the Versteeg draft
about what does the synchronization point include and how do you send it if
it cannot be sent as a retransmission. Examples are the MPEG2 information
and H.264 parameter sets.

Roni

Roni, all,

Thanks,

Orit.

  _____  

Hi guys,

Draft

 

A similar issue is in

Thanks

Roni Even