Re: [AVT] Re: Audio/Video and packet loss

"Marshall Eubanks" <marshall.eubanks@gmail.com> Mon, 24 April 2006 23:22 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAOF-0004jY-3g; Mon, 24 Apr 2006 19:22:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAOD-0004jL-MN for avt@ietf.org; Mon, 24 Apr 2006 19:22:45 -0400
Received: from nz-out-0102.google.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYAOB-0001cg-9r for avt@ietf.org; Mon, 24 Apr 2006 19:22:45 -0400
Received: by nz-out-0102.google.com with SMTP id 40so1100535nzk for <avt@ietf.org>; Mon, 24 Apr 2006 16:22:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ggdLXijV908ubI9RHkSzZI1fTCPgeqd2+xDVkEB0PFhrTA0jrbhEzl6xTgZ+BXhzDnpoMtlQnLYaj0ytihPwVucAZRtrZCtS0bjScKvhfvRM4gMCLjwKCQaXlXDawzeOxOH4lnkdAJ4goYGnQA9UHKeQ7o2RKoHlorJdVzhAEIg=
Received: by 10.36.126.16 with SMTP id y16mr1004574nzc; Mon, 24 Apr 2006 16:22:42 -0700 (PDT)
Received: by 10.36.42.16 with HTTP; Mon, 24 Apr 2006 16:22:42 -0700 (PDT)
Message-ID: <dcad22d80604241622w7b8e69efl21d22bd704924f2e@mail.gmail.com>
Date: Mon, 24 Apr 2006 19:22:42 -0400
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: lazzaro <lazzaro@eecs.berkeley.edu>
Subject: Re: [AVT] Re: Audio/Video and packet loss
In-Reply-To: <20DE4CC2-0A84-43B6-BC63-2568130B948D@eecs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <E1FXKWi-0006UC-4X@megatron.ietf.org> <20DE4CC2-0A84-43B6-BC63-2568130B948D@eecs.berkeley.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Here is one thing to amplify what Dave said  :

In many video codecs, some bits count for more than others. For example,
if you loose part of an I frame in a MPEG video encoding, the
entire Group of Pictures, potentially several seconds, may be corrupted.

Worse, the more important frames tend to be bigger, and thus in many cases
will be more likely to be dropped. A I frame may be split into a
number of packets (say, N) right at the MTU size, for example, while P
frames may be smaller than your MTU. If the packet loss is random, the
I frame right away is N times more likely to be lost, while some
networks, faced with congestion, may drop the biggest packets
preferentially.

Note, too, that the first P frame is more important than the last one in a GOP.

In many audio codecs, each packet is more or less equal in importance,
and of more or less equal size.

So, I have had cases where each I frame is 10 MTU sized packets, and
everything else is smaller than an MTU.  Total send rate was about 100
packets per second, the GOP being several seconds, The packet loss
rate might then be below 10^-2 with the audio sounding fine and the
video looking like a mess more or less continually.

Regards
Marshall

On 4/22/06, lazzaro <lazzaro@eecs.berkeley.edu> wrote:
>
> On Apr 22, 2006, at 9:00 AM, avt-request@ietf.org wrote:
> > In general, which type of media flow (audio or video) is more
> > affected with packet loss in an IP network ???
> >
> > Is this just dependant on the CODEC algorithm used by the audio or
> > video or maybe there is a media that is more sensitive for any
> > given reason ???
>
>
> In the limiting case of running a low-latency stream
> and hitting a long dropout (many hundreds of
> milliseconds), the video artifact (a still image) is
> much less objectionable that the audio artifact
> (a concealment algorithm hitting its limits of
> pleasantness, or a dropout).   So, I'd say audio,
> since its the limiting cases that tend to make
> customers say "this is junk".
>
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt