[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RTP profile for pro apps [was: draft-ietf-avt-rtp-ac3-01.txt]
I agree with John about taking that "serious look" and considering
an RTP profile for the pro world.
I would like to revisit some of the topics I raised 4 years ago
with draft-harrison-avt-precision-av-00.txt . I think this needs
to go farther than just tacking SMPTE timecode (with all its
notorious "features") into a header field.
Cheers,
Chuck Harrison
Far Field Associates, LLC
lazzaro wrote:
>
> On Jan 20, 2005, at 10:21 AM, Link, Brian wrote:
> > Colin,
> >
> > I'm open to this idea, and I note the support from Dave and John. I'm
> > not familiar enough with the infrastructure of RTP to know the possible
> > mechanisms for associating data with any payload format. How would this
> > be done? And from a procedural perspective, what is needed?
>
> I think we should consider taking a serious look at the range of
> RTP pro uses for SMPTE time code, to see if there is real value in
> having time code inline with the media in RTP (as opposed to
> sent over a secondary channel, like the signalling solution
> Colin proposes). If there is, then I think that real value will
> exist for a range of payload formats, not just AC3, and so we
> should think hard about an RTP profile for pro uses. If in
> fact the signalling solution is the right one, then a general purpose
> SMPTE time code signalling mechanism is something we
> should think hard about. But duplicating time code functionality
> in each payload format that might be of interest to pros
> seems to be sub-optimal to me ... part of the benefit of
> RTP/SDP is that the header/parameters includes common features,
> so that each payload format doesn't have to reinvent the wheel.
>
> >
> > Regards,
> > Brian
> >
> >
> > ---
> > Brian Link
> > Dolby Laboratories, 100 Potrero Ave., San Francisco, CA 94103
> > phone: 415-558-0324 fax: 415-863-1373
> > email: bdl at dolby.com alt email: link at ieee.org
> >
> >
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp at csperkins.org]
> > Sent: Thursday, January 20, 2005 6:56 AM
> > To: Link, Brian
> > Cc: avt at ietf.org
> > Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt
> >
> > Brian,
> >
> > This use of SMPTE time codes would seem more general than for the AC3
> > format. If this feature is going to be useful, would it make sense to
> > take it out of the AC3 format, and define a general mechanism that
> > could
> > be used by any RTP payload format?
> >
> > Colin
> >
> >
> >
> > On 19 Jan 2005, at 15:31, Link, Brian wrote:
> >> Hi Colin,
> >>
> >> Thanks for these comments and the editorial ones, too. I'll
> >> incorporate the 'ptime' and 'SDP offer/answer' suggestions you have
> > made.
> >>
> >> I'd like to offer some motivation for including SMPTE time code. The
> >> SMPTE time code feature is not needed by DLNA for their consumer
> >> application of A/V streaming over a home network. However, while I was
> >
> >> updating the I-D, I learned that AC-3 over RTP is also used in a
> >> professional application and I'd like the payload format to
> >> accommodate that, too.
> >>
> >> The particular professional application is quality control for the
> >> mastering of DVDs. The audio and video are stored on separate storage
> >> media, each "striped" with SMPTE time code so that in the final
> >> mastering step they can be correctly multiplexed together into an MPEG
> >
> >> stream. Prior to the multiplexing step, there is a quality control
> >> step where the audio and video are auditioned together to make sure
> >> the multiplex will be performed correctly. The purpose of the audition
> >
> >> is to check the combination of the audio and video data together with
> >> the time code as stored on disk. If, instead, the time code is
> >> discarded by the server and regenerated at the client from the RTP
> >> timestamp, the value of this test is negated. Any errors in the SMPTE
> >> time on the storage medium are replaced by the regenerated time code.
> >>
> >> It's also interesting to note that the SMPTE time code is not used to
> >> synchronize two RTP streams. In this case the audio, in an RTP stream,
> >
> >> is synchronized with an external video device through a hardware
> >> interface. RTP is being used as a "drop in" replacement for an
> >> existing audio transport in a heterogeneous facility. The video stream
> >
> >> is not
> >> (necessarily) carried over RTP. Also, the SMPTE time code for the
> >> audio is not generated as the RTP stream is created, instead it was
> >> created earlier and in an external part of the overall system.
> >>
> >> For most end-consumer-type applications, SMPTE time code is redundant,
> >
> >> so it is optional in the payload header. For professional
> >> applications, it is not necessarily redundant (and that market often
> >> demands redundancy, anyway) and is already used by products in the
> >> field, so I feel SMPTE time code is needed, as an option.
> >>
> >> Regards,
> >> Brian
> >>
> >> ---
> >> Brian Link
> >> Dolby Laboratories, 100 Potrero Ave., San Francisco, CA 94103
> >> phone: 415-558-0324 fax: 415-863-1373
> >> email: bdl at dolby.com alt email: link at ieee.org
> >>
> >>
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:csp at csperkins.org]
> >> Sent: Saturday, January 15, 2005 6:57 AM
> >> To: Link, Brian
> >> Cc: avt at ietf.org
> >> Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt
> >>
> >> Brian,
> >>
> >> On 3 Jan 2005, at 18:39, Link, Brian wrote:
> >>> As the quoted announcement states, I have revived the RTP payload
> >>> format I-D for AC-3. I have made a number of changes to take into
> >>> account comments that had previously been offered, to simplify the
> >>> draft, and to add some time code functionality that is used in some
> >>> products.
> >>>
> >>> An industry consortium called the Digital Living Network Alliance
> >>> (DLNA)
> >>> plans to stream AC-3 over RTP in some of its home networking
> >>> applications. In order for DLNA to reference the payload format in
> >>> this document (instead of publishing their own), it will need to be
> >>> published in a relatively short time. I will very much appreciate it
> >
> >>> if interested people could review and comment on this I-D to move it
> >>> along quickly.
> >>
> >> Mostly this looks good, although I have a couple of technical
> > concerns:
> >>
> >> - Including a SMPTE time code in each packet is unusual, and
> >> redundant
> >> with the RTP timestamp (which is mapped to an NTP-format timestamp
> >
> >> via
> >> RTCP SR packets) in many cases. Is it possible to use the RTP
> >> timestamp
> >> instead, possibly with a signalled mapping from SMPTE time code to
> >
> >> an
> >> NTP format timestamp in the SDP during session setup?
> >>
> >> - The second is that the definition of "ptime" is unusual. I think
> > it
> >> would be better as:
> >>
> >> ptime: The duration of time in milliseconds represented by each
> >> AC-3
> >> frame. This corresponds to the duration of each RTP packet in
> > cases
> >> where fragmentation is not used.
> >>
> >> without trying to define what it means for fragments.
> >>
> >> - Finally, the draft should define how SDP is used in offer/answer
> >> mode to
> >> negotiate parameters. It should also describe how the MIME
> >> parameters are
> >> copied into the SDP (section 5.1 of RFC 3557 is a good example).
> >>
> >> I've also sent a few minor editorial comments privately.
> >>
> >> Colin
> >>
> >>
> >> -----------------------------------------
> >> This message (including any attachments) may contain confidential
> >> information intended for a specific individual and purpose. If you
> >> are not the intended recipient, delete this message. If you are not
> >> the intended recipient, disclosing, copying, distributing, or taking
> >> any action based on this message is strictly prohibited.
> >>
> >>
> >> _______________________________________________
> >> Audio/Video Transport Working Group
> >> avt at ietf.org
> >> https://www1.ietf.org/mailman/listinfo/avt
> >>
> >
> >
> > -----------------------------------------
> > This message (including any attachments) may contain confidential
> > information intended for a specific individual and purpose. If you
> > are not
> > the intended recipient, delete this message. If you are not the
> > intended
> > recipient, disclosing, copying, distributing, or taking any action
> > based on
> > this message is strictly prohibited.
> >
> >
> >
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt