Subject: [AVT] RFC 2198 - Transmission of Redundant Audio Data

From: "Jagan Mohan" <[email-masked]>
Date: Mon, 12 Jan 2009 23:21:47 +0530

Hi,

  While sending RTP packets, say, 1st packet sent has timestamp X, 2nd
packet sent has timestamp X+20, 3rd packet sent has timestamp X+40.
  On what basis, does the sender decide whether the redundant audio data of
1st RTP packet has to be sent in the 2nd RTP packet or the 3rd RTP packet or
the 4th RTP packet?

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Jan 2009 09:37:16 -0500

Jagan,

I do not think the spec is clear on how to handle these initial packets.
However, my expectation is that the redundant data from packet 1 would be
present in packet 2 through packet n (ever how many times you wish to
replicate the data . probably no more than two copies is useful for audio
before it becomes stale).  Likewise, I would expect the primary audio in
packet to be duplicated to packet 3 through packet n+1.

I do not think there is a hard and fast rule on this, but you just have to
consider how the decoder would react: it will have a buffer and if it needs
to play an audio sample/frame and it is not available, then you lose the
benefit of the redundancy.  As such, I would provide the primary audio as
quickly as possible and repeat it as long as reasonable.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jagan
Mohan
Sent: Monday, January 12, 2009 12:52 PM
To: [email-masked]
Subject: [AVT] RFC 2198 - Transmission of Redundant Audio Data

Hi,

Thanks,
Jagan

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 Jan 2009 15:11:00 +0000

Also, if the sender knows the distribution of loss events, for  
example via an RTCP XR report, it can make an intelligent choice on  
when to send redundant data. For example, if single packet losses  
predominate, sending a redundant copy of the data in the packet  
following the original makes a lot of sense; however if you see lots  
of two-packet bursts, then it might make sense to delay the redundant  
copy and send it two packets after the original data.

This requires the receiver to be flexible in its playout buffering,  
but that's not a bad thing.

Colin

On 13 Jan 2009, at 14:37, Paul E. Jones wrote:

> Jagan,
>
>
>
> I do not think the spec is clear on how to handle these initial  
> packets.  However, my expectation is that the redundant data from  
> packet 1 would be present in packet 2 through packet n (ever how  
> many times you wish to replicate the data … probably no more than  
> two copies is useful for audio before it becomes stale).  Likewise,  
> I would expect the primary audio in packet to be duplicated to  
> packet 3 through packet n+1.
>
>
>
> I do not think there is a hard and fast rule on this, but you just  
> have to consider how the decoder would react: it will have a buffer  
> and if it needs to play an audio sample/frame and it is not  
> available, then you lose the benefit of the redundancy.  As such, I  
> would provide the primary audio as quickly as possible and repeat  
> it as long as reasonable.
>
>
>
> Paul
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Jagan Mohan
>   While sending RTP packets, say, 1st packet sent has timestamp X,  
> 2nd packet sent has timestamp X+20, 3rd packet sent has timestamp X 
> +40.
>   On what basis, does the sender decide whether the redundant audio  
> data of 1st RTP packet has to be sent in the 2nd RTP packet or the  
> 3rd RTP packet or the 4th RTP packet?
>
> Thanks,
> Jagan
>

-- 
Colin Perkins
http://csperkins.org/