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:51 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 8D27021F8BCF for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 15:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 T49fQ3AFz0P7 for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 15:51:09 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8021F8BCD for <video-codec@ietf.org>; Tue, 4 Dec 2012 15:51:09 -0800 (PST)
Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BCA46F20E1 for <video-codec@ietf.org>; Tue, 4 Dec 2012 15:51:08 -0800 (PST)
Message-ID: <50BE8C6C.8010200@xiph.org>
Date: Tue, 04 Dec 2012 15:51:08 -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: <C15918F2FCDA0243A7C919DA7C4BE994060E8796@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE994060E8796@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:51:09 -0000

Ali C. Begen (abegen) wrote:
>> 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.
>
> That is possible but that will introduce potentially long delays (which we
> don't want in video-codec).

I wasn't thinking of going beyond the most recent frame. That 
restriction would limit your ability to make things truly CBR (or 
conversely to keep truly consistent quality), but I think it would be a 
step in the right direction. It might work very well with a 
hierarchical-P or P/B reference frame structure.

v2.23.0 | Report a Bug | By Email