depending upon how deblocking is implemented, it is possible to use deblocked samples for intra prediction.
--Dake -----Original Message----- From: video-codec [mailto:[email protected]] On Behalf Of Jean-Marc Valin Sent: Monday, August 17, 2015 3:12 PM To: Minhua Zhou; Arild Fuldseth (arilfuld); [email protected] 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? -- > 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:[email protected]] Sent: Monday, August 17, 2015 8:58 AM > To: Minhua Zhou; Arild Fuldseth (arilfuld); [email protected] > 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:[email protected]] On Behalf Of Jean-Marc Valin >> Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth (arilfuld); >> [email protected] 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:[email protected]] On Behalf Of Jean-Marc Valin >>> Sent: 13. august 2015 21:30 To: [email protected] >>> 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 [email protected] >>> https://www.ietf.org/mailman/listinfo/video-codec > >>> _______________________________________________ video-codec mailing >>> list [email protected] >>> https://www.ietf.org/mailman/listinfo/video-codec > > >> _______________________________________________ video-codec mailing >> list [email protected] >> https://www.ietf.org/mailman/listinfo/video-codec > >> _______________________________________________ video-codec mailing >> list [email protected] >> 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----- _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
