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