|
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 From: Orit Levin
[mailto:oritl at microsoft.com] 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: avt-bounces at ietf.org [avt-bounces at ietf.org]
On Behalf Of Roni Even [ron.even.tlv at gmail.com] 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 avt at ietf.org https://www.ietf.org/mailman/listinfo/avt