Re: [AVT] RTP profile for pro apps [was: draft-ietf-avt-rtp-ac3-01.txt]

[Colin Perkins <[e-mail]>]

Chuck,

Indeed. I would suggest that the first step is for those interested in 
this subject to write an internet-draft summarising the issues, so the 
group can get a common understanding of what problem is to be solved 
and why RTP does not solve it currently. If there is an issue to be 
addressed, we should try to address it in a way that works across 
payload formats, rather than in an ad-hoc solution for a particular 
format.

Colin



On 22 Jan 2005, at 17:02, Chuck Harrison wrote:
> 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: [phone]  fax: [phone]
>>> email: [e-mail]   alt email: [e-mail]
>>>
>>>
>>> -----Original Message-----
>>> From: Colin Perkins [mailto:[e-mail]]
>>> Sent: Thursday, January 20, 2005 6:56 AM
>>> To: Link, Brian
>>> Cc: [e-mail]
>>> 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: [phone]  fax: [phone]
>>>> email: [e-mail]   alt email: [e-mail]
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Colin Perkins [mailto:[e-mail]]
>>>> Sent: Saturday, January 15, 2005 6:57 AM
>>>> To: Link, Brian
>>>> Cc: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
>


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt