Hi Jean-Marc, 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? 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 -----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:[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/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 [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 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----- _______________________________________________ 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
