Subject: [AVT] Transmitting G729ab packets over network

From: Karthigeyan Vaidyanathan <[email-masked]>
Date: Wed, 28 Nov 2001 00:43:36 +0000 (GMT)

Hi all,
        I have a doubt regarding transmission of
G729ab encoded speech packet over the network. As you
all know there are three packet lengths in case of
G729ab speech codec viz, 80,15,0 bits. 
        My doubt is  should we transmit the packet
with zero length or should we avoid sending it into
the network?
        In case I avoid sending it, then there is a
discontinuity in the speech and in case I send it then
there is a unnecessary transmission of a the header
with packet lenght zero with no payload. How do I
handle this? It would be great if someone can help me
regarding this. Is there any standard that can be
followed?
Thanks
Karthik

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

---

From: "Miao, Kai" <[email-masked]>
Date: Thu, 29 Nov 2001 07:51:57 -0500

Both methods will waste memory space. What should be done is to develop a
standard file format which does not contain silence frames but timing
information, so that all the silence frames can be recovered during
playback. Anything exists in this regard?

Kai Miao

-----Original Message-----
From: Simao Campos-Neto [mailto:[email-masked]]
Sent: Wednesday, November 28, 2001 9:33 PM
To: Jeff Meunier
Cc: AVT WG
Subject: Re: [AVT] Transmitting G729ab packets over network

That actually is an interesting question...

One should distinguish the "simulation" of the codec operation from the
codec operation itself. The code in the recommendation (either G.729 or
G.723.1) puts out those 'non-transmitted' frames only because it is a
convenient way to convey the non-transmission periods to the decoder.
(It should be noted that the decoder has the Comfort Noise Generation
functionality as part of the relevant Annexes [B in G.729 and A in
G.723.1]). In a real time (interactive) system, those 'voice' frames are
simply not transmitted. In the RTP case, no packets relevant to these
frames are sent [counters updated as indicated by Steve].

In the case of playback of pre-recorded signals, as Jeff mentioned, one
can record the encoded signal with the no-transmit frames so that the
timers can be kept running properly (the player has to provide that
functionality), or alternatively one could record the RTP packets
themselves, which would contain the proper timing information, instead
of the no transmit frames. In signals with very long silences, I guess
that the latter would be more efficient (ie take up less storage space),
while for recorded announcements (where I would expect silences to be
kept to a minimum), the former is probably more efficient.

Cheers,
Simão.
--
Jeff Meunier wrote:
> 
> So, to properly render a stream like this, one has to program logic on the
> playback side that generates noise until the next packet arrives, and
> continue to generate noise (if applicable) if the timestamp indicates that
> the silence interval is still going?
> 
> We wondered about this at one point, but is was related to saving
g723/g729
> data to file and we just relied on using the non-standard 0 length frames.
> 
> FYI, I know in the ITU reference G.723.1 code, it will generate repeated
> silence frames (actually of length one byte) during such intervals. To be
> fully compliant with the RTP profile, I believe these should not be
> transmitted, right? (since they are not a recognized codec format type)
> 
> -- Jeff
> 
> Stephen Casner wrote:
> 
> > On Wed, 28 Nov 2001, Karthigeyan Vaidyanathan wrote:
> >
> >
> >>Yes, thats what I meant....voice packets, followed by
> >>a silence and then atleast 2 no transmission packets
> >>and then could be anything. My doubt was how to
> >>transmit the no trnasmission packets. Or in other
> >>words how to convey to the receive side that there is
> >>a no transmission packet without transmitting
> >>anything. Hope I have made my doubt clear.
> >>
> >
> > The RTP timestamp advances by the amount of time in the silence, but
> > the RTP sequence number advances only by one.  That is exactly why
> > both of those fields are present in the RTP header.
> >                                                       -- Steve
> >
> >
> --
> Jeff Meunier
> [email-masked]

-- 
========================================================================
Simão Ferraz de Campos Neto, Scientist *All comments strictly my own*
LMGT/COMSAT                            Tel:    +1-301-428-4516
22300 Comsat Drive                     Fax:    +1-301-428-9287
Clarksburg MD 20871 - USA           E-mail: [email-masked]
========================================================================
  ****** Practice random kindness and senseless acts of beauty ******
========================================================================

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 29 Nov 2001 14:58:29 +0100

Hi Kai Miao,

>playback. Anything exists in this regard?

I don't know much about file formats except that they do not seem to
be relevant to IETF/AVT.  And, is file size really the issue?  Hard drives
are cheap, transmission bit rate is not (yet).

With respect to transmission, I feel that we must clearly distinguish
between intentionally not coded (silcence) frames, and lost frames.
Silence frames (however they might be called and coded)  trigger
silence or comfort noise, lost frames trigger error concealment.  I
would be very reluctant to give up the possibility of the use of error
concealment just to save a few bits (or bytes).

Best regards

Stephan

---

From: Jeff Meunier <[email-masked]>
Date: Thu, 29 Nov 2001 08:22:31 -0600

Yes, the SID frames are 4 bytes, and transmission of them is spec'ed in the 
avt profile.

The standard specifies that the first SID frame of a given type be sent, 
but following frames that would normally generate identical SID frames are 
not sent. Therefore, as long as the silence is stationary, no more data 
needs to be sent until the noise changes or a full speech frame needs to be 
sent.

However, if you look closely at what the reference ITU code produces (at 
least in the G.723.1 stuff, not sure in 729), it will generate a 
non-standard, 1 byte "filler" packet for every frame following a 4 byte SID 
frame that would normally not be sent. You have to look for it, and it may 
not be in the 729 reference code, but it does raise issues. The AVT profile 
does not recognize these 1 byte "filler" packets, so if you pipe the ITU 
reference codec into an RTP stream, many existing RTP modules will not 
handle the stream.

-- Jeff

bino george wrote:

> Hello Jeff: 
>  I am little consfused.
> 
>>>FYI, I know in the ITU reference G.723.1 code, it
>>>will generate repeated silence frames
>>>(actually of length one byte) during suchintervals.
>>>To be fully compliant with the RTP profile, I
>>>believe these should not be transmitted, right?  
>>>
> 
> Are you dicussing about SID frames ? SID frames are 4
> bytes. But draft-ietf-avt-profile-new  giving the bit
> packing  to send SID frames.
> Can you just give some more information ?
> Thank you
> bino
>  
> 
> =====
> Bino George 
> 5588257 extn 210 
> "We have to define a new game instead of playing a game better"
> 
> Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
> http://geocities.yahoo.com/ps/info1
> 
> 
> 

-- 
Jeff Meunier
[email-masked]

---

From: "Miao, Kai" <[email-masked]>
Date: Thu, 29 Nov 2001 10:15:40 -0500

Hi Stephen,

What about devices which have no disks? Do we have any control where the
files will end up?

Kai

-----Original Message-----
From: Stephan Wenger [mailto:[email-masked]]
Sent: Thursday, November 29, 2001 8:58 AM
To: Miao, Kai
Cc: 'Simao Campos-Neto'; Jeff Meunier; AVT WG
Subject: RE: [AVT] Transmitting G729ab packets over network

Hi Kai Miao,

Best regards

Stephan