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 -----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? 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/JCTVC-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 -----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 [email protected] https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
