Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt

From: "Link, Brian" <[email-masked]>
Date: Thu, 20 Jan 2005 10:21:31 -0800

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?

Regards,
Brian

---
Brian Link
Dolby Laboratories, 100 Potrero Ave., San Francisco, CA 94103
phone: 415-558-0324  fax: 415-863-1373
email: [email-masked]   alt email: [email-masked]

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, January 20, 2005 6:56 AM
To: Link, Brian
Cc: [email-masked]
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: [email-masked]   alt email: [email-masked]
>
>
> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Saturday, January 15, 2005 6:57 AM
> To: Link, Brian
> Cc: [email-masked]
> 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
> [email-masked]
> 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.

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

---

From: lazzaro <[email-masked]>
Date: Thu, 20 Jan 2005 10:33:49 -0800

> 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.

> are not
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

---

From: Chuck Harrison <[email-masked]>
Date: Sat, 22 Jan 2005 09:02:52 -0800

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