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

From: Dave Singer <[email-masked]>
Date: Wed, 16 Mar 2005 16:49:20 -0800

At 10:58 AM +0000 2/6/05, Colin Perkins wrote:
>Brian,
>
>On 20 Jan 2005, at 18:21, Link, Brian wrote:
>>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?
>
>One possibility might be to standardise a new RTP profile, with 
>additional header fields (e.g. as is being done for the RTP profile 
>for TFRC). Another might be a standard header extension, or new RTCP 
>packet types.
>
>>And from a procedural perspective, what is needed?
>
>Initially, a draft explaining the problem, and some analysis of why 
>is can't be solved using RTP + existing signalling mechanisms.
>

Something that would REALLY help would be an extensible 
use-of-the-x-bit feature.  Something like:

out-of-band, do an XML-style namespace mapping from small integers to 
fully-qualified XML-like names

qt -> http://www.apple.com/quicktime
wm -> http://www.microsoft.com/windowsmedia
smpte -> http://www.smpte.org/12M

1 -> qt:preroll
2 -> wm:overlay
3 -> smpte:timecode
4 -> qt:somethingelse

then each packet could have:

uint(1) x-bit;
...
var extension = x-bit;
while (extension) {
   uint(1) next-x-bit;
   uint(7) tag;
   uint(8) data-length;
   uint(8) data[data-length];
   extension = next-x-bit;
}

This assumes there won't be more than 128 different pieces of 
extension data, and that any extension data is less than 256 bytes. 
which ought to be true.  It allows essentially unlimited, 
collision-free, unregistered extension.

then we could define smpte time-codes as one of those extensions and be done...
-- 
David Singer
Apple Computer/QuickTime

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

---

From: "Link, Brian" <[email-masked]>
Date: Wed, 23 Mar 2005 13:32:30 -0800

Hi Colin,

> As you note, the SMPTE time code is optional in the AC-3 
> format. For that reason, I'd strongly prefer to remove it 
> now, adding something later once we're done a thorough 
> requirements analysis and understood what problem is being 
> solved, and why it can't be solved using the standard RTP mechanisms.

The sense in which the data is optional, is that it need not be included
in the payload for applications that don't need it. There is no overhead
for those applications. For the application I have in mind (QA for DVD
mastering), including the time stamp data is mandatory; the application
is disabled without it.

The discussion on the reflector has supported idea that this use of time
stamps is a special case and not likely to be widely used. (For example,
within DLNA, it is specified that the time stamps be turned off.) I
think it is both easier to design the general case for SMPTE time stamps
and easier to accomplish this application, if this special case is kept
out of the general scheme and incorporated in the payload format.

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: Sunday, February 06, 2005 2:50 AM
> To: Link, Brian
> Cc: [email-masked]
> Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt
> 
> Hi Brian,
> 
> [Apologies for the slow reply]
> 
> As you note, the SMPTE time code is optional in the AC-3 
> format. For that reason, I'd strongly prefer to remove it 
> now, adding something later once we're done a thorough 
> requirements analysis and understood what problem is being 
> solved, and why it can't be solved using the standard RTP mechanisms.
> 
> Colin
> 
> 
> 
> On 26 Jan 2005, at 05:10, Link, Brian wrote:
> > I'd like to argue for leaving the SMPTE time stamps in the AC-3 
> > payload.
> >
> > -The data is optional, so inclusion of the capability comes 
> at no cost 
> > for most uses.
> >
> > -As I've done more investigation into SMPTE time code and 
> time stamps, 
> > I've realized that the time stamps specified in SMPTE 339M (and 
> > proposed in this payload format) were specifically designed 
> for AC-3 
> > to address the need to synchronize audio frames with video frames 
> > which run at unrelated frame rates. It may be possible to 
> generalize 
> > the use of this representation to include other frame-based audio 
> > formats, but that has not been done or needed before. It is 
> needed for 
> > AC-3 for the application of DVD mastering.
> >
> > -I support finding a general solution for pro applications, 
> but in the 
> > meantime, I think there would be value in enabling this 
> time format in 
> > the AC-3 payload since it has already been successfully used in 
> > products.
> >
> > Would this be acceptable?
> >
> > Regards (from cold Helsinki with poor network access), Brian
> 
> 

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