[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: Carrying SMPTE time-codes in RTP streams, discussion email
Hi John,
On Friday, February 11, 2005 3:53 PM, John Lazzaro wrote:
> On Feb 11, 2005, at 3:11 PM, Link, Brian wrote:
> > Part of what needs to be checked, is
> > that the SMPTE time stamps that are "striped" on a hard
> disk with the
> > audio (one SMPTE time stamp value per AC-3 audio frame) are all
> > correctly lined up with the video so that the multiplex
> operation will
> > work correctly. The mapping between RTP time stamps and SMPTE time
> > stamps isn't sufficient because it requires the receiver to
> synthesize
> > SMPTE time stamps between mapping points, which may mask
> errors in the
> > source.
>
> Let's assume the sender of the RTP stream has access to the
> hard disk, with its SMPTE time stamp stripe. If the sender
> makes sure that the mapping it sends in the RTCP packets is
> such that for every AC-3 audio frame, a synthesized timestamp
> by the receiver will always exactly match the time code on
> the hard disk, then it would seem to be impossible to mask
> errors -- the synthesis algorithm would always yield the
> timestamp that exists on the stripe.
>
> Am I missing something here?
Technically, what you propose here works. But it goes against the
testing principle of "minimize the number of steps where something could
go wrong." There's value in knowing that the data in the original is
copied directly to the network rather than being translated. That
consideration is quite important in the market targeted by this QA
application.
Note that this solution breaks down if the receiver misses a mapping
packet that indicated a boundary in the mapping parameters.
> > 3. For that matter, what's the advantage of putting these
> mappings in
> > separate RTCP packets? Instead, encapsulating them in the
> same packet
> > as the media data instead would give a greater assurance that the
> > receiver is associating the right SMPTE time value with the media
> > data.
>
> It sounds like you're suggesting the requirements of your
> application require a SMPTE timestamp on each RTP packet ...
> as my comment above shows, I don't see why that would be true
> (yet) ... but lets assume it is.
>
> In this case, the general-purpose options would be doing it
> as an RTP profile (i.e. each RTP header has an extra N octets
> for a SMPTE
> timecode)
> or as an RTP header extension. Traditionally, I had thought
> extensions were meant for experimental deployments, not
> standards-track items ... so lets assume an RTP profile for
> the moment.
>
> Would this sort of profile result in full functionality for
> your application?
> Or did the timestamps in your AC-3 payload format
> (implicitly) do more than simply associate the RTP timestamp
> of each packet with a SMPTE time stamp?
This isn't quite right. The timestamps don't associate an RTP timestamp
with a SMPTE timestamp. They associate a video frame with the audio
sample that is supposed to be presented at the same time. This is so
that a DVD is printed correctly by muxing the audio and video together
with correct Presentation Time Stamps. The SMPTE time stamps are
generated externally to the RTP system and are passed back out of the
RTP system and used to sync external hardware devices together. The
association with RTP time stamps is coincidental in this application:
RTP is a convenient mechanism for moving the audio with associated SMPTE
time stamps across a DVD post-production facility.
> > 4. Note that regardless of where the mapping exists, there
> needs to
> > be a mechanism so that the receiver can determine if and
> when it has
> > missed a mapping packet (and therefore a run boundary) so it knows
> > that any further synthesized values are invalid.
>
> Phrased in this way, RTP over a network that can lose packets
> might not satisfy your requirement -- what if a packet
> sequence is lost that contains two run boundaries? Or are
> you assuming you terminate the session if an RTP sequence
> number break is detected?
That's right. The loss of any packet in this application is a
catastrophic failure and the QA test must be re-run. As you note, this
failure is easy to detect using the sequence number. If the mapping
scheme is used for this application, a way to determine when a mapping
packet is lost is also needed.
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>
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
-----------------------------------------
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