Questions regarding libvpx issues

[hcb]

1. What makes libvpx so slow (ie 0.1 fps)? I think it's the motion search but I'm not sure.

2. Pieter Kapsenberg told me the blur issue was probably caused by 32x32 transforms. If so, what is being transformed and lost, actual image data (intra) or residuals (inter), and how does that relate to the blur?

[Pieter Kapsenberg]

Transforms apply on residual data, whether or not they are intra or inter predicted. When you have strong quantization and using 32x32, it results in the residual signal usually being pretty flat, smooth gradients because high frequency signals are typically zeroed out. This can (but not always) cause the reconstructed block to appear to blurry. Using smaller transforms can improve the results, but will also (usually) use more bits, so it is a trade-off.

On Wed, Feb 8, 2017 at 7:24 AM, hcb <designingo...@gmail.com> wrote:

1. What makes libvpx so slow (ie 0.1 fps)? I think it's the motion search but I'm not sure.

2. Pieter Kapsenberg told me the blur issue was probably caused by 32x32 transforms. If so, what is being transformed and lost, actual image data (intra) or residuals (inter), and how does that relate to the blur?

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel+unsubscribe@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[hcb]

That makes perfect sense. But I know that expending more CPU will give better results, because YouTube can look very sharp using 800 kbps @ 1080p. At what part could an encoder put in more effort to make videos look good at a low bitrate? By trying different transform directions in order to find the one that requires the least residual?

[Pieter Kapsenberg]

One of the key reasons that Youtube can look great at 800kbps is the codec selection, i.e. using VP9 instead of say H.264. Then, adding more CPU to VP9 encode means searching futher motion ranges, trying more filters and transform sizes, doing multi-pass encode, etc. There is a pretty long list of things that can tried.

On Wed, Feb 8, 2017 at 12:43 PM, hcb <designingo...@gmail.com> wrote:

That makes perfect sense. But I know that expending more CPU will give better results, because YouTube can look very sharp using 800 kbps @ 1080p. At what part could an encoder put in more effort to make videos look good at a low bitrate? By trying different transform directions in order to find the one that requires the least residual?

--

[Henry Barton]

By "searching further motion ranges", do you mean comparing blocks within a larger search area, increasing the granularity, or both? Is there any way a block could/should be searched within the entire frame, because when I wrote to Ronald Bultje he said something confusing about limits for search boundaries.

On Feb 8, 2017 3:47 PM, "Pieter Kapsenberg" <pkap...@waymo.com> wrote:

One of the key reasons that Youtube can look great at 800kbps is the codec selection, i.e. using VP9 instead of say H.264. Then, adding more CPU to VP9 encode means searching futher motion ranges, trying more filters and transform sizes, doing multi-pass encode, etc. There is a pretty long list of things that can tried.

[Pieter Kapsenberg]

Both. Yes, you could conceivably search every valid motion vector, every fractional offset. Obviously going outside the frame is unlikely to yield better predictions. But in practice this is unrealistic so there are lots of techniques to reduce the search space without giving up too much compression performance. As you might imagine, encoder design is a fertile area of innovation.

On Wed, Feb 8, 2017 at 1:07 PM, Henry Barton <designingo...@gmail.com> wrote:

By "searching further motion ranges", do you mean comparing blocks within a larger search area, increasing the granularity, or both? Is there any way a block could/should be searched within the entire frame, because when I wrote to Ronald Bultje he said something confusing about limits for search boundaries.

On Feb 8, 2017 3:47 PM, "Pieter Kapsenberg" <pkap...@waymo.com> wrote:

One of the key reasons that Youtube can look great at 800kbps is the codec selection, i.e. using VP9 instead of say H.264. Then, adding more CPU to VP9 encode means searching futher motion ranges, trying more filters and transform sizes, doing multi-pass encode, etc. There is a pretty long list of things that can tried.

On Wed, Feb 8, 2017 at 12:43 PM, hcb <designingo...@gmail.com> wrote:

That makes perfect sense. But I know that expending more CPU will give better results, because YouTube can look very sharp using 800 kbps @ 1080p. At what part could an encoder put in more effort to make videos look good at a low bitrate? By trying different transform directions in order to find the one that requires the least residual?

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel+unsubscribe@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel+unsubscribe@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Henry Barton]

Can you explain the point of having 64x64 blocks if the largest possible transform is 32x32?

On Feb 8, 2017 4:26 PM, "Pieter Kapsenberg" <pkap...@waymo.com> wrote:

Both. Yes, you could conceivably search every valid motion vector, every fractional offset. Obviously going outside the frame is unlikely to yield better predictions. But in practice this is unrealistic so there are lots of techniques to reduce the search space without giving up too much compression performance. As you might imagine, encoder design is a fertile area of innovation.

[Pieter Kapsenberg]

Those 4 32x32 blocks will share a common motion vector and other mode information. So you only send that once instead of 4 times.

On Feb 8, 2017 2:00 PM, "Henry Barton" <designingo...@gmail.com> wrote:

Can you explain the point of having 64x64 blocks if the largest possible transform is 32x32?

On Feb 8, 2017 4:26 PM, "Pieter Kapsenberg" <pkap...@waymo.com> wrote:

Both. Yes, you could conceivably search every valid motion vector, every fractional offset. Obviously going outside the frame is unlikely to yield better predictions. But in practice this is unrealistic so there are lots of techniques to reduce the search space without giving up too much compression performance. As you might imagine, encoder design is a fertile area of innovation.