-----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
