IETF Logo Mail Archive

Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00

"Timothy B. Terriberry" <tterribe@xiph.org> Tue, 04 December 2012 23:42 UTC

Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38321F8BCD for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 15:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level:
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q73hIgvuA7q for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 15:42:02 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC821F8BCA for <video-codec@ietf.org>; Tue, 4 Dec 2012 15:42:02 -0800 (PST)
Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 88D8DF210B for <video-codec@ietf.org>; Tue, 4 Dec 2012 15:42:02 -0800 (PST)
Message-ID: <50BE8A4A.4050907@xiph.org>
Date: Tue, 04 Dec 2012 15:42:02 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: "video-codec@ietf.org" <video-codec@ietf.org>
References: <C15918F2FCDA0243A7C919DA7C4BE994060E86FF@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE994060E86FF@xmb-aln-x01.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/video-codec>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 23:42:03 -0000

Ali C. Begen (abegen) wrote:
>> This is something I hope rmcat will explore in more detail, though I
>> recognize it's hard to evaluate. One idea that occurs to me is actually
>> using VBR video and padding it with FEC data to get something closer to
>> CBR. That might actually be a better use of the bits.
>
> I doubt it. If a frame (or slide) has less bits due to VBR encoding, that
> means it is easier to encode it, which implies it is less important than
> the one that has more bits. FEC'ing these frames will not make the stream
> CBR.

Well, the idea would be to put the redundant information from the larger 
(more important) frames in space you didn't use in the smaller frames, 
to protect against lost packets in those frames.

v2.23.0 | Report a Bug | By Email