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

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Apr 2005 16:35:28 +0100

Hi,

[Apologies for the slow response on this]

On 23 Mar 2005, at 21:32, Link, Brian wrote:
>> 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.)

Agreed.

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

I'm not sure I agree. SMPTE time codes will, I suspect, likely always 
be a corner case for RTP formats. Given that we have an application 
that uses them, now is a good time to define a mechanism to convey 
these time codes independent of the payload format. Otherwise, it'll 
never get done, and we'll be stuck with payload-specific hacks.

Colin

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