Subject: [video-codec] Questions about Thor

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 13 Aug 2015 15:30:17 -0400

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

---

From: Yushin Cho <[email-masked]>
Date: Thu, 13 Aug 2015 13:03:43 -0700

Regarding 2), cbp = p_cbp || q_cbp; is true if at least one of two blocks
(p or q) has non-zero coefficient coded.

On Thu, Aug 13, 2015 at 12:30 PM, Jean-Marc Valin <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> -----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-masked]
> https://www.ietf.org/mailman/listinfo/video-codec
>

-- 
Thanks!
Yushin

---

From: "Arild Fuldseth (arilfuld)" <[email-masked]>
Date: Fri, 14 Aug 2015 07:31:05 +0000

Hi Jean-Marc,

Please see answers inline.

Regards,

Arild

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: 13. august 2015 21:30
To: [email-masked]
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/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

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 17 Aug 2015 11:37:38 -0400

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:
> -----Original Message----- From: video-codec
> [mailto:[email-masked]] On Behalf Of Jean-Marc Valin 
> Sent: 13. august 2015 21:30 To: [email-masked] 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.
> 
> 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.
> 
> 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.
> 
> between 32x32 superblocks. Are there known reasons why this would
> be a bad idea?
> 
> 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).
> 
>  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-masked] 
> _______________________________________________ video-codec mailing
> list [email-masked]

---

From: Minhua Zhou <[email-masked]>
Date: Mon, 17 Aug 2015 15:44:15 +0000

Hi Jean-Marc,

> between 32x32 superblocks. Are there known reasons why this would be a 

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-masked]] On Behalf Of Jean-Marc Valin
Sent: Monday, August 17, 2015 8:38 AM
To: Arild Fuldseth (arilfuld); [email-masked]
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:
> things a bit differently. We have found the impact on performance to 
> be marginal.
> 
> 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.
> 
> 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.
> 
> 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
> 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?
> 
> 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
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 17 Aug 2015 11:58:16 -0400

On 08/17/2015 11:44 AM, Minhua Zhou wrote:
>>  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

>  Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth
> (arilfuld); [email-masked] 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
> 
>> [mailto:[email-masked]] On Behalf Of Jean-Marc
>> Valin Sent: 13. august 2015 21:30 To: [email-masked]
>> 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.
> 
>> 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.
> 
>> 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?
> 
>> complexity reasons). It survived several iterations of
>> deblocking filter improvements during the H.265 standardization
>> process.
> 
>>  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?
> 
>> 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-masked] 
>> _______________________________________________ video-codec
>> mailing list [email-masked] 
> _______________________________________________ video-codec
> mailing list [email-masked] 
> _______________________________________________ video-codec
> mailing list [email-masked]

---

From: Minhua Zhou <[email-masked]>
Date: Mon, 17 Aug 2015 16:11:43 +0000

Are de-blocked neighboring samples used for intra prediction? -- Minhua

-----Original Message-----
From: Jean-Marc Valin [mailto:[email-masked]] 
Sent: Monday, August 17, 2015 8:58 AM
To: Minhua Zhou; Arild Fuldseth (arilfuld); [email-masked]
Subject: Re: [video-codec] Questions about Thor

On 08/17/2015 11:44 AM, Minhua Zhou wrote:
>> 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

>  Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth (arilfuld); 
> [email-masked] Subject: Re: [video-codec] Questions about Thor
> 
> Hi Arild,
> 
>> Sent: 13. august 2015 21:30 To: [email-masked]
>> use the absolute value of the motion vectors on each side rather than 
>> the difference between the two motion vectors?
> 
>> not a collection of blocks (typically 4 luma&2 chroma or 1 luma&2 
>> chroma blocks) have non-zero coefficients or not.
>> between 32x32 superblocks. Are there known reasons why this would be 
>> a bad idea?
> 
>> VLC codes. Most of the VLC codes (n=0-10) are described in JCTVC-A119 
>> (last section of the decoder description).
> 
C
TVC-A119.zip

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 17 Aug 2015 15:12:14 -0400

> Are de-blocked neighboring samples used for intra prediction? --

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-masked]] Sent: Monday, August 17, 2015 8:58 AM 
>>> 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?
> 
> 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.
> 
> 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
> 
> 
>> Valin Sent: Monday, August 17, 2015 8:38 AM To: Arild Fuldseth
>>> 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
>>> 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.
> 
>>> 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?
> 
>>>  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?
> 
C
>>> 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
>

---

From: Dake He <[email-masked]>
Date: Mon, 17 Aug 2015 19:21:34 +0000

depending upon how deblocking is implemented, it is possible to use deblocked samples for intra prediction. 

--Dake

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Monday, August 17, 2015 3:12 PM
To: Minhua Zhou; Arild Fuldseth (arilfuld); [email-masked]
Subject: Re: [video-codec] Questions about Thor

> Are de-blocked neighboring samples used for intra prediction? -- 

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

> take the deblocking filter into account when making block size 
> decisions .
> 
> Cheers,
> 
> Jean-Marc
> 
>> Regards,
> 
>> Minhua
> 
> 
>>> 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.
> 
>>> pixels and using two pixels is marginal. While
>>> 8x8 block edges was one of our inputs to the initial H.265 draft 
>>> (for complexity reasons). It survived several iterations of 
C
>>> 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?
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 17 Aug 2015 12:33:44 -0700

> depending upon how deblocking is implemented, it is possible to use deblocked samples for intra prediction.

Well, certainly if you implement it in the order Jean-Marc was 
describing, you could apply deblocking to pixels along interior edges 
before using them to predict adjacent blocks along an exterior edge, but 
I believe that was one of the "not implementation friendly" things 
Minhua Zhou was complaining about. It means your hardware can't pipeline 
reconstruction of those neighboring blocks until it has the deblocked 
pixels, which is fairly late in the process.

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 17 Aug 2015 15:49:38 -0400

> pixels, which is fairly late in the process.

Well, most intra predictors use only the pixels on the edges of the
block, so the interior pixels -- deblocked or not -- aren't used at all.
In that case, the "recursive deblocking" is just equivalent to decoding
the entire image and then deblocking rows/columns that are multiples of
8 but not 16 first, then deblocking those are are multiples of 16 but
not 32, then deblocking the rest...

	Jean-Marc

---

From: Dake He <[email-masked]>
Date: Mon, 17 Aug 2015 20:01:09 +0000

Minhua might not like it, but still technically possible (otherwise he would not have asked the question in the first place) with careful ordering of processing steps of deblocking (vertical/horizontal) and prediction. 

--Dake

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Monday, August 17, 2015 3:50 PM
To: Timothy B. Terriberry; [email-masked]
Subject: Re: [video-codec] Questions about Thor

On 08/17/2015 03:33 PM, Timothy B. Terriberry wrote:
> before using them to predict adjacent blocks along an exterior edge, 
> but I believe that was one of the "not implementation friendly" things 
> Minhua Zhou was complaining about. It means your hardware can't 
> pipeline reconstruction of those neighboring blocks until it has the 
> deblocked pixels, which is fairly late in the process.

Well, most intra predictors use only the pixels on the edges of the block, so the interior pixels -- deblocked or not -- aren't used at all.
In that case, the "recursive deblocking" is just equivalent to decoding the entire image and then deblocking rows/columns that are multiples of
8 but not 16 first, then deblocking those are are multiples of 16 but not 32, then deblocking the rest...

	Jean-Marc

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 17 Aug 2015 13:21:42 -0700

> block, so the interior pixels -- deblocked or not -- aren't used at all.

A) That's no longer true. They run filters which may include interior 
pixels now.

B) What I meant by "interior edges" includes pixels on the exterior edge 
of the block, e.g.,

     A       B
*---+---*-------*
|   ║   |       |
+===+===+       |
|   ║   |       |
*---+---*-------*

Here ║ and = represent interior edges which need to be deblocked, and 
the four blocks in A are used to predict the single block in B (though 
it would not matter how B is split). The interior edge separating the 
top and bottom blocks includes pixels on the very right edge of A, and 
it matters whether they are deblocked or not before predicting B.

---

From: "Thomas Davies (thdavies)" <[email-masked]>
Date: Tue, 18 Aug 2015 08:56:43 +0000

Jean-Marc

To answer your original question, I think it's best from an implementation perspective not to impose an order on visiting blocks for deblocking if possible. It's pretty useful at least for SW optimisation to have a range of options for ordering how edges are visited and how the V and H stages interact with that.

best regards

Thomas

________________________________________
From: video-codec [[email-masked]] on behalf of Timothy B. Terriberry [[email-masked]]
Sent: 17 August 2015 21:21
To: [email-masked]
Subject: Re: [video-codec] Questions about Thor

     A       B
*---+---*-------*
|   ║   |       |
+===+===+       |
|   ║   |       |
*---+---*-------*

---

From: Minhua Zhou <[email-masked]>
Date: Tue, 18 Aug 2015 15:55:44 +0000

Any idea about the quality again by using the de-blocked reference samples in intra prediction? Agree that it is possible technically, but architecture wise this would create a nightmare for HW. Of course, if there was significant gain, we could take a second look.  -- Minhua

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Dake He
Sent: Monday, August 17, 2015 1:01 PM
To: Jean-Marc Valin; Timothy B. Terriberry; [email-masked]
Subject: Re: [video-codec] Questions about Thor

--Dake

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Monday, August 17, 2015 3:50 PM
To: Timothy B. Terriberry; [email-masked]
Subject: Re: [video-codec] Questions about Thor

	Jean-Marc

---

From: Dake He <[email-masked]>
Date: Wed, 19 Aug 2015 22:44:07 +0000

This was discussed in 2009 at VCEG in the context of AVC if my memory is correct. I don't recall there were exact numbers on the quality gain, at least not cross-checked ones. But it should be in the same range as the gain offered by the smoothing filter for intra prediction in HEVC. There is some, but probably not something to get too excited about. 

--Dake

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Dake He
Sent: Monday, August 17, 2015 1:01 PM
To: Jean-Marc Valin; Timothy B. Terriberry; [email-masked]
Subject: Re: [video-codec] Questions about Thor

--Dake

-----Original Message-----
From: video-codec [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Monday, August 17, 2015 3:50 PM
To: Timothy B. Terriberry; [email-masked]
Subject: Re: [video-codec] Questions about Thor

	Jean-Marc