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