From nobody Mon Aug 3 15:49:55 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92FF1A8AD9 for ; Mon, 3 Aug 2015 15:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZamgLnrp_Nj for ; Mon, 3 Aug 2015 15:49:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AA71A8979 for ; Mon, 3 Aug 2015 15:49:52 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t73Mnndg098674 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 3 Aug 2015 17:49:50 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55BFF00D.7060405@nostrum.com> Date: Mon, 03 Aug 2015 17:49:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "video-codec@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Mo Zanaty \(mzanaty\)" Subject: [video-codec] Preliminary Minutes Posted X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 22:49:53 -0000 [as chair] I've posted preliminary minutes for the Prague NETVC meeting: https://www.ietf.org/proceedings/93/minutes/minutes-93-netvc Please review them, and send any proposed corrections to me and Mo. Thanks! /a From nobody Fri Aug 7 14:31:37 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD41A000F for ; Fri, 7 Aug 2015 14:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7RXz1WZ1l8J for ; Fri, 7 Aug 2015 14:31:33 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE5C1A0004 for ; Fri, 7 Aug 2015 14:31:33 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id F16AFC0545 for ; Fri, 7 Aug 2015 21:31:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEpg9Qce8kcT for ; Fri, 7 Aug 2015 21:31:32 +0000 (UTC) Received: from [10.252.26.3] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id DCC47C019E for ; Fri, 7 Aug 2015 21:31:32 +0000 (UTC) Message-ID: <55C523B4.2070903@xiph.org> Date: Fri, 07 Aug 2015 14:31:32 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: netvc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [video-codec] Add Daala's Entropy Coder to Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 21:31:36 -0000 As promised at the mic in Prague, here is a pull request to add Daala's entropy coder to Thor: https://github.com/cisco/thor/pull/8 It also fixes several crash bugs in the decoder on invalid streams. This does not actually convert any of the symbols over to using arithmetic coding, but it should now be possible to do that one symbol at a time, or to experiment with adding other features in Daala to Thor that rely on Daala's arithmetic coder. From nobody Wed Aug 12 08:59:43 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E747E1A8788 for ; Wed, 12 Aug 2015 08:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYjBeYWI8PD9 for ; Wed, 12 Aug 2015 08:59:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF1D1A0371 for ; Wed, 12 Aug 2015 08:59:34 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7CFxXw4054105 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 12 Aug 2015 10:59:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55CB6D65.4020601@nostrum.com> Date: Wed, 12 Aug 2015 10:59:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "video-codec@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [video-codec] For all interested contributors... X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 15:59:36 -0000 [as chair] In Prague, I was approached by a working group participant who was unsure about when and how to bring potential technical contributions to the NETVC working group. So, to be clear: if you have any ideas, or techniques, or implementations -- from the tiniest tweak to existing algorithms to a full-fledged and working video codec -- you are strongly encouraged to bring them to the working group as soon as you are able to do so [1]. Depending on the size and nature of your work, this could take the form of a simple email to the working group mailing list. More involved techniques can be contributed as internet-drafts. If you have code that you want to contribute, a pointer to a repository would be great. If you have proposals for improving the current codecs that have already been brought to the working group, this might take the form of pull requests against the Daala [2] and Thor [3] repositories (and followup mails to the mailing list). If you remain unsure about how to participate, please reach out directly to me or Mo, and we'll help you figure out how to get involved. Thanks! /a ____ [1] Assuming you can do so in accordance with BCP 78 and BCP 79 [2] https://github.com/xiph/daala [3] https://github.com/cisco/thor From nhwcodec@gmail.com Wed Aug 12 10:41:23 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE411A92EB for ; Wed, 12 Aug 2015 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocO0xQ0jjfAe for ; Wed, 12 Aug 2015 10:41:21 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100201A92ED for ; Wed, 12 Aug 2015 10:41:21 -0700 (PDT) Received: by oiev193 with SMTP id v193so13031373oie.3 for ; Wed, 12 Aug 2015 10:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ewD/WEQEqb/xoFbL0s8eLlDz4C5SkkPnJTIxmBClzI8=; b=MUcONdw4bzLWV5KBJjwimGQwS1bkgUw3y1gySaPnqjJipO1oZ4tjXh4w+sz0HIFAjs 6sf5BTZU8Mh8FlwEmBu1nTrEs31O26sodPt3g7Xys6Z+OMTL/xpT0SLIBG3vYPdsvkx+ m8SrpNImQCw+ObkOdx4xAekI6aCKkrbJRWCRyOjGPhCNTTHinS7t/WdCpE+R18MzgJqd VpnmA1byUCnCIU8kXfWD0ndUTmKqlQ6QcKr3vf63rbDhZt3+wHL6HfqWBfWCQKHOe1iD JscO4UzJDLfCUBSF3vfmwtfsQU2GUEvTKn22jlqgiqpHHqP5YFhWOdHHbrA4SftruFOZ 1mfA== MIME-Version: 1.0 X-Received: by 10.202.69.130 with SMTP id s124mr30101948oia.70.1439401280521; Wed, 12 Aug 2015 10:41:20 -0700 (PDT) Received: by 10.76.83.69 with HTTP; Wed, 12 Aug 2015 10:41:20 -0700 (PDT) Date: Wed, 12 Aug 2015 19:41:20 +0200 Message-ID: From: Raphael Canut To: video-codec@ietf.org Content-Type: multipart/alternative; boundary=001a113ddd2e03cb2b051d20ba8c Archived-At: Subject: [video-codec] NHW: a wavelet image codec X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 17:44:51 -0000 --001a113ddd2e03cb2b051d20ba8c Content-Type: text/plain; charset=UTF-8 Hello, New to this list, I am submitting the NHW codec to your working group.NHW is an experimental wavelet codec, that I presented on the Xiph Theora channel, it uses (normally) new non-patented techniques (it is normally royalty-free).Its main advantages are speed and neatness of image. Here are the links: demo page: http://nhwcodec.blogspot.com/ github repo: https://github.com/rcanut/nhwcodec If some parts could be selected for test in the NETVC project, would be just great.The main interesting parts are: a new fast wavelet transform, a multistage residual coding, and 3 new entropy coding schemes, which one is very efficient and very fast for quantized coefficients in video/image compression. Do not hesitate to let me know if I am submitting the right way. Many thanks. Cheers, Raphael --001a113ddd2e03cb2b051d20ba8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

New to this list, I am = submitting the NHW codec to your working group.NHW is an experimental wavel= et codec, that I presented on the Xiph Theora channel, it uses (normally) n= ew non-patented techniques (it is normally royalty-free).Its main advantage= s are speed and neatness of image.

Here are the links:
=C2= =A0
If some parts could be selected for test in the NETVC pro= ject, would be just great.The main interesting parts are: a new fast wavele= t transform, a multistage residual coding, and 3 new entropy coding schemes= , which one is very efficient and very fast for quantized coefficients in v= ideo/image compression.

Do not hesitate to let me know if= I am submitting the right way.

Many thanks.
Cheers,
Raphael
--001a113ddd2e03cb2b051d20ba8c-- From nobody Wed Aug 12 11:25:00 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441541AC406 for ; Wed, 12 Aug 2015 11:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XtfPfavXKk2 for ; Wed, 12 Aug 2015 11:24:54 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086271B2E4E for ; Wed, 12 Aug 2015 11:23:06 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id CF153C4C13; Wed, 12 Aug 2015 18:23:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fF7Zq8ifvdq; Wed, 12 Aug 2015 18:23:05 +0000 (UTC) Received: from [10.252.25.138] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id BA45FBFFEC; Wed, 12 Aug 2015 18:23:05 +0000 (UTC) Message-ID: <55CB8F09.50600@xiph.org> Date: Wed, 12 Aug 2015 11:23:05 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Raphael Canut , video-codec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] NHW: a wavelet image codec X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 18:24:59 -0000 Raphael Canut wrote: > If some parts could be selected for test in the NETVC project, would be > just great.The main interesting parts are: a new fast wavelet transform, > a multistage residual coding, and 3 new entropy coding schemes, which > one is very efficient and very fast for quantized coefficients in > video/image compression. Thanks for the contribution. There are several ways to go from here. One thing that would be interesting to know would be the performance compared to Daala and Thor. I would suggest working with Thomas Daede to make that happen. Another thing would be to try to integrate pieces of the other submissions into your codec or pieces of your codec into the other submissions, to see if you can demonstrate improvements. Some examples of how we have been doing this for Daala and Thor are here: https://review.xiph.org/874/ https://github.com/cisco/thor/pull/8 One potentially interesting area to experiment with might be be the prototype screencasting experiments in Daala presented at IETF 93: https://tools.ietf.org/html/draft-valin-netvc-l1tw-01 Those are using wavelets, so they might benefit from some of what you are doing. From nobody Wed Aug 12 12:15:53 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E221ACD3A for ; Wed, 12 Aug 2015 12:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B8SD7Fl8m8o for ; Wed, 12 Aug 2015 12:15:48 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E391ACD32 for ; Wed, 12 Aug 2015 12:15:48 -0700 (PDT) Received: by oiev193 with SMTP id v193so14499945oie.3 for ; Wed, 12 Aug 2015 12:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=WwbKazv5poDaw17nP2jC8T0DVUtbV9Gkyl/MllUyJpg=; b=vemQBuZPSfPGeTk2bkUm0hudJGneuYi3Q300ojIbWzuanQAtTMX/dWHBsmqDBPb9yy ddvBEvuR0WlTSMCwAbBxh69ypqCIrAVeiCe3wvj3HH/yxDf9xLpQwN55UA68KqpqtRRt JN6viW5G0Nu5AUlduU2hrG/n++Cc9hS+g4gpXMr05DDMAmUHajXDnUh3bvDeciHSDZqt +5Z8c7JmJnkAhDAD/mpzouSnVbFEWCVCVm96S6UOKT7QTAYRO0bpXB+bGf6sTbPYY/yH A2k2JzwKz0xAdeK58CjgIawoemTEDVaZICEGJxDSMBxF8b3VjgmJOnkIIuTt5pqULUqz 8w7w== MIME-Version: 1.0 X-Received: by 10.202.185.133 with SMTP id j127mr30531195oif.9.1439406947731; Wed, 12 Aug 2015 12:15:47 -0700 (PDT) Received: by 10.76.83.69 with HTTP; Wed, 12 Aug 2015 12:15:47 -0700 (PDT) In-Reply-To: <55CB8F09.50600@xiph.org> References: <55CB8F09.50600@xiph.org> Date: Wed, 12 Aug 2015 21:15:47 +0200 Message-ID: From: Raphael Canut Cc: video-codec@ietf.org Content-Type: multipart/alternative; boundary=001a113cddd6ce8ed6051d220bfd Archived-At: Subject: Re: [video-codec] NHW: a wavelet image codec X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 19:15:52 -0000 --001a113cddd6ce8ed6051d220bfd Content-Type: text/plain; charset=UTF-8 Hi Timothy, Many thanks for your answer. 2015-08-12 20:23 GMT+02:00 Timothy B. Terriberry : > > Thanks for the contribution. There are several ways to go from here. > > One thing that would be interesting to know would be the performance > compared to Daala and Thor. I would suggest working with Thomas Daede < > daede003@umn.edu> to make that happen. > > That's a good idea, but keep in mind that the NHW codec is optimized for neatness (and sharpness), so results for PSNR and SSIM are not good (there are more "errors").For now, the best way I have found to evaluate the NHW codec is to visually evaluate it.... It is also now optimized for mid/normal compression, there are no high compression settings... It's still experimental! > Another thing would be to try to integrate pieces of the other submissions > into your codec or pieces of your codec into the other submissions, to see > if you can demonstrate improvements. Some examples of how we have been > doing this for Daala and Thor are here: > > https://review.xiph.org/874/ > https://github.com/cisco/thor/pull/8 > > We can try first with the entropy coding for the wavelet coefficients.I would be really interested in trying Daala's arithmetic coder. One potentially interesting area to experiment with might be be the > prototype screencasting experiments in Daala presented at IETF 93: > https://tools.ietf.org/html/draft-valin-netvc-l1tw-01 > > Those are using wavelets, so they might benefit from some of what you are > doing. > I have read the draft, in my codec I am using 5/3 (and 9/7) wavelets.I have read that you are using tree coding like SPIHT and EZW.I would be interested in understanding more and trying this technique. Many thanks. Cheers, Raphael --001a113cddd6ce8ed6051d220bfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Timothy,

Many thanks for your answer.=

2015-08-12 20:23 GMT+02:00 Timothy B. Terriberry= <tterribe@xiph.org>:

Thanks for the contribution. There are several ways to go from here.

One thing that would be interesting to know would be the performance=20 compared to Daala and Thor. I would suggest working with Thomas Daede=20 <daede003@umn.edu<= /a>> to make that happen.


=C2=A0
Another thing would be to try to integrate pieces of the other=20 submissions into your codec or pieces of your codec into the other=20 submissions, to see if you can demonstrate improvements. Some examples=20 of how we have been doing this for Daala and Thor are here:

https://review.xiph.org/874/
https://github.com/cisco/thor/pull/8

We can try first with the entropy coding=20 for the wavelet coefficients.I would be really interested in trying=20 Daala's arithmetic coder.
=C2=A0
One potentially interesting area to experiment with might be be the=20 prototype screencasting experiments in Daala presented at IETF 93: https://tools.ietf.org/html/draft-valin-netvc-l1tw-01<= /a>

Those are using wavelets, so they might benefit from some of what you are d= oing.

Many thanks.
Raphael --001a113cddd6ce8ed6051d220bfd-- From nobody Wed Aug 12 12:24:30 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7B1ACAD8 for ; Wed, 12 Aug 2015 12:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWjwZgJHWl_z for ; Wed, 12 Aug 2015 12:24:24 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91881ACCD8 for ; Wed, 12 Aug 2015 12:24:24 -0700 (PDT) Received: by pacrr5 with SMTP id rr5so20535659pac.3 for ; Wed, 12 Aug 2015 12:24:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pdPFcwQnI5iGzKBykRY8Xj+rpM8bbFC5oIYeP2iDPFA=; b=SBHjsq78RI/3v7gNrxKjomGX9gN0UjMctOjUOlG50CNWFPuXNNVccHAAyfUkZKobtE Io7YQrn/qKFp2ekhj8wT7Bk9y27r9tgWXSSlGSHocD7+ou+tUU9XG4kNziXNHM4oTS6/ b9HGRwU8gdDRKEhTBHu0Rg1urHEl1X/RZagfE9HqPnwd/2y0r9X/86GKvknCYEqlmcsX mf+bXtrWL6ObQ59fa9tkzvS2Ekzvk9E1OakFUMGAdhlNDMQ2yRZf7LYjJERku9Zrko/3 EfWB49WcXO5hyCuNVilrBhZJ35tYXmYIN3xr3zs2DsybZFa2FuKt7BMY1XEhGsMDaAUb RPuw== X-Gm-Message-State: ALoCoQkZXS/Nv373NN0CW11CxzcXYtz1w9lz0ltSOR6HlhWqMkuL31c6pqUgS07PQ9BiMmrK/l6A X-Received: by 10.69.2.227 with SMTP id br3mr71285094pbd.9.1439407464234; Wed, 12 Aug 2015 12:24:24 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:232:7e7a:91ff:fe9e:8126? ([2620:101:80fc:232:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id p1sm7384797pdb.3.2015.08.12.12.24.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 12:24:23 -0700 (PDT) To: video-codec@ietf.org References: <55CB8F09.50600@xiph.org> From: Thomas Daede Message-ID: <55CB9D65.9060706@mozilla.com> Date: Wed, 12 Aug 2015 12:24:21 -0700 User-Agent: http://a.pomf.se/cszdno.opus MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] NHW: a wavelet image codec X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 19:24:29 -0000 On 08/12/2015 12:15 PM, Raphael Canut wrote: > 2015-08-12 20:23 GMT+02:00 Timothy B. Terriberry >: > > > Thanks for the contribution. There are several ways to go from here. > > One thing that would be interesting to know would be the performance > compared to Daala and Thor. I would suggest working with Thomas > Daede > to make that happen. > > That's a good idea, but keep in mind that the NHW codec is optimized for > neatness (and sharpness), so results for PSNR and SSIM are not good > (there are more "errors").For now, the best way I have found to evaluate > the NHW codec is to visually evaluate it.... It is also now optimized > for mid/normal compression, there are no high compression settings... > It's still experimental! We do have a couple of other metrics that value detail retention more, such as PSNR-HVS and FASTSSIM in our code tree. To be able to hook your codec up to arewecompressedyet, it needs to support YUV 4:2:0 input and output in the y4m format. From nobody Wed Aug 12 12:42:20 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2F01ACD1D for ; Wed, 12 Aug 2015 12:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhqVR0_YoeYT for ; Wed, 12 Aug 2015 12:42:14 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9A51ACD09 for ; Wed, 12 Aug 2015 12:42:14 -0700 (PDT) Received: by oiev193 with SMTP id v193so14897918oie.3 for ; Wed, 12 Aug 2015 12:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dYlvmmy8ikvxF4hOLK5ub4kFtSKEgixQDiuF4RaGdI8=; b=xdvUq74XVEsigBV6di9Yco6s1/G5LiyKjp+q1o+Df8RgPHnxr88n6hfnzca1SkQrKV yMRIhQGBQpZESr+EQ/+q0HdQEQ9e6Ezjs+uO0OUddnxfKR+8CVCqzaPtzHmWnN1w2V1n TFgBetk00m1L+Q0YFZsVLeIs7kFU1/YNSPSZut4nf19S76mGKutRFN2R2XZCWcSmopkd wJgFnebX0YksNxWHR4mm00rfm3mR2wcFsNH3TWZ3tsfYUn4pJJnF7YizR5lDqOr8kCOC iQuZq1u5pM+8MMqbXAw3PhFqWKSKZuKKi9bjS5lrRvPPK4M0GJ9owQpJ5EUPlqbeebDj LMRg== MIME-Version: 1.0 X-Received: by 10.202.194.9 with SMTP id s9mr30790956oif.39.1439408533660; Wed, 12 Aug 2015 12:42:13 -0700 (PDT) Received: by 10.76.83.69 with HTTP; Wed, 12 Aug 2015 12:42:13 -0700 (PDT) In-Reply-To: <55CB9D65.9060706@mozilla.com> References: <55CB8F09.50600@xiph.org> <55CB9D65.9060706@mozilla.com> Date: Wed, 12 Aug 2015 21:42:13 +0200 Message-ID: From: Raphael Canut To: Thomas Daede Content-Type: multipart/alternative; boundary=001a113dc33455eb75051d226a47 Archived-At: Cc: video-codec@ietf.org Subject: Re: [video-codec] NHW: a wavelet image codec X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 19:42:18 -0000 --001a113dc33455eb75051d226a47 Content-Type: text/plain; charset=UTF-8 Hi Thomas, The NHW codec is at very early experimental stage (it's an image codec furthermore, not a video codec), and image input size is fixed 512x512 size for now. Also, the NHW codec is not very good at detail retention, but it gives more neatness, sharpness to image contours, edges. Cheers, Raphael 2015-08-12 21:24 GMT+02:00 Thomas Daede : > On 08/12/2015 12:15 PM, Raphael Canut wrote: > > 2015-08-12 20:23 GMT+02:00 Timothy B. Terriberry > >: > > > > > > Thanks for the contribution. There are several ways to go from here. > > > > One thing that would be interesting to know would be the performance > > compared to Daala and Thor. I would suggest working with Thomas > > Daede > to make that > happen. > > > > That's a good idea, but keep in mind that the NHW codec is optimized for > > neatness (and sharpness), so results for PSNR and SSIM are not good > > (there are more "errors").For now, the best way I have found to evaluate > > the NHW codec is to visually evaluate it.... It is also now optimized > > for mid/normal compression, there are no high compression settings... > > It's still experimental! > > We do have a couple of other metrics that value detail retention more, > such as PSNR-HVS and FASTSSIM in our code tree. > > To be able to hook your codec up to arewecompressedyet, it needs to > support YUV 4:2:0 input and output in the y4m format. > > _______________________________________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > --001a113dc33455eb75051d226a47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

The NHW codec = is at very early experimental stage (it's an image codec furthermore, n= ot a video codec), and image input size is fixed 512x512 size for now.
<= br>
Also, the NHW codec is not very good at detail retention, but it g= ives more neatness, sharpness to image contours, edges.

Cheers= ,
Raphael

2015-08-12 21:24 GMT+02:00 Thomas Daede <tdaede@mozil= la.com>:
O= n 08/12/2015 12:15 PM, Raphael Canut wrote:
> 2015-08-12 20:23 GMT+02:00 Timothy B. Terriberry <tterribe@xiph.org
> <mailto:tterribe@xiph.o= rg>>:
>
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the contribution. There are several ways= to go from here.
>
>=C2=A0 =C2=A0 =C2=A0One thing that would be interesting to know would b= e the performance
>=C2=A0 =C2=A0 =C2=A0compared to Daala and Thor. I would suggest working= with Thomas
>=C2=A0 =C2=A0 =C2=A0Daede <daede003@umn.edu <mailto:daede= 003@umn.edu>> to make that happen.
>
> That's a good idea, but keep in mind that the NHW codec is optimiz= ed for
> neatness (and sharpness), so results for PSNR and SSIM are not good > (there are more "errors").For now, the best way I have found= to evaluate
> the NHW codec is to visually evaluate it.... It is also now optimized<= br> > for mid/normal compression, there are no high compression settings...<= br> > It's still experimental!

We do have a couple of other metrics that value detail retention mor= e,
such as PSNR-HVS and FASTSSIM in our code tree.

To be able to hook your codec up to arewecompressedyet, it needs to
support YUV 4:2:0 input and output in the y4m format.

_______________________________________________
video-codec mailing list
video-codec@ietf.org
https://www.ietf.org/mailman/listinfo/video-codec

--001a113dc33455eb75051d226a47-- From nobody Thu Aug 13 12:30:24 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CE91AC405 for ; Thu, 13 Aug 2015 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrAIVowF0kTg for ; Thu, 13 Aug 2015 12:30:20 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F082D1AC3F1 for ; Thu, 13 Aug 2015 12:30:19 -0700 (PDT) Received: by qged69 with SMTP id d69so38004042qge.0 for ; Thu, 13 Aug 2015 12:30:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=syWQGFy26qyK+VFaOXjPgpId2T/66FTtyzBROkvEa/I=; b=Vc16rPxDiTP+60wumwl5/OXmipwUBC4ASGNWoasxFa16UTAWq2aqJb7kUSG2Em34V4 1MGcgUHPQSDYz6BPVLBWXo+9Dm91hk+9PbrbN3f46QJRLBRURViHYEpeZf/E3obShcyk 3IyQjJH4dUOvO9Cb7QfvYQtYijAwBZz8bivdnnrQcoS3X3/9svLSsJ26b1t+G/lcKag6 yCdDLnmzJRtbS6zFZ29ftxZAWOGoHFZpfaSmmeEseck+zV13DYGezFLSIP4j//nomH6k HPunTFNByzEKvL3pszE1hX3Va6g4ShVfhBj85i59JvK9QNL27EcrnGNm4LRsZkcva5mW /u2A== X-Gm-Message-State: ALoCoQn/YPyjLR+X/bqsmB3vDl0ZnQYnguLpLvqJwJSA5dohrqLIAmheXSp7X9SiZ48kHLoJsQKb X-Received: by 10.140.19.116 with SMTP id 107mr71442741qgg.33.1439494218939; Thu, 13 Aug 2015 12:30:18 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by smtp.gmail.com with ESMTPSA id 19sm1635864qhx.39.2015.08.13.12.30.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 12:30:18 -0700 (PDT) To: "video-codec@ietf.org" From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <55CCF049.8050206@mozilla.com> Date: Thu, 13 Aug 2015 15:30:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 19:30:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm trying to understand the Thor code base and had a few questions on the deblocking filter and the VLC coding. 1) When deciding whether to filter, why does the deblocking filter use the absolute value of the motion vectors on each side rather than the difference between the two motion vectors? 2) What does cbp stand for and why does the deblocking use cbp = p_cbp || q_cbp; as a condition? 3) Considering that with NEW_DEBLOCK_TEST=1 (which is now the default), the deblocking filter only seems to look at two pixels on each side of an edge, are there any plans on adding deblocking to 4x4 blocks? 4) For the purpose of experimenting with Daala, it would be more convenient to do the deblocking recursively, first filtering the inside of 16x16 blocks that are split into 8x8, then filtering the inside of 32x32 blocks that are split into 16x16, then filtering between 32x32 superblocks. Are there known reasons why this would be a bad idea? 5) Is there any documentation for what the different values of the variable "n" mean in get_vlc(). 6) Is there any way to get stats on how many bits are spend coding in different contexts, e.g. for a particular video, how much of the bits are used for motion vectors vs block modes vs residual, etc? If not, any interest in using the bit accounting framework we have in Daala? Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVzPBDAAoJEJ6/8sItn9q9z50IAIuDTSlSf3w+8MFMc9ruP26V 3DKL+1sevJ2CjqqcSBJEMpodFUIGruS6fu/ztU5gG32+SrbquYDtvhH0owpaIsjk /TPIiuSoe/Pvy3yaNZVG2pbKECW1pxcz3QYvJ8ldNIwBPglWjBOYo5DSMJCJek9d PSpYXrk1QQeuTmYulu+In8+XZBlm7/Nb4aVXsHTfYCWEpq1WxZWTbcRUfsTCLyfd vtv1R26TFmEOESwdtnI3H0aJc2cfpDQprCSn2mbWwLmz40jZsB/tAgr/CfQfpkAs 2QNTGN+vzsoYu+kAUbYGiUsA6wnO9LrojAdFepednYwPGhAyh476PObpMZ1IWlE= =+hE7 -----END PGP SIGNATURE----- From nobody Thu Aug 13 13:03:50 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6208B1ACC85 for ; Thu, 13 Aug 2015 13:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOfI1JV8Bkp7 for ; Thu, 13 Aug 2015 13:03:44 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39FA1B3A81 for ; Thu, 13 Aug 2015 13:03:44 -0700 (PDT) Received: by ykdz80 with SMTP id z80so51154733ykd.2 for ; Thu, 13 Aug 2015 13:03:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4kSHYEU6VP7RGxd6KOvurtMxGWtBvO/TiLJre0qyMew=; b=NCHqj5RSoX2phMM1W1o6LoZbMNvZ29JbxBIhQtzFrEPXB4D3t7sMBAU9LOx8RrQfDo Te8fUZEl868aKsEJz+WQ8ifbhIqIo6xE3Y1Y9AIjsxRLiBZCF8UEswRrymrV5dQIOzUx Yeo0dKNX18JugE9yf4NvdylLyqa5mrqQHqUxr21X5cFIeQ4d73i2O7gSDrYbd0tJHp/6 63L4EYOAnI9n9L2pb9b4X8KOxwmd6M/mVpl1gt7OwoEBF8TsHFAJ7nwoI8rkyLQ4fI2G ybdSCc5lwC9I/+kMBKWOi7HCB6J+h3nARti8qiCRVJN0FdnAG7j/l1bXfOMyZAfcwolC fXvA== X-Gm-Message-State: ALoCoQnseth7uTKes0vNCCUBwsj/n8SUc3wsUid7jC/7vUM6Yo89CgQq5Per43uxpT6Wcom3jlww MIME-Version: 1.0 X-Received: by 10.170.76.66 with SMTP id s63mr31018108yks.62.1439496223894; Thu, 13 Aug 2015 13:03:43 -0700 (PDT) Received: by 10.37.214.22 with HTTP; Thu, 13 Aug 2015 13:03:43 -0700 (PDT) In-Reply-To: <55CCF049.8050206@mozilla.com> References: <55CCF049.8050206@mozilla.com> Date: Thu, 13 Aug 2015 13:03:43 -0700 Message-ID: From: Yushin Cho To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a113a8d08150263051d36d5eb Archived-At: Cc: "video-codec@ietf.org" Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:03:49 -0000 --001a113a8d08150263051d36d5eb Content-Type: text/plain; charset=UTF-8 Regarding 2), cbp = p_cbp || q_cbp; is true if at least one of two blocks (p or q) has non-zero coefficient coded. On Thu, Aug 13, 2015 at 12:30 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I'm trying to understand the Thor code base and had a few questions on > the deblocking filter and the VLC coding. > > 1) When deciding whether to filter, why does the deblocking filter use > the absolute value of the motion vectors on each side rather than the > difference between the two motion vectors? > > 2) What does cbp stand for and why does the deblocking use > cbp = p_cbp || q_cbp; > as a condition? > > 3) Considering that with NEW_DEBLOCK_TEST=1 (which is now the > default), the deblocking filter only seems to look at two pixels on > each side of an edge, are there any plans on adding deblocking to 4x4 > blocks? > > 4) For the purpose of experimenting with Daala, it would be more > convenient to do the deblocking recursively, first filtering the > inside of 16x16 blocks that are split into 8x8, then filtering the > inside of 32x32 blocks that are split into 16x16, then filtering > between 32x32 superblocks. Are there known reasons why this would be a > bad idea? > > 5) Is there any documentation for what the different values of the > variable "n" mean in get_vlc(). > > 6) Is there any way to get stats on how many bits are spend coding in > different contexts, e.g. for a particular video, how much of the bits > are used for motion vectors vs block modes vs residual, etc? If not, > any interest in using the bit accounting framework we have in Daala? > > Cheers, > > Jean-Marc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVzPBDAAoJEJ6/8sItn9q9z50IAIuDTSlSf3w+8MFMc9ruP26V > 3DKL+1sevJ2CjqqcSBJEMpodFUIGruS6fu/ztU5gG32+SrbquYDtvhH0owpaIsjk > /TPIiuSoe/Pvy3yaNZVG2pbKECW1pxcz3QYvJ8ldNIwBPglWjBOYo5DSMJCJek9d > PSpYXrk1QQeuTmYulu+In8+XZBlm7/Nb4aVXsHTfYCWEpq1WxZWTbcRUfsTCLyfd > vtv1R26TFmEOESwdtnI3H0aJc2cfpDQprCSn2mbWwLmz40jZsB/tAgr/CfQfpkAs > 2QNTGN+vzsoYu+kAUbYGiUsA6wnO9LrojAdFepednYwPGhAyh476PObpMZ1IWlE= > =+hE7 > -----END PGP SIGNATURE----- > > _______________________________________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > -- Thanks! Yushin --001a113a8d08150263051d36d5eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding 2), cbp =3D p_cbp || q_cbp; is true if at least = one of two blocks (p or q) has non-zero coefficient coded.

On Thu, Aug 13, 2015 at 12:30 = PM, Jean-Marc Valin <jmvalin@mozilla.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I'm trying to understand the Thor code base and had a few questions on<= br> the deblocking filter and the VLC coding.

1) When deciding whether to filter, why does the deblocking filter use
the absolute value of the motion vectors on each side rather than the
difference between the two motion vectors?

2) What does cbp stand for and why does the deblocking use
cbp =3D p_cbp || q_cbp;
as a condition?

3) Considering that with NEW_DEBLOCK_TEST=3D1 (which is now the
default), the deblocking filter only seems to look at two pixels on
each side of an edge, are there any plans on adding deblocking to 4x4
blocks?

4) For the purpose of experimenting with Daala, it would be more
convenient to do the deblocking recursively, first filtering the
inside of 16x16 blocks that are split into 8x8, then filtering the
inside of 32x32 blocks that are split into 16x16, then filtering
between 32x32 superblocks. Are there known reasons why this would be a
bad idea?

5) Is there any documentation for what the different values of the
variable "n" mean in get_vlc().

6) Is there any way to get stats on how many bits are spend coding in
different contexts, e.g. for a particular video, how much of the bits
are used for motion vectors vs block modes vs residual, etc? If not,
any interest in using the bit accounting framework we have in Daala?

Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVzPBDAAoJEJ6/8sItn9q9z50IAIuDTSlSf3w+8MFMc9ruP26V
3DKL+1sevJ2CjqqcSBJEMpodFUIGruS6fu/ztU5gG32+SrbquYDtvhH0owpaIsjk
/TPIiuSoe/Pvy3yaNZVG2pbKECW1pxcz3QYvJ8ldNIwBPglWjBOYo5DSMJCJek9d
PSpYXrk1QQeuTmYulu+In8+XZBlm7/Nb4aVXsHTfYCWEpq1WxZWTbcRUfsTCLyfd
vtv1R26TFmEOESwdtnI3H0aJc2cfpDQprCSn2mbWwLmz40jZsB/tAgr/CfQfpkAs
2QNTGN+vzsoYu+kAUbYGiUsA6wnO9LrojAdFepednYwPGhAyh476PObpMZ1IWlE=3D
=3D+hE7
-----END PGP SIGNATURE-----

_______________________________________________
video-codec mailing list
video-codec@ietf.org
https://www.ietf.org/mailman/listinfo/video-codec



--
Thanks!
Yushin=
--001a113a8d08150263051d36d5eb-- From nobody Fri Aug 14 00:31:16 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C106B1A026F for ; Fri, 14 Aug 2015 00:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JwBmFQM6KoT for ; Fri, 14 Aug 2015 00:31:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09F51A0263 for ; Fri, 14 Aug 2015 00:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4169; q=dns/txt; s=iport; t=1439537473; x=1440747073; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xj6/xCylEGkBhJhfwqrNpFLS62me2Tn0h4GH4SSCs60=; b=ZLErRbuRhMpxmqWZxsbSLJGSRkyoa66YYzFFbH2mlB13R1JnaJ/h65xI z7mYmOJt2Aw8hUcJggbnuquB9zTq5NfD2z9XocZ29jjLIjoZxFTjq2Ukw kHGlFJEhbil1gwGCwxkBI5UnajF/ifsCVpJ8LuFB37KHKMCL8aafghYnn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B1AgASmM1V/4YNJK1dgxtUaQa9fgEJgWsMhXcCgUU4FAEBAQEBAQGBCoQjAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiIJg3QMwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLU4RYOAaDEoEUBZIOgw0BhQOJMkaDZYxlh0omgg0dgVNxAYFHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,676,1432598400"; d="scan'208";a="20438572" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2015 07:31:13 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t7E7VDUK022507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2015 07:31:13 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 14 Aug 2015 02:31:12 -0500 Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-rcd-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 14 Aug 2015 02:31:12 -0500 Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Fri, 14 Aug 2015 02:31:06 -0500 From: "Arild Fuldseth (arilfuld)" To: Jean-Marc Valin , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ1f6EBlGWWs9Thky4fm3BYycLV54LE8aA Date: Fri, 14 Aug 2015 07:31:05 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> In-Reply-To: <55CCF049.8050206@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 07:31:15 -0000 Hi Jean-Marc, Please see answers inline. Regards, Arild -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-M= arc Valin Sent: 13. august 2015 21:30 To: video-codec@ietf.org Subject: [video-codec] Questions about Thor -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm trying to understand the Thor code base and had a few questions on the = deblocking filter and the VLC coding. 1) When deciding whether to filter, why does the deblocking filter use the = absolute value of the motion vectors on each side rather than the differenc= e between the two motion vectors? H.264/H.265 use motion vector differences. In Thor we decided to do things = a bit differently. We have found the impact on performance to be marginal.= =20 2) What does cbp stand for and why does the deblocking use cbp =3D p_cbp ||= q_cbp; as a condition? CBP stands for Coded Block Pattern and is used to describe whether or not a= collection of blocks (typically 4 luma&2 chroma or 1 luma&2 chroma blocks)= have non-zero coefficients or not. The condition p_cbp || q_cbp specifies = that deblocking shall be performed if one of the blocks on either side of t= he block boundary has non-zero coefficients. 3) Considering that with NEW_DEBLOCK_TEST=3D1 (which is now the default), t= he deblocking filter only seems to look at two pixels on each side of an ed= ge, are there any plans on adding deblocking to 4x4 blocks? We have no plans to introduce deblocking of 4x4 block edges and looking at = only two pixels at every side of a block edge is done for an entirely diffe= rent reason. The difference between using three pixels and using two pixels= is marginal. While H.264 does deblocking on 4x4 block boundaries, consider= ing only 8x8 block edges was one of our inputs to the initial H.265 draft (= for complexity reasons). It survived several iterations of deblocking filte= r improvements during the H.265 standardization process. 4) For the purpose of experimenting with Daala, it would be more convenient= to do the deblocking recursively, first filtering the inside of 16x16 bloc= ks that are split into 8x8, then filtering the inside of 32x32 blocks that = are split into 16x16, then filtering between 32x32 superblocks. Are there k= nown reasons why this would be a bad idea? As long as all major block edges are filtered I guess it would be OK? 5) Is there any documentation for what the different values of the variable= "n" mean in get_vlc(). The draft would have to be updated with this information. Thor uses systema= tic VLC codes and "n" is used to choose between the various VLC codes. Most= of the VLC codes (n=3D0-10) are described in JCTVC-A119 (last section of t= he decoder description). http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/JCTVC-A= 119.zip 6) Is there any way to get stats on how many bits are spend coding in diffe= rent contexts, e.g. for a particular video, how much of the bits are used f= or motion vectors vs block modes vs residual, etc? If not, any interest in = using the bit accounting framework we have in Daala? Since the encoder does multiple encodings of each block (as part of the RDO= process), we found that it was most convenient to put bit statistics in th= e decoder where each syntax element of every block is processed only once. = The decoder prints out some of the statistics by default.=20 Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVzPBDAAoJEJ6/8sItn9q9z50IAIuDTSlSf3w+8MFMc9ruP26V 3DKL+1sevJ2CjqqcSBJEMpodFUIGruS6fu/ztU5gG32+SrbquYDtvhH0owpaIsjk /TPIiuSoe/Pvy3yaNZVG2pbKECW1pxcz3QYvJ8ldNIwBPglWjBOYo5DSMJCJek9d PSpYXrk1QQeuTmYulu+In8+XZBlm7/Nb4aVXsHTfYCWEpq1WxZWTbcRUfsTCLyfd vtv1R26TFmEOESwdtnI3H0aJc2cfpDQprCSn2mbWwLmz40jZsB/tAgr/CfQfpkAs 2QNTGN+vzsoYu+kAUbYGiUsA6wnO9LrojAdFepednYwPGhAyh476PObpMZ1IWlE=3D =3D+hE7 -----END PGP SIGNATURE----- _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From nobody Mon Aug 17 08:37:44 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE2D1AC44A for ; Mon, 17 Aug 2015 08:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO_5v7FqlS9F for ; Mon, 17 Aug 2015 08:37:41 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180A51AC443 for ; Mon, 17 Aug 2015 08:37:41 -0700 (PDT) Received: by qgeg42 with SMTP id g42so96891565qge.1 for ; Mon, 17 Aug 2015 08:37:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eED56PiT71caLhDmWVcEeeBuP+YrurcUbEska67VN9o=; b=DsB+M6TFI0czHNVXSVeYGvMjsB9uRgT5S6mPnahjeZzEoxPBeSLXHjoSAJloul40cx vzUsint08qybIvBCVQNI1+vyWm37gqihLimYbIynAxW3WUE5EuHCynfQkRhafLq2dPr8 HY9rBN8Im4v+XqkSnyyU6vL0hN4tGpyNOt9TAe9oUwWFW9NI+MyecoxuTHU2jO92P2+8 tyBNQgzdvnPBc0haiX8QFJnDbiF3tZvmt7wwZ9GU2GMpIhLXkMj/ObMcPb5qlZ1hC+ZZ wVXaUC7Sv8BUuVFfbssd5F1VIiIg5hEXMpAqhnQ4TvmGpX3fM4gqFx8e1pBmglA5hi/J BTjg== X-Gm-Message-State: ALoCoQnEkacNOc1ALfFsBTnLSZDkUss+y8K7Z8rxJ4b6jdSxEQnMYF7BvgxRsgPdtCrDlgp8ReoD X-Received: by 10.140.235.3 with SMTP id g3mr3781417qhc.56.1439825860235; Mon, 17 Aug 2015 08:37:40 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by smtp.gmail.com with ESMTPSA id e197sm8356983qhc.30.2015.08.17.08.37.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 08:37:39 -0700 (PDT) To: "Arild Fuldseth (arilfuld)" , "video-codec@ietf.org" References: <55CCF049.8050206@mozilla.com> From: Jean-Marc Valin Message-ID: <55D1FFC2.1020800@mozilla.com> Date: Mon, 17 Aug 2015 11:37:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 15:37:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Arild, Thanks for your help. I'm about to have a simplified version of the Thor deblocking filter working for Daala intra frames. I'll post results when I have it fully working. Cheers, Jean-Marc On 08/14/2015 03:31 AM, Arild Fuldseth (arilfuld) wrote: > Hi Jean-Marc, > > Please see answers inline. > > Regards, > > Arild > > -----Original Message----- From: video-codec > [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin > Sent: 13. august 2015 21:30 To: video-codec@ietf.org Subject: > [video-codec] Questions about Thor > > Hi, > > I'm trying to understand the Thor code base and had a few questions > on the deblocking filter and the VLC coding. > > 1) When deciding whether to filter, why does the deblocking filter > use the absolute value of the motion vectors on each side rather > than the difference between the two motion vectors? > > H.264/H.265 use motion vector differences. In Thor we decided to do > things a bit differently. We have found the impact on performance > to be marginal. > > 2) What does cbp stand for and why does the deblocking use cbp = > p_cbp || q_cbp; as a condition? > > CBP stands for Coded Block Pattern and is used to describe whether > or not a collection of blocks (typically 4 luma&2 chroma or 1 > luma&2 chroma blocks) have non-zero coefficients or not. The > condition p_cbp || q_cbp specifies that deblocking shall be > performed if one of the blocks on either side of the block boundary > has non-zero coefficients. > > 3) Considering that with NEW_DEBLOCK_TEST=1 (which is now the > default), the deblocking filter only seems to look at two pixels on > each side of an edge, are there any plans on adding deblocking to > 4x4 blocks? > > We have no plans to introduce deblocking of 4x4 block edges and > looking at only two pixels at every side of a block edge is done > for an entirely different reason. The difference between using > three pixels and using two pixels is marginal. While H.264 does > deblocking on 4x4 block boundaries, considering only 8x8 block > edges was one of our inputs to the initial H.265 draft (for > complexity reasons). It survived several iterations of deblocking > filter improvements during the H.265 standardization process. > > 4) For the purpose of experimenting with Daala, it would be more > convenient to do the deblocking recursively, first filtering the > inside of 16x16 blocks that are split into 8x8, then filtering the > inside of 32x32 blocks that are split into 16x16, then filtering > between 32x32 superblocks. Are there known reasons why this would > be a bad idea? > > As long as all major block edges are filtered I guess it would be > OK? > > 5) Is there any documentation for what the different values of the > variable "n" mean in get_vlc(). > > The draft would have to be updated with this information. Thor uses > systematic VLC codes and "n" is used to choose between the various > VLC codes. Most of the VLC codes (n=0-10) are described in > JCTVC-A119 (last section of the decoder description). > > http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/JC TVC-A119.zip > > 6) Is there any way to get stats on how many bits are spend coding > in different contexts, e.g. for a particular video, how much of the > bits are used for motion vectors vs block modes vs residual, etc? > If not, any interest in using the bit accounting framework we have > in Daala? > > Since the encoder does multiple encodings of each block (as part of > the RDO process), we found that it was most convenient to put bit > statistics in the decoder where each syntax element of every block > is processed only once. The decoder prints out some of the > statistics by default. > > Cheers, > > Jean-Marc > > _______________________________________________ video-codec mailing > list video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > > _______________________________________________ video-codec mailing > list video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0f++AAoJEJ6/8sItn9q97q0H/10+UxDQ/j8I+RL2DSRyt3O2 wZ0rawvpLVIqpGrvtlb/GE4FNmM4+TrH8RGPc3s00iEAQXcG5oB5fXcplpR/uJ8w dXg4piM9Gd1my7tEumPZx/WsumiF9ZelaHlmBDw4FIc/UF7hWKZwV3NZYn83sWU/ PFNcv6zGLO2ZtBIEWwTA4036j8fsyU65lVyzDPUJIAQpvCZlKnOqo+ZHgnPUYbf1 80c6rSXD9aJDUtRHFJtVoqiPTOm0szk1Lp6YVuyy0JyLtx5QobbdoKfdNcv3T3BH CT+PEsE1EYfPiyXDLgqW+f60qnvz19iZH5wis0GtIINvj+36dYOgtgZ8CrL1spE= =bOiu -----END PGP SIGNATURE----- From nobody Mon Aug 17 08:44:22 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BA21ACCFA for ; Mon, 17 Aug 2015 08:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd1JHYZwmtUY for ; Mon, 17 Aug 2015 08:44:19 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id D82AF1ACD05 for ; Mon, 17 Aug 2015 08:44:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,695,1432623600"; d="scan'208";a="72783078" Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw1-out.broadcom.com with ESMTP; 17 Aug 2015 10:07:51 -0700 Received: from IRVEXCHMB15.corp.ad.broadcom.com ([fe80::3c14:d213:d2c9:b75a]) by IRVEXCHCAS07.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 17 Aug 2015 08:44:16 -0700 From: Minhua Zhou To: Jean-Marc Valin , "Arild Fuldseth (arilfuld)" , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ2QKyJla43Yq3qkW32sy32vOoUp4QVF+A Date: Mon, 17 Aug 2015 15:44:15 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> In-Reply-To: <55D1FFC2.1020800@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 15:44:21 -0000 Hi Jean-Marc, 4) For the purpose of experimenting with Daala, it would be more=20 > convenient to do the deblocking recursively, first filtering the=20 > inside of 16x16 blocks that are split into 8x8, then filtering the=20 > inside of 32x32 blocks that are split into 16x16, then filtering=20 > between 32x32 superblocks. Are there known reasons why this would be a=20 > bad idea? This filtering order might not be implementation friendly.. Could you pleas= e elaborate more on how this is done? Regards, Minhua =20 -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-M= arc Valin Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth (arilfuld); video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Arild, Thanks for your help. I'm about to have a simplified version of the Thor de= blocking filter working for Daala intra frames. I'll post results when I ha= ve it fully working. Cheers, Jean-Marc On 08/14/2015 03:31 AM, Arild Fuldseth (arilfuld) wrote: > Hi Jean-Marc, >=20 > Please see answers inline. >=20 > Regards, >=20 > Arild >=20 > -----Original Message----- From: video-codec=20 > [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin > Sent: 13. august 2015 21:30 To: video-codec@ietf.org Subject: > [video-codec] Questions about Thor >=20 > Hi, >=20 > I'm trying to understand the Thor code base and had a few questions on=20 > the deblocking filter and the VLC coding. >=20 > 1) When deciding whether to filter, why does the deblocking filter use=20 > the absolute value of the motion vectors on each side rather than the=20 > difference between the two motion vectors? >=20 > H.264/H.265 use motion vector differences. In Thor we decided to do=20 > things a bit differently. We have found the impact on performance to=20 > be marginal. >=20 > 2) What does cbp stand for and why does the deblocking use cbp =3D p_cbp= =20 > || q_cbp; as a condition? >=20 > CBP stands for Coded Block Pattern and is used to describe whether or=20 > not a collection of blocks (typically 4 luma&2 chroma or 1 > luma&2 chroma blocks) have non-zero coefficients or not. The condition=20 > p_cbp || q_cbp specifies that deblocking shall be performed if one of=20 > the blocks on either side of the block boundary has non-zero=20 > coefficients. >=20 > 3) Considering that with NEW_DEBLOCK_TEST=3D1 (which is now the=20 > default), the deblocking filter only seems to look at two pixels on=20 > each side of an edge, are there any plans on adding deblocking to > 4x4 blocks? >=20 > We have no plans to introduce deblocking of 4x4 block edges and=20 > looking at only two pixels at every side of a block edge is done for=20 > an entirely different reason. The difference between using three=20 > pixels and using two pixels is marginal. While H.264 does deblocking=20 > on 4x4 block boundaries, considering only 8x8 block edges was one of=20 > our inputs to the initial H.265 draft (for complexity reasons). It=20 > survived several iterations of deblocking filter improvements during=20 > the H.265 standardization process. >=20 > 4) For the purpose of experimenting with Daala, it would be more=20 > convenient to do the deblocking recursively, first filtering the=20 > inside of 16x16 blocks that are split into 8x8, then filtering the=20 > inside of 32x32 blocks that are split into 16x16, then filtering=20 > between 32x32 superblocks. Are there known reasons why this would be a=20 > bad idea? >=20 > As long as all major block edges are filtered I guess it would be OK? >=20 > 5) Is there any documentation for what the different values of the=20 > variable "n" mean in get_vlc(). >=20 > The draft would have to be updated with this information. Thor uses=20 > systematic VLC codes and "n" is used to choose between the various VLC=20 > codes. Most of the VLC codes (n=3D0-10) are described in > JCTVC-A119 (last section of the decoder description). >=20 > http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/JC TVC-A119.zip > > 6) Is there any way to get stats on how many bits are spend coding in=20 > different contexts, e.g. for a particular video, how much of the bits=20 > are used for motion vectors vs block modes vs residual, etc? > If not, any interest in using the bit accounting framework we have in=20 > Daala? >=20 > Since the encoder does multiple encodings of each block (as part of=20 > the RDO process), we found that it was most convenient to put bit=20 > statistics in the decoder where each syntax element of every block is=20 > processed only once. The decoder prints out some of the statistics by=20 > default. >=20 > Cheers, >=20 > Jean-Marc >=20 > _______________________________________________ video-codec mailing=20 > list video-codec@ietf.org=20 > https://www.ietf.org/mailman/listinfo/video-codec >=20 > _______________________________________________ video-codec mailing=20 > list video-codec@ietf.org=20 > https://www.ietf.org/mailman/listinfo/video-codec >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0f++AAoJEJ6/8sItn9q97q0H/10+UxDQ/j8I+RL2DSRyt3O2 wZ0rawvpLVIqpGrvtlb/GE4FNmM4+TrH8RGPc3s00iEAQXcG5oB5fXcplpR/uJ8w dXg4piM9Gd1my7tEumPZx/WsumiF9ZelaHlmBDw4FIc/UF7hWKZwV3NZYn83sWU/ PFNcv6zGLO2ZtBIEWwTA4036j8fsyU65lVyzDPUJIAQpvCZlKnOqo+ZHgnPUYbf1 80c6rSXD9aJDUtRHFJtVoqiPTOm0szk1Lp6YVuyy0JyLtx5QobbdoKfdNcv3T3BH CT+PEsE1EYfPiyXDLgqW+f60qnvz19iZH5wis0GtIINvj+36dYOgtgZ8CrL1spE=3D =3DbOiu -----END PGP SIGNATURE----- _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From nobody Mon Aug 17 08:58:56 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7491B2EB3 for ; Mon, 17 Aug 2015 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud0Tjm8yx11d for ; Mon, 17 Aug 2015 08:58:35 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AF61B2E7F for ; Mon, 17 Aug 2015 08:58:18 -0700 (PDT) Received: by qgj62 with SMTP id 62so96917182qgj.2 for ; Mon, 17 Aug 2015 08:58:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3LYQPNVUt0U8XQLJ5YUYaqaeNLTfojJLCBaqPRLeajc=; b=B9iJgMAjTl9evT/EVIb5Ne7bFuZs3Niw3SH0bXMjVHKBP1C/qQHTXlWe7QzU1RZiQl sy8Qc+r8kY/WnM6BNbuqUF2JJ33oj6o+nCSlJ8SbkVuqfiBXpESzoUTkTv7oofoO88vi dbp1ZQIhvacwhMqnJ0jRbtTjZnfxMbSjGOE2ZC/g4v3uw0ojEOAvmYbMBx2aha0vR86+ 3fhObNYQz+1tdZ9ofoQiXc3AhO5HxUjS+/0HPtt3tYJ/o2IMXGCivmXx6wzVlJvvQg6n BD+HkdUDQx4Y4J3NgFzFUZi3WMwE0yvYMhor7iTTU5AQ3rh+lDCzLD3fFIvwedKZvmFC 1vmA== X-Gm-Message-State: ALoCoQmPmdl5m3WhmoyGdJQHGGH8HI1Jwpydk3YNIzW2+QBtuFtKY64TOqvJGbsTNtWrB3teVydD X-Received: by 10.140.133.199 with SMTP id 190mr3968402qhf.12.1439827097883; Mon, 17 Aug 2015 08:58:17 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by smtp.gmail.com with ESMTPSA id b47sm6892139qge.44.2015.08.17.08.58.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 08:58:17 -0700 (PDT) To: Minhua Zhou , "Arild Fuldseth (arilfuld)" , "video-codec@ietf.org" References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> From: Jean-Marc Valin Message-ID: <55D20498.30305@mozilla.com> Date: Mon, 17 Aug 2015 11:58:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 15:58:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/17/2015 11:44 AM, Minhua Zhou wrote: > 4) For the purpose of experimenting with Daala, it would be more >> convenient to do the deblocking recursively, first filtering the >> inside of 16x16 blocks that are split into 8x8, then filtering >> the inside of 32x32 blocks that are split into 16x16, then >> filtering between 32x32 superblocks. Are there known reasons why >> this would be a bad idea? > > This filtering order might not be implementation friendly.. Could > you please elaborate more on how this is done? Keep in mind that right now this is just for the purpose of experimentation and it matches how the lapping is done (of course there's no lapping if we use deblocking). The idea is simply that in the recursion, after 4 8x8 blocks are decoded, we can deblock the boundary between these 4 blocks and treat the result as a 16x16 block. Then higher up in the recursion, when we have 4 16x16 blocks, we again deblock the boundary between them. This is done all the way up to whatever super-block size. Then, the superblocks are deblocked in order. Right now, I'm doing this mostly for convenience, but one potential advantage of this ordering is that it makes it easy for the encoder to take the deblocking filter into account when making block size decisions . Cheers, Jean-Marc > Regards, > > Minhua > > > -----Original Message----- From: video-codec > [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin > Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth > (arilfuld); video-codec@ietf.org Subject: Re: [video-codec] > Questions about Thor > > Hi Arild, > > Thanks for your help. I'm about to have a simplified version of > the Thor deblocking filter working for Daala intra frames. I'll > post results when I have it fully working. > > Cheers, > > Jean-Marc > > On 08/14/2015 03:31 AM, Arild Fuldseth (arilfuld) wrote: >> Hi Jean-Marc, > >> Please see answers inline. > >> Regards, > >> Arild > >> -----Original Message----- From: video-codec >> [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc >> Valin Sent: 13. august 2015 21:30 To: video-codec@ietf.org >> Subject: [video-codec] Questions about Thor > >> Hi, > >> I'm trying to understand the Thor code base and had a few >> questions on the deblocking filter and the VLC coding. > >> 1) When deciding whether to filter, why does the deblocking >> filter use the absolute value of the motion vectors on each side >> rather than the difference between the two motion vectors? > >> H.264/H.265 use motion vector differences. In Thor we decided to >> do things a bit differently. We have found the impact on >> performance to be marginal. > >> 2) What does cbp stand for and why does the deblocking use cbp = >> p_cbp || q_cbp; as a condition? > >> CBP stands for Coded Block Pattern and is used to describe >> whether or not a collection of blocks (typically 4 luma&2 chroma >> or 1 luma&2 chroma blocks) have non-zero coefficients or not. >> The condition p_cbp || q_cbp specifies that deblocking shall be >> performed if one of the blocks on either side of the block >> boundary has non-zero coefficients. > >> 3) Considering that with NEW_DEBLOCK_TEST=1 (which is now the >> default), the deblocking filter only seems to look at two pixels >> on each side of an edge, are there any plans on adding deblocking >> to 4x4 blocks? > >> We have no plans to introduce deblocking of 4x4 block edges and >> looking at only two pixels at every side of a block edge is done >> for an entirely different reason. The difference between using >> three pixels and using two pixels is marginal. While H.264 does >> deblocking on 4x4 block boundaries, considering only 8x8 block >> edges was one of our inputs to the initial H.265 draft (for >> complexity reasons). It survived several iterations of >> deblocking filter improvements during the H.265 standardization >> process. > >> 4) For the purpose of experimenting with Daala, it would be more >> convenient to do the deblocking recursively, first filtering the >> inside of 16x16 blocks that are split into 8x8, then filtering >> the inside of 32x32 blocks that are split into 16x16, then >> filtering between 32x32 superblocks. Are there known reasons why >> this would be a bad idea? > >> As long as all major block edges are filtered I guess it would >> be OK? > >> 5) Is there any documentation for what the different values of >> the variable "n" mean in get_vlc(). > >> The draft would have to be updated with this information. Thor >> uses systematic VLC codes and "n" is used to choose between the >> various VLC codes. Most of the VLC codes (n=0-10) are described >> in JCTVC-A119 (last section of the decoder description). > >> http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/J C > >> >> TVC-A119.zip > >> 6) Is there any way to get stats on how many bits are spend >> coding in different contexts, e.g. for a particular video, how >> much of the bits are used for motion vectors vs block modes vs >> residual, etc? If not, any interest in using the bit accounting >> framework we have in Daala? > >> Since the encoder does multiple encodings of each block (as part >> of the RDO process), we found that it was most convenient to put >> bit statistics in the decoder where each syntax element of every >> block is processed only once. The decoder prints out some of the >> statistics by default. > >> Cheers, > >> Jean-Marc > >> _______________________________________________ video-codec >> mailing list video-codec@ietf.org >> https://www.ietf.org/mailman/listinfo/video-codec > >> _______________________________________________ video-codec >> mailing list video-codec@ietf.org >> https://www.ietf.org/mailman/listinfo/video-codec > > > _______________________________________________ video-codec > mailing list video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > > _______________________________________________ video-codec > mailing list video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0gSYAAoJEJ6/8sItn9q96tsIAL5fIbav8G/u2f7qC3ammLDe NXxNLvgTnbw6Spohyp8FdfUQ0xHVESVsgVYb6t96wmVcizymyaVRW3sP+7nvAj/I 1qZKd1PoHNhCikuF4Llr8LwgR3kKjHjgrPdnvw9ls85ZC3CrY5C8THkAmtv1+MGW 4dKFlQvDNa10uyLcH0DE6O7jJBtvMasIj8ZXFsSGvsjTlpTOrQAOLfi/1r/abAM3 6UWySXaWeI0sCtEkDcCJ4fgy1joeZJZNi5Sqfn1Eed+GVo4fLQFbrgbBkkg3Q+W+ WjkL0/bUxgRbvwKl7URmL/GCHPFAREw2Qqhk9tyPH+d5sQImZx0H4YlPxaHDyM8= =cxFS -----END PGP SIGNATURE----- From nobody Mon Aug 17 09:11:58 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104111B2ED9 for ; Mon, 17 Aug 2015 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkFs9WSi1stN for ; Mon, 17 Aug 2015 09:11:46 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id B81201B2ED3 for ; Mon, 17 Aug 2015 09:11:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,695,1432623600"; d="scan'208";a="72697103" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 17 Aug 2015 09:33:02 -0700 Received: from IRVEXCHMB15.corp.ad.broadcom.com ([fe80::3c14:d213:d2c9:b75a]) by IRVEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 17 Aug 2015 09:11:44 -0700 From: Minhua Zhou To: Jean-Marc Valin , "Arild Fuldseth (arilfuld)" , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ2QKyJla43Yq3qkW32sy32vOoUp4QVF+AgAB6AgD//44f8A== Date: Mon, 17 Aug 2015 16:11:43 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> In-Reply-To: <55D20498.30305@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:11:53 -0000 Are de-blocked neighboring samples used for intra prediction? -- Minhua -----Original Message----- From: Jean-Marc Valin [mailto:jmvalin@mozilla.com]=20 Sent: Monday, August 17, 2015 8:58 AM To: Minhua Zhou; Arild Fuldseth (arilfuld); video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/17/2015 11:44 AM, Minhua Zhou wrote: > 4) For the purpose of experimenting with Daala, it would be more >> convenient to do the deblocking recursively, first filtering the =20 >> inside of 16x16 blocks that are split into 8x8, then filtering the=20 >> inside of 32x32 blocks that are split into 16x16, then filtering=20 >> between 32x32 superblocks. Are there known reasons why this would be=20 >> a bad idea? >=20 > This filtering order might not be implementation friendly.. Could you=20 > please elaborate more on how this is done? Keep in mind that right now this is just for the purpose of experimentation= and it matches how the lapping is done (of course there's no lapping if we= use deblocking). The idea is simply that in the recursion, after 4 8x8 blo= cks are decoded, we can deblock the boundary between these 4 blocks and tre= at the result as a 16x16 block. Then higher up in the recursion, when we have 4 16x16 blocks, we again debl= ock the boundary between them. This is done all the way up to whatever supe= r-block size. Then, the superblocks are deblocked in order. Right now, I'm doing this mostly for convenience, but one potential advanta= ge of this ordering is that it makes it easy for the encoder to take the de= blocking filter into account when making block size decisions . Cheers, Jean-Marc > Regards, >=20 > Minhua >=20 >=20 > -----Original Message----- From: video-codec=20 > [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin > Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth (arilfuld);=20 > video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor >=20 > Hi Arild, >=20 > Thanks for your help. I'm about to have a simplified version of the=20 > Thor deblocking filter working for Daala intra frames. I'll post=20 > results when I have it fully working. >=20 > Cheers, >=20 > Jean-Marc >=20 > On 08/14/2015 03:31 AM, Arild Fuldseth (arilfuld) wrote: >> Hi Jean-Marc, >=20 >> Please see answers inline. >=20 >> Regards, >=20 >> Arild >=20 >> -----Original Message----- From: video-codec=20 >> [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin=20 >> Sent: 13. august 2015 21:30 To: video-codec@ietf.org >> Subject: [video-codec] Questions about Thor >=20 >> Hi, >=20 >> I'm trying to understand the Thor code base and had a few questions=20 >> on the deblocking filter and the VLC coding. >=20 >> 1) When deciding whether to filter, why does the deblocking filter=20 >> use the absolute value of the motion vectors on each side rather than=20 >> the difference between the two motion vectors? >=20 >> H.264/H.265 use motion vector differences. In Thor we decided to do=20 >> things a bit differently. We have found the impact on performance to=20 >> be marginal. >=20 >> 2) What does cbp stand for and why does the deblocking use cbp =3D=20 >> p_cbp || q_cbp; as a condition? >=20 >> CBP stands for Coded Block Pattern and is used to describe whether or=20 >> not a collection of blocks (typically 4 luma&2 chroma or 1 luma&2=20 >> chroma blocks) have non-zero coefficients or not. >> The condition p_cbp || q_cbp specifies that deblocking shall be=20 >> performed if one of the blocks on either side of the block boundary=20 >> has non-zero coefficients. >=20 >> 3) Considering that with NEW_DEBLOCK_TEST=3D1 (which is now the=20 >> default), the deblocking filter only seems to look at two pixels on=20 >> each side of an edge, are there any plans on adding deblocking to 4x4=20 >> blocks? >=20 >> We have no plans to introduce deblocking of 4x4 block edges and=20 >> looking at only two pixels at every side of a block edge is done for=20 >> an entirely different reason. The difference between using three=20 >> pixels and using two pixels is marginal. While H.264 does deblocking=20 >> on 4x4 block boundaries, considering only 8x8 block edges was one of=20 >> our inputs to the initial H.265 draft (for complexity reasons). It=20 >> survived several iterations of deblocking filter improvements during=20 >> the H.265 standardization process. >=20 >> 4) For the purpose of experimenting with Daala, it would be more =20 >> convenient to do the deblocking recursively, first filtering the =20 >> inside of 16x16 blocks that are split into 8x8, then filtering the=20 >> inside of 32x32 blocks that are split into 16x16, then filtering=20 >> between 32x32 superblocks. Are there known reasons why this would be=20 >> a bad idea? >=20 >> As long as all major block edges are filtered I guess it would be=20 >> OK? >=20 >> 5) Is there any documentation for what the different values of the=20 >> variable "n" mean in get_vlc(). >=20 >> The draft would have to be updated with this information. Thor uses=20 >> systematic VLC codes and "n" is used to choose between the various=20 >> VLC codes. Most of the VLC codes (n=3D0-10) are described in JCTVC-A119= =20 >> (last section of the decoder description). >=20 >> http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/J C > >> >>=20 TVC-A119.zip >=20 >> 6) Is there any way to get stats on how many bits are spend coding in=20 >> different contexts, e.g. for a particular video, how much of the bits=20 >> are used for motion vectors vs block modes vs residual, etc? If not,=20 >> any interest in using the bit accounting framework we have in Daala? >=20 >> Since the encoder does multiple encodings of each block (as part of=20 >> the RDO process), we found that it was most convenient to put bit=20 >> statistics in the decoder where each syntax element of every block is=20 >> processed only once. The decoder prints out some of the statistics by=20 >> default. >=20 >> Cheers, >=20 >> Jean-Marc >=20 >> _______________________________________________ video-codec mailing=20 >> list video-codec@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/video-codec >=20 >> _______________________________________________ video-codec mailing=20 >> list video-codec@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/video-codec >=20 >=20 > _______________________________________________ video-codec mailing=20 > list video-codec@ietf.org=20 > https://www.ietf.org/mailman/listinfo/video-codec >=20 > _______________________________________________ video-codec mailing=20 > list video-codec@ietf.org=20 > https://www.ietf.org/mailman/listinfo/video-codec >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0gSYAAoJEJ6/8sItn9q96tsIAL5fIbav8G/u2f7qC3ammLDe NXxNLvgTnbw6Spohyp8FdfUQ0xHVESVsgVYb6t96wmVcizymyaVRW3sP+7nvAj/I 1qZKd1PoHNhCikuF4Llr8LwgR3kKjHjgrPdnvw9ls85ZC3CrY5C8THkAmtv1+MGW 4dKFlQvDNa10uyLcH0DE6O7jJBtvMasIj8ZXFsSGvsjTlpTOrQAOLfi/1r/abAM3 6UWySXaWeI0sCtEkDcCJ4fgy1joeZJZNi5Sqfn1Eed+GVo4fLQFbrgbBkkg3Q+W+ WjkL0/bUxgRbvwKl7URmL/GCHPFAREw2Qqhk9tyPH+d5sQImZx0H4YlPxaHDyM8=3D =3DcxFS -----END PGP SIGNATURE----- From nobody Mon Aug 17 12:12:20 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8CB1B2F1E for ; Mon, 17 Aug 2015 12:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zKh5l5epssr for ; Mon, 17 Aug 2015 12:12:16 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB121B2F18 for ; Mon, 17 Aug 2015 12:12:16 -0700 (PDT) Received: by qged69 with SMTP id d69so100634905qge.0 for ; Mon, 17 Aug 2015 12:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=OvqwYqDUPU7vFOfSxaXDkce2bjrsKm4R+EwDe+6LIK8=; b=GDT5nrOaRimCj1Gmk3IZUrneJsZaQdAoU2m8FrhSl7TWoqz39JEQODlwDKnXFO9AdW jjuGG6PlI6JEF2MbTJrUY3NqSs7XkC3F+ATHyycxz6db8eeEHuvZfVo4/iD0qa/AzBiV X0Ts2Md5lBKnCtsO2CxLDlBtAAM7Y1g77QbADzCvTIHkn9hmzFMerPXD9cq9VmP9iuQJ ZNhhphdBv9NfXZ9JAwVQ9fkqMuZoP5D9iB2/22gguIIz13EYzrRkKSone6ErernaM6nZ ZvhNvWzGR+L+Qny+ot1cyYk/Av2UrIJzjHcywZkzt3oPFaBxYDeZVMCUunfXM/nRJNsJ robA== X-Gm-Message-State: ALoCoQkueSdhxCxbefT8MJOLGQdCzHbgiM2MZQeziqZCW7AYgZwRha5dRQ0BQ1AXudKL8yyxNjNV X-Received: by 10.140.235.143 with SMTP id g137mr5612314qhc.102.1439838735625; Mon, 17 Aug 2015 12:12:15 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by smtp.gmail.com with ESMTPSA id b196sm8808540qka.14.2015.08.17.12.12.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 12:12:15 -0700 (PDT) To: Minhua Zhou , "Arild Fuldseth (arilfuld)" , "video-codec@ietf.org" References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> From: Jean-Marc Valin Message-ID: <55D2320E.5030504@mozilla.com> Date: Mon, 17 Aug 2015 15:12:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:12:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/17/2015 12:11 PM, Minhua Zhou wrote: > Are de-blocked neighboring samples used for intra prediction? -- > Minhua Well, right now Daala doesn't really have intra prediction. But even if it did, the prediction would work on the pixels before deblocking (otherwise you get a chicken-and-egg problem). Jean-Marc > -----Original Message----- From: Jean-Marc Valin > [mailto:jmvalin@mozilla.com] Sent: Monday, August 17, 2015 8:58 AM > To: Minhua Zhou; Arild Fuldseth (arilfuld); video-codec@ietf.org > Subject: Re: [video-codec] Questions about Thor > > On 08/17/2015 11:44 AM, Minhua Zhou wrote: >> 4) For the purpose of experimenting with Daala, it would be more >>> convenient to do the deblocking recursively, first filtering >>> the inside of 16x16 blocks that are split into 8x8, then >>> filtering the inside of 32x32 blocks that are split into 16x16, >>> then filtering between 32x32 superblocks. Are there known >>> reasons why this would be a bad idea? > >> This filtering order might not be implementation friendly.. Could >> you please elaborate more on how this is done? > > Keep in mind that right now this is just for the purpose of > experimentation and it matches how the lapping is done (of course > there's no lapping if we use deblocking). The idea is simply that > in the recursion, after 4 8x8 blocks are decoded, we can deblock > the boundary between these 4 blocks and treat the result as a 16x16 > block. Then higher up in the recursion, when we have 4 16x16 > blocks, we again deblock the boundary between them. This is done > all the way up to whatever super-block size. Then, the superblocks > are deblocked in order. > > Right now, I'm doing this mostly for convenience, but one potential > advantage of this ordering is that it makes it easy for the encoder > to take the deblocking filter into account when making block size > decisions . > > Cheers, > > Jean-Marc > >> Regards, > >> Minhua > > >> -----Original Message----- From: video-codec >> [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc >> Valin Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth >> (arilfuld); video-codec@ietf.org Subject: Re: [video-codec] >> Questions about Thor > >> Hi Arild, > >> Thanks for your help. I'm about to have a simplified version of >> the Thor deblocking filter working for Daala intra frames. I'll >> post results when I have it fully working. > >> Cheers, > >> Jean-Marc > >> On 08/14/2015 03:31 AM, Arild Fuldseth (arilfuld) wrote: >>> Hi Jean-Marc, > >>> Please see answers inline. > >>> Regards, > >>> Arild > >>> -----Original Message----- From: video-codec >>> [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc >>> Valin Sent: 13. august 2015 21:30 To: video-codec@ietf.org >>> Subject: [video-codec] Questions about Thor > >>> Hi, > >>> I'm trying to understand the Thor code base and had a few >>> questions on the deblocking filter and the VLC coding. > >>> 1) When deciding whether to filter, why does the deblocking >>> filter use the absolute value of the motion vectors on each >>> side rather than the difference between the two motion >>> vectors? > >>> H.264/H.265 use motion vector differences. In Thor we decided >>> to do things a bit differently. We have found the impact on >>> performance to be marginal. > >>> 2) What does cbp stand for and why does the deblocking use cbp >>> = p_cbp || q_cbp; as a condition? > >>> CBP stands for Coded Block Pattern and is used to describe >>> whether or not a collection of blocks (typically 4 luma&2 >>> chroma or 1 luma&2 chroma blocks) have non-zero coefficients or >>> not. The condition p_cbp || q_cbp specifies that deblocking >>> shall be performed if one of the blocks on either side of the >>> block boundary has non-zero coefficients. > >>> 3) Considering that with NEW_DEBLOCK_TEST=1 (which is now the >>> default), the deblocking filter only seems to look at two >>> pixels on each side of an edge, are there any plans on adding >>> deblocking to 4x4 blocks? > >>> We have no plans to introduce deblocking of 4x4 block edges and >>> looking at only two pixels at every side of a block edge is >>> done for an entirely different reason. The difference between >>> using three pixels and using two pixels is marginal. While >>> H.264 does deblocking on 4x4 block boundaries, considering only >>> 8x8 block edges was one of our inputs to the initial H.265 >>> draft (for complexity reasons). It survived several iterations >>> of deblocking filter improvements during the H.265 >>> standardization process. > >>> 4) For the purpose of experimenting with Daala, it would be >>> more convenient to do the deblocking recursively, first >>> filtering the inside of 16x16 blocks that are split into 8x8, >>> then filtering the inside of 32x32 blocks that are split into >>> 16x16, then filtering between 32x32 superblocks. Are there >>> known reasons why this would be a bad idea? > >>> As long as all major block edges are filtered I guess it would >>> be OK? > >>> 5) Is there any documentation for what the different values of >>> the variable "n" mean in get_vlc(). > >>> The draft would have to be updated with this information. Thor >>> uses systematic VLC codes and "n" is used to choose between the >>> various VLC codes. Most of the VLC codes (n=0-10) are described >>> in JCTVC-A119 (last section of the decoder description). > >>> http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/ J > >>> C > >>> >>> > TVC-A119.zip > >>> 6) Is there any way to get stats on how many bits are spend >>> coding in different contexts, e.g. for a particular video, how >>> much of the bits are used for motion vectors vs block modes vs >>> residual, etc? If not, any interest in using the bit accounting >>> framework we have in Daala? > >>> Since the encoder does multiple encodings of each block (as >>> part of the RDO process), we found that it was most convenient >>> to put bit statistics in the decoder where each syntax element >>> of every block is processed only once. The decoder prints out >>> some of the statistics by default. > >>> Cheers, > >>> Jean-Marc > >>> _______________________________________________ video-codec >>> mailing list video-codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/video-codec > >>> _______________________________________________ video-codec >>> mailing list video-codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/video-codec > > >> _______________________________________________ video-codec >> mailing list video-codec@ietf.org >> https://www.ietf.org/mailman/listinfo/video-codec > >> _______________________________________________ video-codec >> mailing list video-codec@ietf.org >> https://www.ietf.org/mailman/listinfo/video-codec > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0jILAAoJEJ6/8sItn9q93M4H/jduI+GVH+F5qaTHaIzCx0Mi 8LCnZvtcsoyCwU8jjmaphcBNbUHeU1Y4Bh5P2XjmLKDQ8s8prLP8zhBN+HYdd26s y6koZ4O89DUrYSH/e1AYcQkQTXeNfZK2MYES/z59eYkSgpaFrXHbU7wa12xavpz9 fEo3ZJ5J4JYk7KUk/Ji/Z2u2o6ASzYkkCFCql8Gycv00IJ9LD4IKpd6oMDzEROdM 1GZencAulKr7ifRaY5PBbRRUJoBl59dsPDnjgAsZb3V/yIwtCthmbkihOYpC55Qm edQKuujxC+vXDUlXiCxLSdhA2w9MDkJBkQt9MXzKgB0VeDefuyCoI8OmZxtNxzk= =QQqr -----END PGP SIGNATURE----- From nobody Mon Aug 17 12:21:42 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652D91B2F4C for ; Mon, 17 Aug 2015 12:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb5PARzoolOL for ; Mon, 17 Aug 2015 12:21:37 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD861B2F49 for ; Mon, 17 Aug 2015 12:21:36 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 17 Aug 2015 15:21:35 -0400 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 17 Aug 2015 15:21:35 -0400 Received: from XMB102FCNC.rim.net ([fe80::d821:2880:9aba:1a40]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 17 Aug 2015 15:21:35 -0400 From: Dake He To: Jean-Marc Valin , Minhua Zhou , "Arild Fuldseth (arilfuld)" , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ1f6IFLUqdlvAPE+3AZVkfrCDYZ4LXWyAgAU+7wCAAAHZgIAAA+sAgAADwoCAADJwAP//vsXw Date: Mon, 17 Aug 2015 19:21:34 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> In-Reply-To: <55D2320E.5030504@mozilla.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:21:40 -0000 depending upon how deblocking is implemented, it is possible to use deblock= ed samples for intra prediction.=20 --Dake -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-M= arc Valin Sent: Monday, August 17, 2015 3:12 PM To: Minhua Zhou; Arild Fuldseth (arilfuld); video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/17/2015 12:11 PM, Minhua Zhou wrote: > Are de-blocked neighboring samples used for intra prediction? --=20 > Minhua Well, right now Daala doesn't really have intra prediction. But even if it = did, the prediction would work on the pixels before deblocking (otherwise y= ou get a chicken-and-egg problem). Jean-Marc > -----Original Message----- From: Jean-Marc Valin=20 > [mailto:jmvalin@mozilla.com] Sent: Monday, August 17, 2015 8:58 AM > To: Minhua Zhou; Arild Fuldseth (arilfuld); video-codec@ietf.org > Subject: Re: [video-codec] Questions about Thor >=20 > On 08/17/2015 11:44 AM, Minhua Zhou wrote: >> 4) For the purpose of experimenting with Daala, it would be more >>> convenient to do the deblocking recursively, first filtering the=20 >>> inside of 16x16 blocks that are split into 8x8, then filtering the=20 >>> inside of 32x32 blocks that are split into 16x16, then filtering=20 >>> between 32x32 superblocks. Are there known reasons why this would be=20 >>> a bad idea? >=20 >> This filtering order might not be implementation friendly.. Could you=20 >> please elaborate more on how this is done? >=20 > Keep in mind that right now this is just for the purpose of=20 > experimentation and it matches how the lapping is done (of course=20 > there's no lapping if we use deblocking). The idea is simply that in=20 > the recursion, after 4 8x8 blocks are decoded, we can deblock the=20 > boundary between these 4 blocks and treat the result as a 16x16 block.=20 > Then higher up in the recursion, when we have 4 16x16 blocks, we again=20 > deblock the boundary between them. This is done all the way up to=20 > whatever super-block size. Then, the superblocks are deblocked in=20 > order. >=20 > Right now, I'm doing this mostly for convenience, but one potential=20 > advantage of this ordering is that it makes it easy for the encoder to=20 > take the deblocking filter into account when making block size=20 > decisions . >=20 > Cheers, >=20 > Jean-Marc >=20 >> Regards, >=20 >> Minhua >=20 >=20 >> -----Original Message----- From: video-codec=20 >> [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin=20 >> Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth (arilfuld);=20 >> video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor >=20 >> Hi Arild, >=20 >> Thanks for your help. I'm about to have a simplified version of the=20 >> Thor deblocking filter working for Daala intra frames. I'll post=20 >> results when I have it fully working. >=20 >> Cheers, >=20 >> Jean-Marc >=20 >> On 08/14/2015 03:31 AM, Arild Fuldseth (arilfuld) wrote: >>> Hi Jean-Marc, >=20 >>> Please see answers inline. >=20 >>> Regards, >=20 >>> Arild >=20 >>> -----Original Message----- From: video-codec=20 >>> [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin=20 >>> Sent: 13. august 2015 21:30 To: video-codec@ietf.org >>> Subject: [video-codec] Questions about Thor >=20 >>> Hi, >=20 >>> I'm trying to understand the Thor code base and had a few questions=20 >>> on the deblocking filter and the VLC coding. >=20 >>> 1) When deciding whether to filter, why does the deblocking filter=20 >>> use the absolute value of the motion vectors on each side rather=20 >>> than the difference between the two motion vectors? >=20 >>> H.264/H.265 use motion vector differences. In Thor we decided to do=20 >>> things a bit differently. We have found the impact on performance to=20 >>> be marginal. >=20 >>> 2) What does cbp stand for and why does the deblocking use cbp =3D=20 >>> p_cbp || q_cbp; as a condition? >=20 >>> CBP stands for Coded Block Pattern and is used to describe whether=20 >>> or not a collection of blocks (typically 4 luma&2 chroma or 1 luma&2=20 >>> chroma blocks) have non-zero coefficients or not. The condition=20 >>> p_cbp || q_cbp specifies that deblocking shall be performed if one=20 >>> of the blocks on either side of the block boundary has non-zero=20 >>> coefficients. >=20 >>> 3) Considering that with NEW_DEBLOCK_TEST=3D1 (which is now the=20 >>> default), the deblocking filter only seems to look at two pixels on=20 >>> each side of an edge, are there any plans on adding deblocking to=20 >>> 4x4 blocks? >=20 >>> We have no plans to introduce deblocking of 4x4 block edges and =20 >>> looking at only two pixels at every side of a block edge is done for=20 >>> an entirely different reason. The difference between using three=20 >>> pixels and using two pixels is marginal. While >>> H.264 does deblocking on 4x4 block boundaries, considering only >>> 8x8 block edges was one of our inputs to the initial H.265 draft=20 >>> (for complexity reasons). It survived several iterations of=20 >>> deblocking filter improvements during the H.265 standardization=20 >>> process. >=20 >>> 4) For the purpose of experimenting with Daala, it would be more=20 >>> convenient to do the deblocking recursively, first filtering the=20 >>> inside of 16x16 blocks that are split into 8x8, then filtering the=20 >>> inside of 32x32 blocks that are split into 16x16, then filtering=20 >>> between 32x32 superblocks. Are there known reasons why this would be=20 >>> a bad idea? >=20 >>> As long as all major block edges are filtered I guess it would be=20 >>> OK? >=20 >>> 5) Is there any documentation for what the different values of the=20 >>> variable "n" mean in get_vlc(). >=20 >>> The draft would have to be updated with this information. Thor uses=20 >>> systematic VLC codes and "n" is used to choose between the various=20 >>> VLC codes. Most of the VLC codes (n=3D0-10) are described in=20 >>> JCTVC-A119 (last section of the decoder description). >=20 >>> http://phenix.int-evry.fr/jct/doc_end_user/documents/1_Dresden/wg11/ J > >>>=20 C >=20 >>>=20 >>>=20 > TVC-A119.zip >=20 >>> 6) Is there any way to get stats on how many bits are spend coding=20 >>> in different contexts, e.g. for a particular video, how much of the=20 >>> bits are used for motion vectors vs block modes vs residual, etc? If=20 >>> not, any interest in using the bit accounting framework we have in=20 >>> Daala? >=20 >>> Since the encoder does multiple encodings of each block (as part of=20 >>> the RDO process), we found that it was most convenient to put bit=20 >>> statistics in the decoder where each syntax element of every block=20 >>> is processed only once. The decoder prints out some of the=20 >>> statistics by default. >=20 >>> Cheers, >=20 >>> Jean-Marc >=20 >>> _______________________________________________ video-codec mailing=20 >>> list video-codec@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/video-codec >=20 >>> _______________________________________________ video-codec mailing=20 >>> list video-codec@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/video-codec >=20 >=20 >> _______________________________________________ video-codec mailing=20 >> list video-codec@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/video-codec >=20 >> _______________________________________________ video-codec mailing=20 >> list video-codec@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/video-codec >=20 >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0jILAAoJEJ6/8sItn9q93M4H/jduI+GVH+F5qaTHaIzCx0Mi 8LCnZvtcsoyCwU8jjmaphcBNbUHeU1Y4Bh5P2XjmLKDQ8s8prLP8zhBN+HYdd26s y6koZ4O89DUrYSH/e1AYcQkQTXeNfZK2MYES/z59eYkSgpaFrXHbU7wa12xavpz9 fEo3ZJ5J4JYk7KUk/Ji/Z2u2o6ASzYkkCFCql8Gycv00IJ9LD4IKpd6oMDzEROdM 1GZencAulKr7ifRaY5PBbRRUJoBl59dsPDnjgAsZb3V/yIwtCthmbkihOYpC55Qm edQKuujxC+vXDUlXiCxLSdhA2w9MDkJBkQt9MXzKgB0VeDefuyCoI8OmZxtNxzk=3D =3DQQqr -----END PGP SIGNATURE----- _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From nobody Mon Aug 17 12:33:48 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84E91B2F76 for ; Mon, 17 Aug 2015 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu-RMPZAxaTa for ; Mon, 17 Aug 2015 12:33:45 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADDE1B2F52 for ; Mon, 17 Aug 2015 12:33:44 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id A317CC07A3 for ; Mon, 17 Aug 2015 19:33:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZjJhQnwi20a for ; Mon, 17 Aug 2015 19:33:44 +0000 (UTC) Received: from [10.252.28.69] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 6CC6DC053F for ; Mon, 17 Aug 2015 19:33:44 +0000 (UTC) Message-ID: <55D23718.103@xiph.org> Date: Mon, 17 Aug 2015 12:33:44 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "video-codec@ietf.org" References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:33:47 -0000 Dake He wrote: > depending upon how deblocking is implemented, it is possible to use deblocked samples for intra prediction. Well, certainly if you implement it in the order Jean-Marc was describing, you could apply deblocking to pixels along interior edges before using them to predict adjacent blocks along an exterior edge, but I believe that was one of the "not implementation friendly" things Minhua Zhou was complaining about. It means your hardware can't pipeline reconstruction of those neighboring blocks until it has the deblocked pixels, which is fairly late in the process. From nobody Mon Aug 17 12:49:45 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168021B2F79 for ; Mon, 17 Aug 2015 12:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAGSOzy2uVeU for ; Mon, 17 Aug 2015 12:49:40 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28AE1B2ECA for ; Mon, 17 Aug 2015 12:49:40 -0700 (PDT) Received: by qgdd90 with SMTP id d90so101781334qgd.3 for ; Mon, 17 Aug 2015 12:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=leMuFyVVoZNxaRjAXkLgyox2kjI+OkSKNy+jQFd/wUc=; b=VUirGuDPQfvNmxR1O5uZsHIwSqyYw3jAtih0fenj29XiX/8RwJmMTMynmrTdmc8x8n FIi/bOhI3tDvoZifrRtVGE0XvkNl/g7yl0Rbo+b01wgTEt6pzUo7BjWjBN2vZf2Hoqp+ 17LYv4mLmrOkzqQC8FnN52qZbXJZm57IJ+k4ThW06AtLX3ADWjQHfCLYdOQ44q8LSAks QYN8pwTnxV3q8kzfVe838eSla/oI+4ucu5UpOVhRySMvAIvUv0DRa9KvT9YYo2WovYAZ Qku7efBada/mSqPE8N1vjw8IMbT9+a4IS8M+AkJoAjRa/wx4Qku6243TsmKvCmiqs6Pv CKkQ== X-Gm-Message-State: ALoCoQmZSwCiNK9kZiqlrSObJtWXTuiTw8VRLgoKBdXT0DBzZcPweNTKau50qw78yZayts5Ti48S X-Received: by 10.140.108.10 with SMTP id i10mr5609929qgf.75.1439840979897; Mon, 17 Aug 2015 12:49:39 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by smtp.gmail.com with ESMTPSA id c109sm8795941qga.16.2015.08.17.12.49.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 12:49:39 -0700 (PDT) To: "Timothy B. Terriberry" , "video-codec@ietf.org" References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> <55D23718.103@xiph.org> From: Jean-Marc Valin Message-ID: <55D23AD2.5080501@jmvalin.ca> Date: Mon, 17 Aug 2015 15:49:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55D23718.103@xiph.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:49:42 -0000 On 08/17/2015 03:33 PM, Timothy B. Terriberry wrote: > Well, certainly if you implement it in the order Jean-Marc was > describing, you could apply deblocking to pixels along interior edges > before using them to predict adjacent blocks along an exterior edge, but > I believe that was one of the "not implementation friendly" things > Minhua Zhou was complaining about. It means your hardware can't pipeline > reconstruction of those neighboring blocks until it has the deblocked > pixels, which is fairly late in the process. Well, most intra predictors use only the pixels on the edges of the block, so the interior pixels -- deblocked or not -- aren't used at all. In that case, the "recursive deblocking" is just equivalent to decoding the entire image and then deblocking rows/columns that are multiples of 8 but not 16 first, then deblocking those are are multiples of 16 but not 32, then deblocking the rest... Jean-Marc From nobody Mon Aug 17 13:01:18 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6945F1ACDA9 for ; Mon, 17 Aug 2015 13:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK5v2N1ebdFM for ; Mon, 17 Aug 2015 13:01:11 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77C1A8967 for ; Mon, 17 Aug 2015 13:01:11 -0700 (PDT) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 17 Aug 2015 16:01:10 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 17 Aug 2015 16:01:10 -0400 Received: from XMB102FCNC.rim.net ([fe80::d821:2880:9aba:1a40]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 17 Aug 2015 16:01:10 -0400 From: Dake He To: Jean-Marc Valin , "Timothy B. Terriberry" , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ1f6IFLUqdlvAPE+3AZVkfrCDYZ4LXWyAgAU+7wCAAAHZgIAAA+sAgAADwoCAADJwAP//vsXwgABHPACAAARyAP//vg5g Date: Mon, 17 Aug 2015 20:01:09 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> <55D23718.103@xiph.org> <55D23AD2.5080501@jmvalin.ca> In-Reply-To: <55D23AD2.5080501@jmvalin.ca> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 20:01:17 -0000 Minhua might not like it, but still technically possible (otherwise he woul= d not have asked the question in the first place) with careful ordering of = processing steps of deblocking (vertical/horizontal) and prediction.=20 --Dake -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-M= arc Valin Sent: Monday, August 17, 2015 3:50 PM To: Timothy B. Terriberry; video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor On 08/17/2015 03:33 PM, Timothy B. Terriberry wrote: > Well, certainly if you implement it in the order Jean-Marc was=20 > describing, you could apply deblocking to pixels along interior edges=20 > before using them to predict adjacent blocks along an exterior edge,=20 > but I believe that was one of the "not implementation friendly" things=20 > Minhua Zhou was complaining about. It means your hardware can't=20 > pipeline reconstruction of those neighboring blocks until it has the=20 > deblocked pixels, which is fairly late in the process. Well, most intra predictors use only the pixels on the edges of the block, = so the interior pixels -- deblocked or not -- aren't used at all. In that case, the "recursive deblocking" is just equivalent to decoding the= entire image and then deblocking rows/columns that are multiples of 8 but not 16 first, then deblocking those are are multiples of 16 but not 3= 2, then deblocking the rest... Jean-Marc _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From nobody Mon Aug 17 13:21:46 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C161E1A033A for ; Mon, 17 Aug 2015 13:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kGNPPrIxoRZ for ; Mon, 17 Aug 2015 13:21:43 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB4F1A0338 for ; Mon, 17 Aug 2015 13:21:43 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 14D9CC44FC for ; Mon, 17 Aug 2015 20:21:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgh9itc-s-2g for ; Mon, 17 Aug 2015 20:21:43 +0000 (UTC) Received: from [10.252.28.69] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id EC4D2C41B0 for ; Mon, 17 Aug 2015 20:21:42 +0000 (UTC) Message-ID: <55D24256.6000607@xiph.org> Date: Mon, 17 Aug 2015 13:21:42 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "video-codec@ietf.org" References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> <55D23718.103@xiph.org> <55D23AD2.5080501@jmvalin.ca> In-Reply-To: <55D23AD2.5080501@jmvalin.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 20:21:44 -0000 Jean-Marc Valin wrote: > Well, most intra predictors use only the pixels on the edges of the > block, so the interior pixels -- deblocked or not -- aren't used at all. A) That's no longer true. They run filters which may include interior pixels now. B) What I meant by "interior edges" includes pixels on the exterior edge of the block, e.g., A B *---+---*-------* | ║ | | +===+===+ | | ║ | | *---+---*-------* Here ║ and = represent interior edges which need to be deblocked, and the four blocks in A are used to predict the single block in B (though it would not matter how B is split). The interior edge separating the top and bottom blocks includes pixels on the very right edge of A, and it matters whether they are deblocked or not before predicting B. From nobody Tue Aug 18 01:56:52 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3231ACCE5 for ; Tue, 18 Aug 2015 01:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG9UbY-fISBM for ; Tue, 18 Aug 2015 01:56:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AEB1A0052 for ; Tue, 18 Aug 2015 01:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1791; q=dns/txt; s=iport; t=1439888206; x=1441097806; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VUvt9duTOjM9IAaZ/GsZUmwRFM5J1ooc9pBNQmOQhO4=; b=hBl14vf32LGpFTfcPBiGFb89OFXczk5gMDpbo+jytfRyIsiI62mm0n8+ ZcJQB6jR7axBdch3lQUZ4dbnLWW/GWrq7pZ37xf2x5BjxYADP1r+vubkM vcUIBuB2eTafIdgHe1/DLsfOIiCsgQ+bPPgktX/qO+Rr5JzdjHrhkOh8Y Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3AgAC8tJV/4YNJK1dgxtUaQaDHrpXAQmBbAqFeQKBLjgUAQEBAQEBAYEKhCMBAQEEAQEBARxOBhUCAQgRBAEBAQokJwsdCAIEARIIiCYNuX0IljEBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEgijKEWDiCZzGBFAWVIAGHb4ZGlH6DZyaDfXGBSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,700,1432598400"; d="scan'208";a="24894013" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 18 Aug 2015 08:56:45 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t7I8uj8a006745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2015 08:56:45 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 18 Aug 2015 03:56:44 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 18 Aug 2015 03:56:44 -0500 Received: from xmb-rcd-x07.cisco.com ([169.254.7.70]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Tue, 18 Aug 2015 03:56:43 -0500 From: "Thomas Davies (thdavies)" To: Jean-Marc Valin , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ1f6EgupW0ivEz0WCdUl11ffAE54Lbi+AgAU+8ACAAAHZgIAAA+sAgAADwoCAADJvAIAAApwAgAADZgCAAARxAIAACPYAgAB4ZK0= Date: Tue, 18 Aug 2015 08:56:43 +0000 Message-ID: <9C2FAEDF6B678042ADE3B6686D7C6E152D0A5C65@xmb-rcd-x07.cisco.com> References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> <55D23718.103@xiph.org> <55D23AD2.5080501@jmvalin.ca>,<55D24256.6000607@xiph.org> In-Reply-To: <55D24256.6000607@xiph.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.16] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 08:56:50 -0000 Jean-Marc=0A= =0A= To answer your original question, I think it's best from an implementation = perspective not to impose an order on visiting blocks for deblocking if pos= sible. It's pretty useful at least for SW optimisation to have a range of o= ptions for ordering how edges are visited and how the V and H stages intera= ct with that.=0A= =0A= best regards=0A= =0A= Thomas=0A= =0A= =0A= ________________________________________=0A= From: video-codec [video-codec-bounces@ietf.org] on behalf of Timothy B. Te= rriberry [tterribe@xiph.org]=0A= Sent: 17 August 2015 21:21=0A= To: video-codec@ietf.org=0A= Subject: Re: [video-codec] Questions about Thor=0A= =0A= Jean-Marc Valin wrote:=0A= > Well, most intra predictors use only the pixels on the edges of the=0A= > block, so the interior pixels -- deblocked or not -- aren't used at all.= =0A= =0A= A) That's no longer true. They run filters which may include interior=0A= pixels now.=0A= =0A= B) What I meant by "interior edges" includes pixels on the exterior edge=0A= of the block, e.g.,=0A= =0A= A B=0A= *---+---*-------*=0A= | =A1 | |=0A= +=3D=3D=3D+=3D=3D=3D+ |=0A= | =A1 | |=0A= *---+---*-------*=0A= =0A= Here =A1 and =3D represent interior edges which need to be deblocked, and= =0A= the four blocks in A are used to predict the single block in B (though=0A= it would not matter how B is split). The interior edge separating the=0A= top and bottom blocks includes pixels on the very right edge of A, and=0A= it matters whether they are deblocked or not before predicting B.=0A= =0A= _______________________________________________=0A= video-codec mailing list=0A= video-codec@ietf.org=0A= https://www.ietf.org/mailman/listinfo/video-codec=0A= From nobody Tue Aug 18 08:55:48 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAFC1A877F for ; Tue, 18 Aug 2015 08:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlPssEGsiLub for ; Tue, 18 Aug 2015 08:55:46 -0700 (PDT) Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5CA1A8750 for ; Tue, 18 Aug 2015 08:55:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,702,1432623600"; d="scan'208";a="72877521" Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw1-out.broadcom.com with ESMTP; 18 Aug 2015 10:19:53 -0700 Received: from IRVEXCHMB15.corp.ad.broadcom.com ([fe80::3c14:d213:d2c9:b75a]) by IRVEXCHCAS07.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Tue, 18 Aug 2015 08:55:44 -0700 From: Minhua Zhou To: Dake He , Jean-Marc Valin , "Timothy B. Terriberry" , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ2QKyJla43Yq3qkW32sy32vOoUp4QVF+AgAB6AgD//44f8IAAqBMAgAACmwCAAANnAIAABHEAgAADOICAANeBoA== Date: Tue, 18 Aug 2015 15:55:44 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> <55D23718.103@xiph.org> <55D23AD2.5080501@jmvalin.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 15:55:47 -0000 Any idea about the quality again by using the de-blocked reference samples = in intra prediction? Agree that it is possible technically, but architectur= e wise this would create a nightmare for HW. Of course, if there was signif= icant gain, we could take a second look. -- Minhua -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Dake H= e Sent: Monday, August 17, 2015 1:01 PM To: Jean-Marc Valin; Timothy B. Terriberry; video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor Minhua might not like it, but still technically possible (otherwise he woul= d not have asked the question in the first place) with careful ordering of = processing steps of deblocking (vertical/horizontal) and prediction.=20 --Dake -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-M= arc Valin Sent: Monday, August 17, 2015 3:50 PM To: Timothy B. Terriberry; video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor On 08/17/2015 03:33 PM, Timothy B. Terriberry wrote: > Well, certainly if you implement it in the order Jean-Marc was=20 > describing, you could apply deblocking to pixels along interior edges=20 > before using them to predict adjacent blocks along an exterior edge,=20 > but I believe that was one of the "not implementation friendly" things=20 > Minhua Zhou was complaining about. It means your hardware can't=20 > pipeline reconstruction of those neighboring blocks until it has the=20 > deblocked pixels, which is fairly late in the process. Well, most intra predictors use only the pixels on the edges of the block, = so the interior pixels -- deblocked or not -- aren't used at all. In that case, the "recursive deblocking" is just equivalent to decoding the= entire image and then deblocking rows/columns that are multiples of 8 but not 16 first, then deblocking those are are multiples of 16 but not 3= 2, then deblocking the rest... Jean-Marc _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From nobody Wed Aug 19 15:44:12 2015 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037C61A89A6 for ; Wed, 19 Aug 2015 15:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07Pd7ZRqso52 for ; Wed, 19 Aug 2015 15:44:10 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D48F61A21AE for ; Wed, 19 Aug 2015 15:44:09 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT104CNC.rim.net) ([10.65.161.204]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 19 Aug 2015 18:44:08 -0400 Received: from XMB102FCNC.rim.net ([fe80::d821:2880:9aba:1a40]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 19 Aug 2015 18:44:08 -0400 From: Dake He To: Minhua Zhou , Jean-Marc Valin , "Timothy B. Terriberry" , "video-codec@ietf.org" Thread-Topic: [video-codec] Questions about Thor Thread-Index: AQHQ1f6IFLUqdlvAPE+3AZVkfrCDYZ4LXWyAgAU+7wCAAAHZgIAAA+sAgAADwoCAADJwAP//vsXwgABHPACAAARyAP//vg5ggAGS7QCAAb7sgA== Date: Wed, 19 Aug 2015 22:44:07 +0000 Message-ID: References: <55CCF049.8050206@mozilla.com> <55D1FFC2.1020800@mozilla.com> <55D20498.30305@mozilla.com> <55D2320E.5030504@mozilla.com> <55D23718.103@xiph.org> <55D23AD2.5080501@jmvalin.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [video-codec] Questions about Thor X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 22:44:12 -0000 This was discussed in 2009 at VCEG in the context of AVC if my memory is co= rrect. I don't recall there were exact numbers on the quality gain, at leas= t not cross-checked ones. But it should be in the same range as the gain of= fered by the smoothing filter for intra prediction in HEVC. There is some, = but probably not something to get too excited about.=20 --Dake -----Original Message----- From: Minhua Zhou [mailto:minhua@broadcom.com]=20 Sent: Tuesday, August 18, 2015 11:56 AM To: Dake He; Jean-Marc Valin; Timothy B. Terriberry; video-codec@ietf.org Subject: RE: [video-codec] Questions about Thor Any idea about the quality again by using the de-blocked reference samples = in intra prediction? Agree that it is possible technically, but architectur= e wise this would create a nightmare for HW. Of course, if there was signif= icant gain, we could take a second look. -- Minhua -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Dake H= e Sent: Monday, August 17, 2015 1:01 PM To: Jean-Marc Valin; Timothy B. Terriberry; video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor Minhua might not like it, but still technically possible (otherwise he woul= d not have asked the question in the first place) with careful ordering of = processing steps of deblocking (vertical/horizontal) and prediction.=20 --Dake -----Original Message----- From: video-codec [mailto:video-codec-bounces@ietf.org] On Behalf Of Jean-M= arc Valin Sent: Monday, August 17, 2015 3:50 PM To: Timothy B. Terriberry; video-codec@ietf.org Subject: Re: [video-codec] Questions about Thor On 08/17/2015 03:33 PM, Timothy B. Terriberry wrote: > Well, certainly if you implement it in the order Jean-Marc was=20 > describing, you could apply deblocking to pixels along interior edges=20 > before using them to predict adjacent blocks along an exterior edge,=20 > but I believe that was one of the "not implementation friendly" things=20 > Minhua Zhou was complaining about. It means your hardware can't=20 > pipeline reconstruction of those neighboring blocks until it has the=20 > deblocked pixels, which is fairly late in the process. Well, most intra predictors use only the pixels on the edges of the block, = so the interior pixels -- deblocked or not -- aren't used at all. In that case, the "recursive deblocking" is just equivalent to decoding the= entire image and then deblocking rows/columns that are multiples of 8 but not 16 first, then deblocking those are are multiples of 16 but not 3= 2, then deblocking the rest... Jean-Marc _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec